Newbie Q: "user" variable in every view?

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 (
http://www.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

On 6/24/06, Will M. [email protected] wrote:

 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 :wink:

Good luck, and have fun!

Much appreciated, thank you for the pointer to helper_method (still
getting
used to actually finding things in the docs).

Best,

Will

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

On 6/24/06, Will M. [email protected] wrote:
helper_method :user

You 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

Alder G. 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

On 6/26/06, Hendrik M. [email protected] 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

On 6/27/06, Łukasz Piestrzeniewicz [email protected] wrote:

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs