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
