Helpers and html/code separation

rubyonrails-talk
1

To what extent should one try to keep strings of HTML out of helper functions? Both .rhtml and helpers are in the view layer, so it would seem okay to include HTML in the helper function, which is after all trying to construct something to put the returned page. A cleaner separation could be obtained by having the helper function use partials-- but that could lead to a proliferation of very simple partials, and I wonder about the performance of having ERB code in an .rhtml file calling an helper rendering a partial, which might call another function in the helper....

Does anyone have a good rule of thumb for when HTML code should be moved into a partial?

Thanks,       --Paul

2

Paul E. G. Lynch wrote:

To what extent should one try to keep strings of HTML out of helper functions? Both .rhtml and helpers are in the view layer, so it would seem okay to include HTML in the helper function, which is after all trying to construct something to put the returned page. A cleaner separation could be obtained by having the helper function use partials-- but that could lead to a proliferation of very simple partials, and I wonder about the performance of having ERB code in an .rhtml file calling an helper rendering a partial, which might call another function in the helper....

Does anyone have a good rule of thumb for when HTML code should be moved into a partial?

Place HTML wherever you like so long as it passes these checks, in order:

- your colleagues approve - the HTML passes all tests - the code is clear and understandable - the code has the least possible duplication - the code has minimal methods & classes

Put the HTML, or whatever, wherever you like, so long as all your code passes all those checks.

Attempting to keep the HTML out of the model or controller layers is essentially a mind game - can we challenge ourselves to reduce excesses? Keeping methods short is a similar mind game. If you are indeed writing clean code, then the actual home site of various effects is less important, and of course much HTML will naturally gravitate to the View.

When I put HTML in the model, I generate it with Builder::XmlMarkup, so it's easy to refactor.