Musings - how thin can controllers go

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?

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.

> 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.

> > 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:

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

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

http://simply_presentable.richcollins.net/

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

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: