updated over 6 years ago; latest suggestion over 6 years ago
This proposal has been withdrawn...
Unwieldy templates (a.k.a. views) are all too common in Rails apps, even among teams that otherwise craft high-quality code. Being brought into or having to maintain a project with poorly-crafted templates leads to extreme frustration and less than-adequite-velocity. At _________, we have started to use a few simple patterns that result in templates that are easier to maintain. By investing a small amount of time up-front learning and applying these patterns we have saved countless hours in the long run.
- The Decorator Pattern
- Using View objects
- Sanely building forms
- And more!
Can the techniques you propose be applied to APIs, or is this primarily for HTML?
Just to echo Murray's comment really, I also wonder about template file arrangement. I feel like it should be better but I don't have any suggestions. We've also started using Cells and found them useful, but difficult to apply to an app retroactively.
I think it would be great to start with some of the things that make views unwieldy in your eyes. Is it just deeply nested partials and an abundance of helper methods, or is their something more?
Aside from the OOP things you've already suggested (decorator, view objects, etc...) have you any thoughts on template organisation? I have a feeling (that I haven't properly explored myself) that the standard arrangement of our template files (e.g. app/views/controller_name/action_name.html aided by app/views/controller_name/_model_name.html and app/views/shared/all_manner_of_things.html) maybe isn't that useful.
I'd like to understand whether there is anything particularly novel about your approach. How does your approach compare with some of the approaches listed here? And what are the main advantages and disadvantages?
Do you have an opinion or distinction between the "presenter" pattern and the "decorator" pattern? Is that interesting and/or worth touching upon?