I am aware that controllers can be placed in modules: ruby script/generate controller modulename/controllername But what does this buy me? Is it just a way of ensuring that my source code is nicely arranged, or can I use the fact that a set of controllers are all within a particular model to implement functionality common to all of those controllers? Why am I asking? The app we''re currently working on has some controllers which can be accessed by anyone and some which require the user to login before they can access it. Currently we have before_filter :login_required at the top of each "secure" controller. I would like to separate secure controllers into one module and unsecure controllers in another. I thought that this might give me a way to DRY the code up - by having the secure module enforce the login requirement. But if there is a way to achieve this, it''s escaping me. I can obviously achieve the desired effect through inheritance, as described here: http://justinfrench.com/index.php?id=122 But this requires me to remember to change the base class of each new secure controller (and raises the spectre of having a controller in the secure module which doesn''t inherit from the appropriate base). Am I missing something? Thanks! paul.butcher->msgCount++ -- Posted via http://www.ruby-forum.com/.
I can''t see anything wrong with the method described in that article - that''s exactly how i do it. Yeah, you have to change the inherited class for each new secure controller but that''s not really a problem. The generators are a nice helping hand but they''re not the be all and end all. As for raising spectre, the super class - AdminController - will in turn inherit from the standard ApplicationController which is perfectly appropriate :0) Steve Paul Butcher wrote:> I am aware that controllers can be placed in modules: > > ruby script/generate controller modulename/controllername > > But what does this buy me? Is it just a way of ensuring that my source > code is nicely arranged, or can I use the fact that a set of controllers > are all within a particular model to implement functionality common to > all of those controllers? > > Why am I asking? > > The app we''re currently working on has some controllers which can be > accessed by anyone and some which require the user to login before they > can access it. Currently we have > > before_filter :login_required > > at the top of each "secure" controller. I would like to separate secure > controllers into one module and unsecure controllers in another. I > thought that this might give me a way to DRY the code up - by having the > secure module enforce the login requirement. But if there is a way to > achieve this, it''s escaping me. > > I can obviously achieve the desired effect through inheritance, as > described here: > > http://justinfrench.com/index.php?id=122 > > But this requires me to remember to change the base class of each new > secure controller (and raises the spectre of having a controller in the > secure module which doesn''t inherit from the appropriate base). > > Am I missing something? > > Thanks! > > paul.butcher->msgCount++ >
It''s not really a module, it''s just a directory. What you can do is create a controller with all of the functionality you need and then have each one of your "secure" controllers inherit from that. ie class SecureController < Admin If you do this you get all of the normal controller stuff pluss whatever you have in the admin controller On Wed, 2006-05-31 at 17:35 +0200, Paul Butcher wrote:> I am aware that controllers can be placed in modules: > > ruby script/generate controller modulename/controllername > > But what does this buy me? Is it just a way of ensuring that my source > code is nicely arranged, or can I use the fact that a set of controllers > are all within a particular model to implement functionality common to > all of those controllers? > > Why am I asking? > > The app we''re currently working on has some controllers which can be > accessed by anyone and some which require the user to login before they > can access it. Currently we have > > before_filter :login_required > > at the top of each "secure" controller. I would like to separate secure > controllers into one module and unsecure controllers in another. I > thought that this might give me a way to DRY the code up - by having the > secure module enforce the login requirement. But if there is a way to > achieve this, it''s escaping me. > > I can obviously achieve the desired effect through inheritance, as > described here: > > http://justinfrench.com/index.php?id=122 > > But this requires me to remember to change the base class of each new > secure controller (and raises the spectre of having a controller in the > secure module which doesn''t inherit from the appropriate base). > > Am I missing something? > > Thanks! > > paul.butcher->msgCount++Charlie Bowman http://www.recentrambles.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060531/2c1e7bd0/attachment-0001.html
Stephen Bartholomew wrote:> As for raising spectre, the super class - AdminController - will in turn > inherit from the standard ApplicationController which is perfectly > appropriate :0)What I was concerned about was that someone might place a controller in the secure module, but forget to modify the base. Anyone looking at the source would *assume* that it was secure because it was in the secure module. Ah well - it doesn''t look like there''s a way of achieving what I wanted (or at least not out of the box). Thanks for the responses! paul.butcher->msgCount++ -- Posted via http://www.ruby-forum.com/.
It''s not a module, it''s just a directory. On Wed, 2006-05-31 at 18:06 +0200, Paul Butcher wrote:> Stephen Bartholomew wrote: > > As for raising spectre, the super class - AdminController - will in turn > > inherit from the standard ApplicationController which is perfectly > > appropriate :0) > > What I was concerned about was that someone might place a controller in > the secure module, but forget to modify the base. Anyone looking at the > source would *assume* that it was secure because it was in the secure > module. > > Ah well - it doesn''t look like there''s a way of achieving what I wanted > (or at least not out of the box). > > Thanks for the responses! > > paul.butcher->msgCount++ >Charlie Bowman Programmer Castle Branch Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060531/9196546c/attachment.html
On 31-May-06, at 8:35 AM, Paul Butcher wrote: <snip>> > I can obviously achieve the desired effect through inheritance, as > described here: > > http://justinfrench.com/index.php?id=122 > > But this requires me to remember to change the base class of each new > secure controller (and raises the spectre of having a controller in > the > secure module which doesn''t inherit from the appropriate base). >Hi Paul, I blogged about doing this just the other day :-) http://tinyurl.com/pqkbs Regards, Trevor -- Trevor Squires http://somethinglearned.com> Am I missing something? > > Thanks! > > paul.butcher->msgCount++ > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 31-May-06, at 10:21 AM, Charlie Bowman wrote:> It''s not a module, it''s just a directory. >Charlie, Rails (1.1 at least) creates a module for each of your subdirectories. admin/foo_controller becomes Admin::FooController and Admin.class returns "Module" Regards, Trevor> On Wed, 2006-05-31 at 18:06 +0200, Paul Butcher wrote: >> Stephen Bartholomew wrote: >> > As for raising spectre, the super class - AdminController - will >> in turn >> > inherit from the standard ApplicationController which is perfectly >> > appropriate :0) >> >> What I was concerned about was that someone might place a >> controller in >> the secure module, but forget to modify the base. Anyone looking >> at the >> source would *assume* that it was secure because it was in the secure >> module. >> >> Ah well - it doesn''t look like there''s a way of achieving what I >> wanted >> (or at least not out of the box). >> >> Thanks for the responses! >> >> paul.butcher->msgCount++ >> > Charlie Bowman > Programmer > Castle Branch Inc. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060531/ab4aa05b/attachment.html
Charlie Bowman wrote:> It''s not a module, it''s just a directory.Yes, I understand that. But all the documentation *calls* it a module, so I thought that I would be consistent. paul.butcher->msgCount++ -- Posted via http://www.ruby-forum.com/.
Trevor Squires wrote:> I blogged about doing this just the other day :-)Cool - thanks Trevor. Nice to see someone else who thinks the same way :-) paul.butcher->msgCount++ -- Posted via http://www.ruby-forum.com/.
That''s neat for what you need it for - but as you say it might get messy as the application grows - things like layouts would be more complicated than they need to be. I guess you have to wonder what level of abstraction you need to go to. Most of our models inherit from ActiveRecord, our controllers from ActionController - this isn''t seen as a problem (nor should it be :0) ). Having an admin controller seems nice and organised to me - but i guess that''s personal taste :0) Regarding the clash of the admin name, I (and a few other people) just create a Dashboard controller that is the default route for the /admin/ directory. This might seem hacky at first but it kinda makes sense if you think of it in terms mapping an interface to real-world...things :0) Ok - so maybe i''m waffling, but sometimes it''s good to think about things from a different angle. Plus, nerdy app design debates are always fun :0) Steve Trevor Squires wrote:> On 31-May-06, at 8:35 AM, Paul Butcher wrote: > <snip> > >> >> I can obviously achieve the desired effect through inheritance, as >> described here: >> >> http://justinfrench.com/index.php?id=122 >> >> But this requires me to remember to change the base class of each new >> secure controller (and raises the spectre of having a controller in the >> secure module which doesn''t inherit from the appropriate base). >> > > Hi Paul, > > I blogged about doing this just the other day :-) > > http://tinyurl.com/pqkbs > > Regards, > Trevor > -- > Trevor Squires > http://somethinglearned.com > >> Am I missing something? >> >> Thanks! >> >> paul.butcher->msgCount++ >> >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
On Wednesday, May 31, 2006, at 7:52 PM, Stephen Bartholomew wrote:>That''s neat for what you need it for - but as you say it might get messy >as the application grows - things like layouts would be more complicated >than they need to be. I guess you have to wonder what level of >abstraction you need to go to. Most of our models inherit from >ActiveRecord, our controllers from ActionController - this isn''t seen as >a problem (nor should it be :0) ). Having an admin controller seems >nice and organised to me - but i guess that''s personal taste :0) > >Regarding the clash of the admin name, I (and a few other people) just >create a Dashboard controller that is the default route for the /admin/ >directory. This might seem hacky at first but it kinda makes sense if >you think of it in terms mapping an interface to real-world...things :0) > >Ok - so maybe i''m waffling, but sometimes it''s good to think about >things from a different angle. Plus, nerdy app design debates are >always fun :0) > >Steve > > >Trevor Squires wrote: >> On 31-May-06, at 8:35 AM, Paul Butcher wrote: >> <snip> >> >>> >>> I can obviously achieve the desired effect through inheritance, as >>> described here: >>> >>> http://justinfrench.com/index.php?id=122 >>> >>> But this requires me to remember to change the base class of each new >>> secure controller (and raises the spectre of having a controller in the >>> secure module which doesn''t inherit from the appropriate base). >>> >> >> Hi Paul, >> >> I blogged about doing this just the other day :-) >> >> http://tinyurl.com/pqkbs >> >> Regards, >> Trevor >> -- >> Trevor Squires >> http://somethinglearned.com >> >>> Am I missing something? >>> >>> Thanks! >>> >>> paul.butcher->msgCount++ >>> >>> -- >>> Posted via http://www.ruby-forum.com/. >>> _______________________________________________ >>> Rails mailing list >>> Rails@lists.rubyonrails.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/railsI''m curious as to what you are actually using the ''admin'' controllers for. My preferred user interface is to implement all controller actions in a single controller and then use a role-based system to see if a particular user has rights to a particular action. I find this a bit cleaner and easier to maintain since you don''t end up with multiple controllers operating on the same models. Of course I can see lots of reasons to do it the way you are, I''m just curious to know why you want a separate admin controller. _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox.
> Of course I can see lots of reasons to do it the way you are, I''m just> curious to know why you want a separate admin controller. I use seperate controllers because i have a seperate interface for the admin system - it''s used by the administrators of the website - not the users. Also, there are actions that have the same name on both the front and back end - ''view'' for example. The admin product ''view'' would load everything needed to edit a product - the front end ''view'' loads all the things needed to show the product on the website. On top of all that, there are loads of actions on the admin i don''t want accessible on the front-end - and never would. So grouping the controllers into a module is a nice simple way of achieving this. I *could* use role-based authentication - but why would i bother? My auth needs a straight forward. Steve Kevin Olbrich wrote:> On Wednesday, May 31, 2006, at 7:52 PM, Stephen Bartholomew wrote: > >>That''s neat for what you need it for - but as you say it might get messy >>as the application grows - things like layouts would be more complicated >>than they need to be. I guess you have to wonder what level of >>abstraction you need to go to. Most of our models inherit from >>ActiveRecord, our controllers from ActionController - this isn''t seen as >>a problem (nor should it be :0) ). Having an admin controller seems >>nice and organised to me - but i guess that''s personal taste :0) >> >>Regarding the clash of the admin name, I (and a few other people) just >>create a Dashboard controller that is the default route for the /admin/ >>directory. This might seem hacky at first but it kinda makes sense if >>you think of it in terms mapping an interface to real-world...things :0) >> >>Ok - so maybe i''m waffling, but sometimes it''s good to think about >>things from a different angle. Plus, nerdy app design debates are >>always fun :0) >> >>Steve >> >> >>Trevor Squires wrote: >> >>>On 31-May-06, at 8:35 AM, Paul Butcher wrote: >>><snip> >>> >>>>I can obviously achieve the desired effect through inheritance, as >>>>described here: >>>> >>>>http://justinfrench.com/index.php?id=122 >>>> >>>>But this requires me to remember to change the base class of each new >>>>secure controller (and raises the spectre of having a controller in the >>>>secure module which doesn''t inherit from the appropriate base). >>>> >>> >>>Hi Paul, >>> >>>I blogged about doing this just the other day :-) >>> >>>http://tinyurl.com/pqkbs >>> >>>Regards, >>>Trevor >>>-- >>>Trevor Squires >>>http://somethinglearned.com >>> >>> >>>>Am I missing something? >>>> >>>>Thanks! >>>> >>>>paul.butcher->msgCount++ >>>> >>>>-- >>>>Posted via http://www.ruby-forum.com/. >>>>_______________________________________________ >>>>Rails mailing list >>>>Rails@lists.rubyonrails.org >>>>http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >>>_______________________________________________ >>>Rails mailing list >>>Rails@lists.rubyonrails.org >>>http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >>> >> >>_______________________________________________ >>Rails mailing list >>Rails@lists.rubyonrails.org >>http://lists.rubyonrails.org/mailman/listinfo/rails > > > I''m curious as to what you are actually using the ''admin'' controllers for. > > My preferred user interface is to implement all controller actions in a > single controller and then use a role-based system to see if a > particular user has rights to a particular action. I find this a bit > cleaner and easier to maintain since you don''t end up with multiple > controllers operating on the same models. > > Of course I can see lots of reasons to do it the way you are, I''m just > curious to know why you want a separate admin controller. > > > _Kevin >
On Wednesday, May 31, 2006, at 8:30 PM, Stephen Bartholomew wrote:>users. Also, there are actions that have the same name on both the >front and back end - ''view'' for example. The admin product ''view'' would > load everything needed to edit a product - the front end ''view'' loads >all the things needed to show the product on the website.Mostly it just seems to be a style thing, which is fine. FWIW, you can write views that use logic to decide what to present to the user. Something like <% if authorized? %> You are authorized <% else %> You are not authorized <% end %> This seems a bit DRYer to me since you don''t have to maintain two separate views (and controllers) for the same object and essentially the same action. _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox.
Julian ''Julik'' Tarkhanov
2006-May-31 22:38 UTC
[Rails] What are controller modules *for*?
On 31-mei-2006, at 21:49, Kevin Olbrich wrote:> > On Wednesday, May 31, 2006, at 8:30 PM, Stephen Bartholomew wrote: >> users. Also, there are actions that have the same name on both the >> front and back end - ''view'' for example. The admin product ''view'' >> would >> load everything needed to edit a product - the front end ''view'' >> loads >> all the things needed to show the product on the website. > > Mostly it just seems to be a style thing, which is fine. > > FWIW, you can write views that use logic to decide what to present to > the user.Or you can use a module and mix it into any controller at will. module Security def self.append_features(klass) klass.send(:before_filter, :do_auth) super end protected def do_auth; ... end end and then class Admin::Special < ApplicationController include Security end There was a discussion to implement stuff to do it much nicer here http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38371 but I don''t know where it got to (this would be a way for your controllers to get some boost of the module upon definition) OTOH,> But this requires me to remember to change the base class of each new > secure controller (and raises the spectre of having a controller in > the > secure module which doesn''t inherit from the appropriate base).Testing? assert_kind_of SecureController, @controller -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
Apparently Analagous Threads
- I can''t get rails to see my plugin. How can I this?
- validations without AR - going crazy trying to find link
- Idiom question - assertions which aren''t in tests
- A mock which extends rather than replaces a class?
- rake create_sessions_table, does not create session table