> > 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. 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
> 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. 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 ..
@cart.voucher and @cart.voucher.free_shipping?
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.