Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^3: HTML - sharing design and logic

by hardburn (Abbot)
on Jul 01, 2004 at 13:13 UTC ( #371070=note: print w/replies, xml ) Need Help??

in reply to Re^2: HTML - sharing design and logic
in thread HTML - separating design and logic

Yes, you can do it that way, and many people do. It makes the templates really, really ugly. If there is a clean solution to this, I haven't seen it yet. Ironically, some of the cleanest ones I've seen involve creating the HTML on the Perl side (though usually with a backend module doing the actual HTML generation).

send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Replies are listed 'Best First'.
Re^4: HTML - sharing design and logic
by saskaqueer (Friar) on Jul 01, 2004 at 17:35 UTC
    It makes the templates really, really ugly.

    Depends on how you do it. Myself, I use Template Toolkit and right off the bat I created a widgets/ directory in my base template directory. This widgets directory contains a different template for each of the form fields (text inputs, textareas, radio buttons, select fields, etc). My select field template is exactly what is below. I'm not even sure now if the SET option.selected = '' line is needed. I think I had to add it because of some weird complication (perhaps the option.selected value wasn't being reset in each iteration of the loop?).

    [% USE HTML %] [% DEFAULT size = 1 %] <select name="[% HTML.escape(name) %]" size="[% size %]" class="frmSel +ect"> [% FOREACH option = options %] [% SET option.selected = ''; SET option.selected = ' selected="selected"' IF option.value = += selected; DEFAULT option.label = option.value; %] <option value="[% HTML.escape(option.value) %]"[% option.selected +%]>[% HTML.escape(option.label) %]</option> [% END %] </select>

    Now within any html template that wants to include a select field, all it takes it this simple include:

    [% INCLUDE widgets/select.tmpl name="fav_flavour" selected="$fav_flavour" options=[ { value => 'Chocolate', label => 'brown stuff' }, { value => 'Vanilla', label => 'plain stuff' }, { value => 'Strawberry', label => 'red stuff' } ] %]

      Myself, I use Template Toolkit . . .

      Increasing the complexity of the template isn't a real solution, because at that point you're no longer doing seperation of data and code, which is the whole point.

      send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Re^4: HTML - sharing design and logic
by BUU (Prior) on Jul 01, 2004 at 17:57 UTC
    Perhaps our standards of beauty differ, but:
    <select> <tmpl_loop name='options'> <option value='<tmpl_var val>' <tmpl_if selected > selected </ +tmpl_if> </option> </tmpl_loop> </select>
    Is that really so ugly?

      I was thinking of the situation where the HTML designer wanted to include the list statically:

      <select> <option value="1" <TMPL_IF option1>selected</TMPL_IF>>1</option> <option value="2" <TMPL_IF option2>selected</TMPL_IF>>2</option> <option value="3" <TMPL_IF option3>selected</TMPL_IF>>3</option> . . . </select>


      send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

        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'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.


        (the triplet paradiddle with high-hat)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://371070]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (2)
As of 2022-05-21 04:08 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (76 votes). Check out past polls.