# Newbie Q: "user" variable in every view?

**URL:** <https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356>\
**Category:** Rails\
**Created:** [June 24, 2006, 7:09pm UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356 "2006-06-24T19:09:44Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 24, 2006, 7:09pm UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/1 "2006-06-24T19:09:44Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 24, 2006, 7:53pm UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/2 "2006-06-24T19:53:52Z")

</div>

On 6/24/06, Will M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 😉

Good luck, and have fun!

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 26, 2006, 3:35am UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/3 "2006-06-26T03:35:48Z")

</div>

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

Best,

Will

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 26, 2006, 5:25pm UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/4 "2006-06-26T17:25:57Z")

</div>

> 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

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 26, 2006, 6:46am UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/5 "2006-06-26T06:46:22Z")

</div>

> On 6/24/06, Will M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 27, 2006, 2:35pm UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/6 "2006-06-27T14:35:24Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 27, 2006, 6:23am UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/7 "2006-06-27T06:23:26Z")

</div>

On 6/26/06, Hendrik M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![wmerydith](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/ccd318/32.png) [@wmerydith](https://www.ruby-forum.com/u/wmerydith)\
**Post date:** [June 28, 2006, 7:05am UTC](https://www.ruby-forum.com/t/newbie-q-user-variable-in-every-view/64356/8 "2006-06-28T07:05:25Z")

</div>

On 6/27/06, Åukasz Piestrzeniewicz [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.
