[rspec-users] Nosy controller specs

Pat Maddox pergesu at gmail.com
Thu Dec 11 18:03:08 EST 2008

"Andrew Premdas" <apremdas at gmail.com> writes:

> 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

I don't see why not.

In fact, something I like to do is

def index
  @posts = repository.find :all

def repository
  params[:auditable] ? Post.auditable : Post


Makes a lot of sense to me.  The controller's basic job is to get some
stuff from the model and give it to the view.  If the "get some stuff"
requires parameterization, fine by me.

Of course, there are plenty of ways you can structure your code.  You
can use query params (and take advantage of routes to make it look like
a clean URL...hey, you're still RESTful!) or a new action (again, still
RESTful), or create a whole new controller for it.  That's another
reason why REST is sweet from web app development perspective - stick to
a consistent URL scheme, and you can refactor the app beneath it however
you want.


More information about the rspec-users mailing list