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? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/11/07, Tim Connor <timocratic@gmail.com> wrote:> > > 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 blockRails 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 designedto 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 11, 2:35 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com> wrote:> On 4/11/07, Tim Connor <timocra...@gmail.com> wrote: > > > > > 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 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. :) 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> > > 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 > 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. :) 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. :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Apr 11, 3:42 pm, Courtenay <court3...@gmail.com> wrote:> > > > 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 > > 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. :) 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. :)--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I have a plugin that provides a layer of presenter classes that are mapped to domain classes: http://simply_presentable.richcollins.net/ On Apr 11, 2007, at 7:43 PM, Tim Connor wrote:> > 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 > > On Apr 11, 3:42 pm, Courtenay <court3...@gmail.com> wrote: >>>>> 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 >>> 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. :) 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. :) > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. ;) Tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 :P On Apr 12, 2007, at 6:32 PM, Tim Connor wrote:> way of handling this dichotomy of responsibilities is presenter--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---