I kind of pushed it out early as I heard something called presenters were being considered. It was not really ready for external use, but I wanted to put it out there to join the impending conversation about OO helpers. I extracted it from an a real world application that we are developing. We are planning launch around April (still stealth at this point).
When I get some time, I will do the canonical blog example to showcase features of the plugin. The thing I am finding most useful is partial rendering based on type. In general, the plugin helps to align your application with CRUD even further. The name was internal - just didn't come up with anything else before I posted it. I am certainly open to advice and criticism. I think we need to move away from functional style helpers and toward a more OO solution. Rich On Dec 8, 2006, at 9:34 AM, Michael Schuerig wrote: > > On Friday 08 December 2006 10:44, [EMAIL PROTECTED] wrote: >> What we were talking about, was, the idea that models and views >> shouldn't really interact; rather, we could define an interface >> between the model and the view, similar to the way Liquid templates >> use a Drop to limit the fields to which you have access. >> >> The idea being, you could turn around the helpers so you're doing >> >> <%= @user.link %> rather than <%= link_to @user.name, >> user_path(@user) %> or whatever it is. > > I'm a bit wary of this idea. My first reaction was, hey, keep the > model > clean, that stuff doesn't belong there, put it somewhere else. But > then > I had to realize that this was a reflex borne from experience with > less > dynamic languages than Ruby. In contrast to Java et al., in Ruby it is > possible to attach presentation-specific methods to model objects > without conflating concerns. Allen Holub campaigned[*] for UI-aware > model objects in Java way back. Without success, and that's for the > better, IMHO. > > I've had a quick look at the simply beautiful plugin. My first > complaint > is that the name is as much presumptuous as it is vacuous. Lacking > docs > and tests, I was at a loss to get the gist of the code; "helper" > and "helperize" aren't good names either. The code is non-trivial, in > particular in the assumptions it makes on how things are going to be > used. > > So, I reserve judgment and won't jump from scepticism to condemnation. > Nonetheless, I think the most important task for people sporting this > approach is to present a convincing case of how it improves on the > current state. How about a couple of examples that demonstrate the > beauty of doing things your way? > > Michael > > [*] http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html > > -- > 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 -~----------~----~----~----~------~----~------~--~---
