Musings - how thin can controllers go

rubyonrails-core
1

The core team seems to be all about practicality, rather than theory, but as I do more and more REST development, it gets me thinking.... Mainly about how controllers are just becoming thin proxies for the true object - models. And then I wonder, how far will this trend go. Should Resource Feeder just be strapped into the model, instead of the controller, so that the class (or a finder on the class) can just to_rss or to_atom. And once you go down that road, that starts looking like the more purely OO approach of just having the model handle all of it's own output. Could/should the model be able to just swallow the whole responds_to block (this would assume it gets passed something that lets it now what url it is at).

Maybe this is useless idling, but how far down that rabbit hole is advisable. Could it clean up Rails development into some just a little custom init code for objects, creating layouts, and tweaking builders for object? Basically get it to the point where you adjust the UI, and then rest (*rimshot*) almost auto-wires itself?

2

Rails follows a strict MVC pattern. The model shouldn’t really care about its output because all it cares about is domain logic tied to it. It can’t know how it’s going to be presented to the world. The pattern was designed to force this separation, so there is no sense struggling to further design to work around it.

I feel you are mixing “pure OO approach” with “less code, more magic”. If you want for your controllers to suddenly become magical about resources, respond_to and stuff, why don’t you just implement this in an abstract controller and have your other controllers inherit it? Even better, put it in ApplicationController.

3

> And once you go down that road, that starts > looking like the more purely OO approach of just having the model > handle all of it's own output. Could/should the model be able to just > swallow the whole responds_to block

Rails follows a strict MVC pattern.

I know. :wink: I'm just not sparing sacred cows (which even Rails does have) in my head and trying to work out how much can I simplify things, for myself. And I thought I'd see if any movers or shakers planned the trend the way I, an outside observer had noticed it. It just feels like more and more is being pushed into fat models, so I was thinking, where is that line? to_xml is on the model. Well that's just another data representation, some will say, not really a view per se, so it's different. But to_rss belongs in the controller, not the view? How about to_atom, or to_xhmtl, or to_some_random_microformat.

I feel you are mixing "pure OO approach" with "less code, more magic". If you want for your controllers to suddenly become magical about resources, respond_to and stuff, why don't you just implement this in an abstract controller and have your other controllers inherit it? Even better, put it in ApplicationController.

I already did. :slight_smile: I really like how much my abstract Rest controller DRY'ed up my code. I just see a trend, and wonder where exactly it will stop. The move to rest is inarguably a move closer to network enabled models/objects. Maybe it won't go another inch in that direction. I'm not agitating for change or anything.

4

> > And once you go down that road, that starts > > looking like the more purely OO approach of just having the model > > handle all of it's own output. Could/should the model be able to just > > swallow the whole responds_to block > > Rails follows a strict MVC pattern. I know. :wink: I'm just not sparing sacred cows (which even Rails does have) in my head and trying to work out how much can I simplify things, for myself. And I thought I'd see if any movers or shakers planned the trend the way I, an outside observer had noticed it. It just feels like more and more is being pushed into fat models, so I was thinking, where is that line? to_xml is on the model. Well that's just another data representation, some will say, not really a view per se, so it's different. But to_rss belongs in the controller, not the view? How about to_atom, or to_xhmtl, or to_some_random_microformat.

> > I feel you are mixing "pure OO approach" with "less code, more magic". If > you want for your controllers to suddenly become magical about resources, > respond_to and stuff, why don't you just implement this in an abstract > controller and have your other controllers inherit it? Even better, put it > in ApplicationController.

I already did. :slight_smile: I really like how much my abstract Rest controller DRY'ed up my code. I just see a trend, and wonder where exactly it will stop. The move to rest is inarguably a move closer to network enabled models/objects. Maybe it won't go another inch in that direction. I'm not agitating for change or anything.

I put this kind of code in a presenter class, which in this case is implemented by Liquid Drops. I keep all the database code in the model (including associations and anything that references the db), and any view code in the Drop. It's not just useful for user-editable templates! With drops, you have to specify which fields are available to the view (take a look at how Mephisto does it), but you can also abstract/hide away all kinds of logic.

    class CartDrop < Liquid::Drop       .. snip ..       def subtotal         amount @cart.cart_items(true).subtotal       end

      def free_shipping?         @cart.voucher and @cart.voucher.free_shipping?       end     end

The controller ends up looking like

  @user = User.find_available params[:id]

and all the :include, :order and other code is hidden in the model.

In your case, to_xml would work on the drop, since it should to use fields made available to it, rather than all fields from the DB.

I'm still feeling around with this, too. :slight_smile:

5

Hey Courtenay,

I guess I'll have to take a closer look at mephisto, if only for another perspective in my ruminations. The risk of adding another layer is, of course, building until you recreate the very thing you were getting away from, but in someways having it more orthogonally specified as a presenter class might make sense. In classic MVC, if I recall my CS classes correctly, controllers were a little more than presentational tweak-and-load layers for the models.

Tim

6

I have a plugin that provides a layer of presenter classes that are
mapped to domain classes:

http://simply_presentable.richcollins.net/

7

Thanks, as well, Rich. So between this and drops it seems a favored way of handling this dichotomy of responsibilities is presenter classes of some sort. Well I suppose that looking to Martin Fowler for patterns in Rails should be expected. :wink:

Tim

8

Heh actually I wrote the code before I read Fowler’s article. I just got sick of helpers as they are not particularly OO. I started talking to people about the code and they pointed to me his article.

Learning that the concept had a name allowed me to change my plugin from the questionably named SimplyBeautiful to the more appropriate SimplyPresentable :stuck_out_tongue: