[rspec-users] Nosy controller specs

Andrew Premdas apremdas at gmail.com
Thu Dec 11 15:34:15 EST 2008


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 <mark at mwilden.com>

> On Thu, Dec 11, 2008 at 11:28 AM, Andrew Premdas <apremdas at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081211/43bcf5f6/attachment.html>


More information about the rspec-users mailing list