We're actually getting pretty close to saying the same thing here, though my use of language is causing some confusion. The two sorts of requests I was talking about where a view request and a request by the business for a specific rule to be implemented.
If there were AuditablePosts the controller wouldn't decide what display it could decide where to route (well actually the Dispatcher but you get my drift) because this new resource would have its own controller as its a seperate business entity. A controller really shouldn't be choosing between model entities, you wouldn't do this would you? def index if params[:auditable] @posts = AuditablePosts.find(:all) else @posts = Posts.find(:all) end end but we often end up with def index if params[:auditable] @posts = Posts.find_auditable else @posts = Posts.find(:all) end end which really isn't much different. You mentioned something like def index if params[:auditable] @posts = Posts.get_auditable_posts else @posts = Posts.find(:all) end end which I think is better. However I kind of think we should have def index @posts = Posts.get_collection(params) or have two resources and two controllers, and not have anything inbetween. Andrew 2008/12/11 Mark Wilden <m...@mwilden.com> > On Thu, Dec 11, 2008 at 11:28 AM, Andrew Premdas <aprem...@gmail.com>wrote: > > >> As you say controllers should not be responsible for defining things, but >> in Rails this is exactly what they do, they formulate queries using class >> methods like find_by_xxx. Personally I think Rails is somewhat confused or >> perhaps lax in defining Controller responsibilities compared to many MVC >> frameworks and particularly to the underlying concept of MVC. > > > When I was talking about defining things, I meant that the controller > should request "this year's posts," but shouldn't define what that means > (calendar year? fiscal year? which calendar? which timezone?). Put it > another way - if there was a button on the view labeled "View this year's > posts", it would be appropriate for the controller to call the > this_years_posts method on the model, right? I was just extending that > thinking to what the controller displays by default. But it's not cut and > dried. Pat mentioned things like acts_as_paranoid which controllers > certainly should not be concerned with. > > >> As for this years posts being a presentation issue that depends. If the >> request came from a view i.e. I'd like to see post for 2001 then the >> controller should pass parameters to the model so it can return the correct >> things. > > > Don't most requests come from views? I mean, you got to this page via a > user gesture of some kind. (Parenthetically, I consider views the most > important part of a web app - if the right thing is displayed to the right > user at the right time, it doesn't matter if it's generated by a herd of > monkeys.) > > >> On the other hand if last years posts represent a specific business >> concept something perphaps like AuditablePosts, then the model could/should >> represent this as a seperate resource. > > > That sounds good. But the controller would still have to decide to display > AuditablePosts on that page (and might display UnauditablePosts on another > page). Again, it would know what result set - in domain terms - it wants to > display. It shouldn't care about how the model defines that result set. > > I appreciate the opportunity to grope my way through my opinions on this > subject. :) > > ///ark > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users