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