The HTML form generation features of CGI will save your butt here, the popup_menu() method will remember the last selected value by default. The "sticky value" behavior is very cool.

my $menu=$q->popup_menu(
            -name=>"templates",
            -id=>"templates",
            -values=>["",23,36],
            -labels=>{""=>"Select . . .",23=>"Text One",36=>"Text Two"
+}
           );
[download]

You should also check out CGI::FormBuilder, which can automate a whole slew of form generation stuff, and use HTML::Template for output control.

Thanks, I did consider this, but I have this "thing" about keeping as much of the HTML as possible on the HTML side (but even Sam himself doesn't have this hang-up, and I quote from the H::T doc:

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

I guess if popup_menu() can help me avoid the mess of javascript/html/Perl then it might be worth a closer look.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

popup_menu() (and checkbox_group(), radio_group(), etc) can absolutely simplify your templates, on large forms you'll see a huge difference. Personally I haven't often had the need to edit form fields directly as HTML, because you can apply a class to the field and change much of it's appearance with CSS. Most field options are created off database queries, seldom are select/radio/check lists hardcoded.

I only use CGI.pm to parse values, print headers, handle uploads and create HTML Forms (though I've started to use CGI::FormBuilder for most of my forms). On trivial apps I'll use the HTML generation features, too. For me, I think this is CGI.pm's "highest and best" use- the tricky stuff that doesn't usually impact design is handled by a library that does it EXTREMELY well.

The way I think of it- you can absolutely save yourself time generating the HTML form fields with CGI, and in those cases where you just can't because of some design problem (which is pretty rare, in my experience), you can always fall back to manual form element generation. In the meantime, you've still come out ahead, with smart forms and saved effort.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.

My Biz

I like to duplicate the current selection on top of the list:

<select name="templates" id="templates">

<tmpl_if selected>
   <option value="<tmpl_var selected>"> <tmpl_var selected_text> </opt
+ion>
   <option disabled>---------</option>
<tmpl_else>
   <option value="">Select...</option>
</tmpl_if>
   
   <option value="23>">Text one</option>
   <option value="36>">Text two</option>
</select>
[download]

I've been able to make something like this work when both the value and text are the same, but not when they are different. Do you have a piece of Perl that can show me how you populate the params? Thanks


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

I've been able to make something like this work when both the value and text are the same, but not when they are different.

Okay, to do this, your Perl program needs to know about all the possible options (both values and labels). It could get these from a database or config file. Let's assume you have them like so

my $options = {
   23 => 'Text One',
   36 => 'Text Two',
};
[download]

then you can look up the label for the current selection.

Since you have all these options in your program or database now, it is a bad idea to duplicate them in the HTML template again. And since a select group typically needs no design at all (and if so that should be CSS anyway), I am inclined to agree with Hero Zzyzzx and recommend creating the whole HTML for the select in your program (for example with CGI.pm) and stuffing it into the template as is.

(Of course, you can also eliminate the duplication by stuffing all the options into a tmpl_loop, but, as has been pointed out, this makes your template more complex than it needs to be)