Newbie to RoR -- as a long time Java Struts/etc. guy it is an awesome tool! I have implemented some basic login/session stuff with the help of a great tutorial, props to the author ( aidanf.net/rails_user_authentication_tutorial). I have a trivial instance method in ApplicationController, which just grabs the User object from the session. def current_user session[:user] end So I can of course call this from within any subclass controller. All I am now trying to do is implement it such that I have access to this user automatically in every view. What is the generally recommended way of doing this -- should I put a call to this method in the constructor of the controller and assign it to an instance variable there? Or should I put it in a view helper instead? Thanks for any tips...RonR is proving to be pretty awesome (I guess you all know that), so glad to be getting into the swing of it. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: wrath.rubyonrails.org/pipermail/rails/attachments/20060624/62576178/attachment.html
On 6/24/06, Will Meyer <will@bracketstyle.org> wrote:> Newbie to RoR -- as a long time Java Struts/etc. guy it is an awesome tool! > > I have implemented some basic login/session stuff with the help of a great > tutorial, props to the author ( > aidanf.net/rails_user_authentication_tutorial). > > I have a trivial instance method in ApplicationController, which just grabs > the User object from the session. > > def current_user > session[:user] > end > > So I can of course call this from within any subclass controller. All I am > now trying to do is implement it such that I have access to this user > automatically in every view. What is the generally recommended way of doing > this -- should I put a call to this method in the constructor of the > controller and assign it to an instance variable there? Or should I put it > in a view helper instead?helper_method :user And voila! Also, consider not overloading your ApplicationController. If you need a convenience method like user in a set of controllers and their views, always opt to create an abstract controller class inheriting from ApplicationController, and have all the controllers in the group inherit from it.> Thanks for any tips...RonR is proving to be pretty awesome (I guess you all > know that), so glad to be getting into the swing of it.Yeah, we know ;) Good luck, and have fun!> Will > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > lists.rubyonrails.org/mailman/listinfo/rails > > >-- -Alder
Much appreciated, thank you for the pointer to helper_method (still getting used to actually finding things in the docs). Best, Will On 6/24/06, Alder Green <alder.green@gmail.com> wrote:> > On 6/24/06, Will Meyer <will@bracketstyle.org> wrote: > > Newbie to RoR -- as a long time Java Struts/etc. guy it is an awesome > tool! > > > > I have implemented some basic login/session stuff with the help of a > great > > tutorial, props to the author ( > > aidanf.net/rails_user_authentication_tutorial). > > > > I have a trivial instance method in ApplicationController, which just > grabs > > the User object from the session. > > > > def current_user > > session[:user] > > end > > > > So I can of course call this from within any subclass controller. All I > am > > now trying to do is implement it such that I have access to this user > > automatically in every view. What is the generally recommended way of > doing > > this -- should I put a call to this method in the constructor of the > > controller and assign it to an instance variable there? Or should I put > it > > in a view helper instead? > > helper_method :user > > And voila! > > Also, consider not overloading your ApplicationController. If you need > a convenience method like user in a set of controllers and their > views, always opt to create an abstract controller class inheriting > from ApplicationController, and have all the controllers in the group > inherit from it. > > > Thanks for any tips...RonR is proving to be pretty awesome (I guess you > all > > know that), so glad to be getting into the swing of it. > > Yeah, we know ;) > > Good luck, and have fun! > > > Will > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > -- > -Alder >-------------- next part -------------- An HTML attachment was scrubbed... URL: wrath.rubyonrails.org/pipermail/rails/attachments/20060626/7338f1f6/attachment-0001.html
> On 6/24/06, Will Meyer <will@bracketstyle.org> wrote: > helper_method :userYou mean helper_method :current_user right?> > And voila! > > Also, consider not overloading your ApplicationController. If you need > a convenience method like user in a set of controllers and their > views, always opt to create an abstract controller class inheriting > from ApplicationController, and have all the controllers in the group > inherit from it.Why? Sounds like extra work to me. Am I missing something? Thanks, Jeff -- Posted via ruby-forum.com.
> Also, consider not overloading your ApplicationController. If you need > a convenience method like user in a set of controllers and their > views, always opt to create an abstract controller class inheriting > from ApplicationController, and have all the controllers in the group > inherit from it.Simply out of curiosity, what is the reasoning behind this? Cheers, Hendrik -- mans.de
On 6/26/06, Hendrik Mans <hendrik@mans.de> wrote:> > Also, consider not overloading your ApplicationController. If you need > > a convenience method like user in a set of controllers and their > > views, always opt to create an abstract controller class inheriting > > from ApplicationController, and have all the controllers in the group > > inherit from it. > > Simply out of curiosity, what is the reasoning behind this?The "controller groups via abstract parent" pattern is generally useful, for example for automagic sharing of layout and filters. ApplicationController itself should be touched only on very rare occassions. Changes with such far-reaching effects are the kind of things you might later regret. Almost always, you really don''t want functionality across all controllers, but within a certain subset (group) of controllers. And if you think you do, unless you''re writing something simple which won''t change much - you can''t really be sure. What if next month you''ll need to add a seperate administrator interface, with a completely different #user method? Finally, keeping your functionality logically seperated makes for much better code organization than sticking everything in a single file (application.rb in this case). Again, unless you''re writing something which is and will stay simple, insisting to extend ApplicationController would lead to a huge class with diverse (in certain cases even incompatible/contradictory) logic. At least for some applications I''ve written, I''d be looking at several KLOCs. So to sum-up: the sub-grouping pattern keeps your code organized, keeps your namespace cleaner (no #user method in controllers that don''t need it, especially important for common method names like user which you might want to override). And if you''re already using the sub-grouping pattern for other reasons - which I think is what you should do for anything not extremely simple - then storing common methods in them is, if anything, easier than overloading application.rb> > Cheers, > Hendrik > > -- > mans.de > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > lists.rubyonrails.org/mailman/listinfo/rails >-- -Alder
Ćukasz Piestrzeniewicz
2006-Jun-27 12:35 UTC
[Rails] Re: Newbie Q: "user" variable in every view?
Alder Green wrote:> ApplicationController itself should be touched only on very rare > occasions. Changes with such far-reaching effects are the kind of > things you might later regret.Actually I agree that in the long run and with big application you do in fact reach state you describe. But I think that doing that kind of structuring in first days (or even weeks/months) of application development might bring undesired results. Developers then tend to over-structure the code and spend plenty of time designing high level abstractions on early project stage. And that is never good. Instead use refactoring: write things as they are necessary. In the beginning put everything in the place where it can be reached in the simplest way. ApplicationController is a perfect choice. Write tests that confirm that your code works. Later on you will be able to refactor things out to separate layers of abstraction - but only if it clarify the code. Such pragmatic approach with good test suite will help you deliver working material earlier and create better structure later. Cheers, ?ukasz Piestrzeniewicz -- Posted via ruby-forum.com.
On 6/27/06, ?ukasz Piestrzeniewicz <bragi.ragnarson+rf@gmail.com> wrote:> Alder Green wrote: > > ApplicationController itself should be touched only on very rare > > occasions. Changes with such far-reaching effects are the kind of > > things you might later regret. > > Actually I agree that in the long run and with big application you do in > fact reach state you describe. But I think that doing that kind of > structuring in first days (or even weeks/months) of application > development might bring undesired results. Developers then tend to > over-structure the code and spend plenty of time designing high level > abstractions on early project stage. And that is never good.It''s probably context-sensitive, like most development "best-practices". I''m a freelancer, working alone, and I find that I frequently need that seperation soon after the project begins. Commonly I''d end up with too large and diverse appliation.rb within 2 weeks of the beginning of the project, if indeed I''d use it instead of controller subgroups. Also (again, in my own case) the cost of making such seperation is pretty minimal, much less than a refactoring would require later. And of course, I''m not worried that the structure would bloat the architecture of the system, since even when I''m working with other developers, the architecture is determined by me before hand.> Instead use refactoring: write things as they are necessary. In the > beginning put everything in the place where it can be reached in the > simplest way. ApplicationController is a perfect choice. Write tests > that confirm that your code works. Later on you will be able to refactor > things out to separate layers of abstraction - but only if it clarify > the code. > > Such pragmatic approach with good test suite will help you deliver > working material earlier and create better structure later. > > Cheers, > > ?ukasz Piestrzeniewicz > > -- > Posted via ruby-forum.com. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > lists.rubyonrails.org/mailman/listinfo/rails >-- -Alder