> I don't think so. Presenters and Presentation Models correspond to a > single view from which they extract as much "intelligence" as > possible.
I often use sub-classes of ActiveRecordHelper for specific model classes. > Above that, there is another layer that adds the same set of helper > methods to all AR instances indiscriminately and another set of > methods > to arrays. Not quite indiscriminately, only to instance variables exposed to the views as well as locals exposed to partials. > If indeed no > more flexibility is needed, then it would be a lot simpler to mix-in > the helper methods into ActiveRecord::Base and Array and be done with > it. OTOH, if there is a need to potentially have different > implementations of helper methods, then the existing flexibility could > be put to use. I suppose I am more hung up on keeping the model clean than I need be. I wanted to change AR Objects as little as possible to reduce the possibility of conflicts (protected and private methods on presenters). It would be simpler to just use a module that gets mixed into the model's class, and would probably be safe in most cases. I am interested to see how Liquid Drops work to see if that would be a more appropriate alternative. Rich On Dec 8, 2006, at 6:45 PM, Michael Schuerig wrote: > > On Saturday 09 December 2006 00:16, Rich Collins wrote: >> Thanks for the links. I think it would be fair to characterize the >> objects created by my plugin as "Presenters". > > I don't think so. Presenters and Presentation Models correspond to a > single view from which they extract as much "intelligence" as > possible. > Whereas your plugin adds very generic presentation functionality to > model objects/classes. (Yes, I know that the methods are not > technically added to the model, but forwarding amounts to the same.) > >> 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. > > Not me. I think it is worthwhile to explore extending model objects > with > view-specific code, *if* at the same time the different concerns of > presentation and business logic can be kept separate. > > In the meantime I had a closer look at the code included with your > original message. There are two layers: A lower layer consisting of > Helpable, Helper, and supporting extensions to the functionality of > ActionView and ActionController. Basically, this layer allows to add > methods to each individual(!) model object assigned in a template. > Above that, there is another layer that adds the same set of helper > methods to all AR instances indiscriminately and another set of > methods > to arrays. > > What sticks out is an imbalance between the flexibility provided by > the > lower layer and what little of it the higher layer uses. If indeed no > more flexibility is needed, then it would be a lot simpler to mix-in > the helper methods into ActiveRecord::Base and Array and be done with > it. OTOH, if there is a need to potentially have different > implementations of helper methods, then the existing flexibility could > be put to use. > > Michael > > -- > Michael Schuerig > mailto:[EMAIL PROTECTED] > http://www.schuerig.de/michael/ > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
