"Andrew Premdas" <aprem...@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 end def repository params[:auditable] ? Post.auditable : Post end :O 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. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
