Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: HTML - sharing design and logic

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


in reply to HTML - separating design and logic

No HTML tags should be in the Perl code

This is a nice dream. However, HTML won't allow it. The best example is in specifying an option in a select list:

<select name="options"> <option>1</option> <option>2</option> <!-- select this one --> <option>3</option> </select>

If HTML allowed you to make the selection in the select tag itself (like <select name="options" option="2">), then this wouldn't be a problem. As it is, there are numerous ways to solve the problem, none of which are particularly satisfying.

I haven't looked at XForms much (though I like what I have read about it), so I'm not sure if it fixes this problem.

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


Comment on Re: HTML - sharing design and logic
Select or Download Code
Re^2: HTML - sharing design and logic
by muba (Priest) on Jul 01, 2004 at 13:00 UTC
    Well, I'd say you could do this by placing the select tag within the template, then use a loop to place all the options and use the template's IF tag to insert the 'selected' keyword.

      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.

        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' } ] %]
        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?
Re^2: HTML - sharing design and logic
by cees (Curate) on Jul 01, 2004 at 17:47 UTC

    Select lists are simple to populate using HTML::FillInForm. Templates get cluttered up very quickly if you try to fill in forms using template tags. They also become much harder to validate (eg <input type="text" name="foo" value="<TMPL_VAR NAME="foo">" />). Also, if you allow the code to generate the form fields, then you remove the ability of the template designer to change the form fields.

    You may argue that HTML::FillInForm needs to have some HTML code in it in order to be able to fill in the HTML form. But it is effectively doing the same thing as a template parser, searching through the HTML for tags that it recognizes (ie HTML form fields), and altering them by assigning a value to the form field. It in no way limits what the template designer can do with the template (ie a select list could be replaced with a series of radio buttons without requiring any code changes, and without needing to alter or adjust any template tags for that matter).

    Of course HTML::FillInForm doesn't actually generate the form fields for you, but that is really the job of the Template anyway. In my templates I always try to statically define my form fields unless an option list is dynamically generated by the code. Then a simple loop will do (remember, there will always be some logic in your templates, but it should be display logic only).

    Separating code and HTML is easy. You just need to find the right toolset that works for you...

    - Cees

      Hmm this one is rather interesting!
      Thank you a lot!
      "2b"||!"2b";$$_="the question"
Re^2: HTML - sharing design and logic
by thraxil (Prior) on Jul 02, 2004 at 00:57 UTC

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (16)
As of 2014-08-27 21:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (253 votes), past polls