Hi koha-devel, Having worked on several intranet template, I've seen things that make me think we sometimes abuse of the HTML::Template toolkit. Apart from the pagination bar I added recently, I propose 2 examples: 1. URL creation =============== We want an URL like the following: "script.pl?key1=value1&key2=value2" To achieve this, I've seen : href="<!-- TMPL_VAR NAME="script_name" -->?firstkey=firstval&<!-- TMPL_LOOP NAME="url_params" --><!-- TMPL_VAR NAME="key" -->=<!-- TMPL_VAR NAME="val" -->&<!-- /TMPL_LOOP -->" (everything on a single line, of course... enjoy the unreadability of 345 characters per line) I really don't understand what we gain by building the URL in the template... while we could do this beautifuly in Perl code before sending to template: $template->param( url => $scriptname.'?'. .join( '&', map { $_->{key}.'='.$_->{val} } @field_data ), ); and in template: href="<!-- TMPL_VAR NAME="url" -->" 2. "selected" option in SELECT ============================== Each option of an HTML SELECT can be selected or not. Localization mecanism forbids to have a TMPL_IF inside the <option> tag. So we need something like: <!-- TMPL_LOOP NAME="items" --> <!-- TMPL_IF NAME="selected" --> <option value="<!-- TMPL_VAR NAME="value" -->" selected="selected"><!-- TMPL_VAR NAME="name" --></option> <!-- TMPL_ELSE --> <option value="<!-- TMPL_VAR NAME="value" -->"><!-- TMPL_VAR NAME="name" --></option> <!-- /TMPL_IF --> <!-- /TMPL_LOOP --> The risk of typo is not negligible, the template can become huge with many options (see koha/koha-tmpl/intranet-tmpl/prog/en/circ/circulation.tmpl to understand what I mean). Couldn't we simply have <!-- TMPL_LOOP NAME="items" --> <option value="<!-- TMPL_VAR NAME="value" -->" <!-- TMPL_VAR NAME="selected" -->><!-- TMPL_VAR NAME="name" --></option> <!-- /TMPL_LOOP --> With in Perl script: selected => (condition ? ' selected="selected"' : '') My conclusion... In my opinion, template system is useful for customization. The examples above are no customization, they make templates heavier, less readable... harder to customize. Do I miss something or do we really need complicated templates on given examples? Bye, -- Pierrick LE GALL INEO media system
Pierrick LE GALL a écrit :
Hi koha-devel, We want an URL like the following: "script.pl?key1=value1&key2=value2" vs href="<!-- TMPL_VAR NAME="url" -->"
at 1st glance, it sound OK to me. The only question could be : could some template designer have a reason to manage the various values separatly ? I see at least 1 case : when the template want to use a <form action> instead of a <a href> In this case, all parameters must be put as hidden input. But i'm not sure wether this case can happends, or if it's just a brain problem (cut a hair in 4 we say in french) ...
Couldn't we simply have <!-- TMPL_LOOP NAME="items" --> <option value="<!-- TMPL_VAR NAME="value" -->" <!-- TMPL_VAR NAME="selected" -->><!-- TMPL_VAR NAME="name" --></option> <!-- /TMPL_LOOP --> With in Perl script: selected => (condition ? ' selected="selected"' : '')
I don't see why this idea would cause problem. So, I'll adopt it unless someone show us it's a bad one ! -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)
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
Owen Leonard a écrit :
Paul, is this method translator-safe? I thought you had had difficulties in the past with constructions like this? So it comes down to three suggestions from me: 3. Find out if we're breaking the translator script :)
yes, this method is translator safe. the translator only hates <tmpl_if> INSIDE an html tag, like : <input <!-- tmpl_if name="xxx"-->type="hidden"<!-- tmpl_else-->type="text"<!-- /tmpl_if --> value="ttt"/> (in this case tmpl_if/else is inside an <input> -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)
On Thu, 13 Apr 2006 10:46:22 -0400 Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
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. [...]
You know my opinion on this subject: form button should not be used instead of links. A good template designer/writer (with HTML/CSS skills) can apply a style to HTML "A" element which could make it look very like a button. I'm far from being skilled in CSS, but do you think any librarian will find which is a button and which is a link on this screenshot? [1]
[...] What about leaving both options open? Have the script create the URL variable but also make all the individual variables available for use?
Well, it seems to be a huge work in my opinion. Do you suggest we do this for every href of a template? I don't say you proposition is not interesting, I believe it is not feasible.
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"
We could have to functions for this: make_URL and get_selected_string (returning 'selected="selected"'). Example of make_URL usage: my $url = make_url( 'script.pl', [ {key => 'key1', val => 'val1'}, {key => 'key2', val => 'val2'}, {key => 'key3', val => 'val3'}, ] ); => script.pl?key1=val1&key2=val2&key3=val3 [1] http://le-gall.net/pierrick/images/koha-link_or_button.png -- Pierrick LE GALL INEO media system
[...] What about leaving both options open? Have the script create the URL variable but also make all the individual variables available for use?
Well, it seems to be a huge work in my opinion. Do you suggest we do this for every href of a template? I don't say you proposition is not interesting, I believe it is not feasible.
I make my suggestion assuming that the creation of the URL variable is the additional work that will be necessary. We're already using the other method. So if we want to /add/ something to the mix it's not extra work to leave the other stuff in place ... is it? -- Owen
On Thu, 13 Apr 2006 11:46:57 -0400 Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
[...] What about leaving both options open? Have the script create the URL variable but also make all the individual variables available for use?
Well, it seems to be a huge work in my opinion. Do you suggest we do this for every href of a template? I don't say you proposition is not interesting, I believe it is not feasible.
I make my suggestion assuming that the creation of the URL variable is the additional work that will be necessary. We're already using the other method. So if we want to /add/ something to the mix it's not extra work to leave the other stuff in place ... is it?
I didn't think my proposition as a replacement for existing templates. I was thinking of next screens or redesigned screens. As in the make_URL function I propose, we give the list of key/value parameters, no extra work to add it to template params :-). my $url_base = 'script.pl'; my $url_params = [ {key => 'key1', val => 'val1'}, {key => 'key2', val => 'val2'}, {key => 'key3', val => 'val3'}, ]; $template->param( url => make_url( $url_base, $url_params ), base_url => $url_base, url_params => $url_params, ); Owen, would that be a solution for new or renewed templates? -- Pierrick LE GALL INEO media system
participants (3)
-
Owen Leonard -
Paul POULAIN -
Pierrick LE GALL