Another newbie question: I want to keep business logic out of my controller. For example I had a routine that did a slightly complicated computation and it didn''t seem to belong in the controller. But the calculation has nothing to do with display per-se. It takes an integer in and returns a different integer. So I thought to put it in the corresponding helper. Is that the best practice? Because I note that helpers are not automatically ''included'' in the corresponding controller. I had to add an ''include'' to the controller which seemed a bit lame. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12 Dec 2007, at 02:34, Pito wrote:> > Another newbie question: I want to keep business logic out of my > controller. For example I had a routine that did a slightly > complicated computation and it didn''t seem to belong in the > controller. But the calculation has nothing to do with display per-se. > It takes an integer in and returns a different integer. > > So I thought to put it in the corresponding helper. Is that the best > practice? > > Because I note that helpers are not automatically ''included'' in the > corresponding controller. I had to add an ''include'' to the controller > which seemed a bit lame.When you see helper, think ''view helper''. They''re loaded automatically into templates. They''re not loaded into controller, because they''re little bits of presentation logic and so don''t belong in the controller normally. It sounds like your complicated calculation belongs in a model Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Not really. In my experience, it works like this: Keep Controllers and View Skinny. In other words, keep as much code out of the controllers and view as possible. The controller should only 1) Make basic calls to model (save, update, custom_method_1) 2) Assign values to use in the view 3) Alter the session, cookies, flash 4) Redirect or render That is all a controller should do, aka the bare minimum. Same with the view. A view should only contain 1) Simple pieces of data to display (set in the controller) 2) Simple formatting and structure with html In your quest to keep the controller clean you have some basic options at hand but the primary place to stick all the stuff you don''t want in the controller is in the model! Put all the complicated code in the model and then make simple one line requests and store the return values in the controller (for display in the view). In your quest to keep views clean, you have helpers and partials. Basically, use helpers and partials whenever possible to keep views as concise and clean of code as possible. So Basically, Controller => Lean, View => Lean Model => Picks up controller''s excess code Helper => Picks up views excess code That''s my take anyways. Pito wrote:> Another newbie question: I want to keep business logic out of my > controller. For example I had a routine that did a slightly > complicated computation and it didn''t seem to belong in the > controller. But the calculation has nothing to do with display per-se. > It takes an integer in and returns a different integer. > > So I thought to put it in the corresponding helper. Is that the best > practice? > > Because I note that helpers are not automatically ''included'' in the > corresponding controller. I had to add an ''include'' to the controller > which seemed a bit lame.-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
In addition to Nathan''s excellent remarks, I''d add: 3) As much formatting as possible in the stylesheet. ///ark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I always felt helper should have been a folder inside the views folder almost. It seems like a common mistake amongst new people to rails to think helpers are helpers for controllers or models and I can''t blame them. They need a way of distinguishing helpers and view-centric more. It''s not really it''s own part of the MVC model yet it gets its own folder next to the rest of them. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks all for the excellent points. I held back from putting the logic in the model because it really wasn''t model related. It was more of a ''business rule'' which takes a date in and generates two boolean and one date result. The model is a User table, nothing more. That''s how I ended up with the helper but as you all say, helpers are more view helpers - as is evidenced by needing to do an explicit include in the controller. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
That''s just it... business rules go in models.
However, it may not go in the User model. Models in Rails are not just
data-access objects - they are your domain models. If this code belongs to
a User, it goes in the User model.
You can even have models that don''t have a table behind them.
Since I don''t know what this method actually does, I can''t
tell you where it
should go. However, another option is to make your own class and put it
there. The Lib folder is a great place for classes that aren''t models.
lib/utility.rb
class Utility
# returns two dates plus the date + 10
def self.do_something_with_date(date)
return 0, 1, date + 10
end
end
That class wil be required automatically by Rails, so you can use it where
you want. In models, views, etc.
So there''s another option. How you do it depends on what you want to
accomplish. It''s most likely that this method you''re referring
to has some
association with a model, so that''s where I''d put it.
On Dec 12, 2007 1:55 PM, Pito
<pitosalas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Thanks all for the excellent points.
>
> I held back from putting the logic in the model because it really
> wasn''t model related. It was more of a ''business
rule'' which takes a
> date in and generates two boolean and one date result. The model is a
> User table, nothing more.
>
> That''s how I ended up with the helper but as you all say, helpers
are
> more view helpers - as is evidenced by needing to do an explicit
> include in the controller.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
One thing I have come to understand which frankly is useful knowledge is that whenever I tried to "go around rails", in other words, when I tried to do things the "non-rails" way I always thought I had a good reason. I would convince myself that doing it MY way was smarter or better for my specific condition. What I didn''t realize was that I was just doing things wrong. 90% of the time it was just me not understand how beautiful and simple life would be if I would have just not tried to reinvent the wheel or do thing my way. If I just go with the rails conventions, once I learned what they were, it ended up making more sense to me that my way even did. The problem was learning them all because there are so many patterns and conventions to learn it can drive a man crazy. I don''t know if this has been any one else''s experience but for me, when I run into a place where my opinion differs from rails convention, I do a long, hard look at what I want to do and try to seriously evaluate the possibility that I am missing something. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I''d go with Brian''s approach, personally. For example, I have a file in my lib directory that does the rendering of a PDF, which would otherwise clog up my controlller. I also have Vacation and PTO calculations in my lib directory for an employee program. On Dec 12, 4:12 pm, "Brian Hogan" <bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That''s just it... business rules go in models. > > However, it may not go in the User model. Models in Rails are not just > data-access objects - they are your domain models. If this code belongs to > a User, it goes in the User model. > > You can even have models that don''t have a table behind them. > > Since I don''t know what this method actually does, I can''t tell you where it > should go. However, another option is to make your own class and put it > there. The Lib folder is a great place for classes that aren''t models. > > lib/utility.rb > > class Utility > # returns two dates plus the date + 10 > def self.do_something_with_date(date) > return 0, 1, date + 10 > end > > end > > That class wil be required automatically by Rails, so you can use it where > you want. In models, views, etc. > > So there''s another option. How you do it depends on what you want to > accomplish. It''s most likely that this method you''re referring to has some > association with a model, so that''s where I''d put it. > > On Dec 12, 2007 1:55 PM, Pito <pitosa...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Thanks all for the excellent points. > > > I held back from putting the logic in the model because it really > > wasn''t model related. It was more of a ''business rule'' which takes a > > date in and generates two boolean and one date result. The model is a > > User table, nothing more. > > > That''s how I ended up with the helper but as you all say, helpers are > > more view helpers - as is evidenced by needing to do an explicit > > include in the controller.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---