> Because there's really no other way to do it, short of assigning every > model method call to a separate controller variable -- and that's just > plain silly. > No it's not. One way to fix this headache could be to add 1 more layer to the MVC that get's tied to the model and handles the rendering of an object. Yeah I know view creeps in the model, but it's in a separate file to not clutter the true business logic.
Instead of: <%= user.login %> <%= user.age %> We could call: <%= user.display %> So that attributes change only in 2 locations (Model and ModelRender) instead of 100 different places. Does anyone already use such solution? How does it work out? Is it better or worse than before? I got that idea for the book Hollub on Patterns. I'm wondering if the 4th layer of MVC wouldn't get out of control with 200 methods for each view in the app. There is also another idea using a kind of Presenter Pattern, but I didn't get it right. Moreover I figured out that most my views look very similar so finding a solution to abstract the rendering from the object would be super cool, and that's where a Presenter could come in handy if used right (I'm not talking about Django's AutoAdmin!) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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-talk?hl=en -~----------~----~----~----~------~----~------~--~---
