and in template:
href="<!-- TMPL_VAR NAME="url" -->"
Paul's point is the same as I would like to make: using this method removes
the option for the template designer to use a form instead of a link. What
about leaving both options open? Have the script create the URL variable
but also make all the individual variables available for use?
<!-- TMPL_LOOP NAME="items" -->
<option value="<!-- TMPL_VAR NAME="value" -->" <!-- TMPL_VAR NAME="selected" -->><!-- TMPL_VAR
NAME="name" --></option>
<!-- /TMPL_LOOP -->
Paul, is this method translator-safe? I thought you had had difficulties
in the past with constructions like this?
In both cases, past practices have colored my attitude towards these
practices: Any time the script generates HTML, you run the risk of no
complying with the standard chosen by the template designer. This was a
problem when we were transitioning between HTML and XHTML. If we can all
agree on complying with XHTML transitional (at least), we just need to
follow the rules:
URLs which are generated by the script must include proper encoding of
ampersands (& instead of &)
"selected" attributes generated by the script must follow the rules of no
implied attributes: selected="selected"
So it comes down to three suggestions from me:
1. Make options available to the template designers.
2. Ensure that generated markup is XHTML compliant
3. Find out if we're breaking the translator script :)
-- Owen
_______________________________________________
Koha-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/koha-devel