in reply to Re^5: HTML - sharing design and logic
in thread HTML - separating design and logic
In this case, i don't think you should allow the designers to do that. Why? Have to answer that
one with another question: Why do they need to do that? I'll wager they have no valid,
good reason for it.
Many moons ago, samtregar
gave me a good piece of advice. There he pointed me to H::T FAQ #11, and since
Sam said it much better than i can, i will reprint his text here:
Q: What's the best way to create a <select> form element using HTML::Template?
A: There is much disagreement on this issue. My personal preference is to use CGI.pm's excellent popup_menu() and scrolling_list() functions to fill in a single <tmpl_var select_foo> variable.
To some people this smacks of mixing HTML and code in a way that they hoped HTML::Template would help them avoid. To them I'd say that HTML is a violation of the principle of separating design from programming. There's no clear separation between the programmatic elements of the <form> tags and the layout of the <form> tags. You'll have to draw the line somewhere - clearly the designer can't be entirely in charge of form creation.
It's a balancing act and you have to weigh the pros and cons on each side. It is certainly possible to produce a <select> element entirely inside the template. What you end up with is a rat's nest of loops and conditionals. Alternately you can give up a certain amount of flexibility in return for vastly simplifying your templates. I generally choose the latter.
Another option is to investigate HTML::FillInForm which some have reported success using to solve this problem.
For me, this means that you (the HTML designer) give me the list you want and i will make the
select for you.