Thanks for the links. I think it would be fair to characterize the objects created by my plugin as "Presenters". They generate data (html markup) related to the presentation of the models without explicit instructions regarding the layout (css).
I see that people are going to be hung up on the fact that the forwarding code is on the model instead of on the presenter. I don't think it would be terribly hard to reverse this, so that messages not handled by the presenter are forwarded to the model. Perhaps that would assuage some of the concerns raised here. There is always the option to expose the model through an accessor as well (I would get tired of chaining the messages but I'm lazy :/). Rich On Dec 8, 2006, at 1:32 PM, Rob Sanheim wrote: > > On 12/8/06, Courtenay <[EMAIL PROTECTED]> wrote: >> FWIW, I didn't say to put extra methods in the model. Hell no. >> >> I was suggesting a layer between the model (or models) and the view >> which packages up certain methods, much like Liquid's Drops. > > Thats essentially what the presenter pattern is, I believe. So I > think you guys are talking about the same thing, its just a matter of > implementation. I just ask to make it very easily testable w/i the > core framework -- helper_test_case is still somewhat of a hack. I > think each layer should be testable out of the box, and right now > helpers are lacking in that respect. > > related: > http://jayfields.blogspot.com/2006/09/rails-model-view-controller- > presenter.html > http://www.martinfowler.com/eaaDev/PresentationModel.html > > - rob > > > --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
