Re: [Koha-devel] template system abuse
I don't do a lot of hacking on koha, and I've never submitted a patch, though I do use it and am an avid follower of the development list. (I am a web application developer by trade though). So take this for what it's worth. It's a bad idea to generate ANY HTML in the code. Keep the presentation in the presentation layer (templates). No matter how obvious or useful a particular choice may seem now, it will cause you heartache down the road. Regarding the select box, Imagine that I as a template designer wanted to substitute a column of checkboxes or radio buttons for the select box. With the proposal below it would be impossible, yet that is merely a matter of presentation which should be able to be changed only by modifying the templates. Adequate objections have already been made to the fully constructed url. Good luck, and thank you all for a great, robust product. Keep making it more robust, don't make it less. Sincerely, Robert Flach Owen Leonard 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. 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 Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
This discussion made me think of a great article I read awhile back. http://www.massassi.com/php/articles/template_engines/ It's written about php, but is just as applicable to perl because there are apache mods to use perl just like php. I'm actually using the template style in the article for a project I'm working on. Kyle On 4/13/06, Robert Flach, Poet and Critic <webmaster@allauthors.com> wrote:
I don't do a lot of hacking on koha, and I've never submitted a patch,
though I do use it and am an avid follower of the development list. (I am a web application developer by trade though). So take this for what it's worth.
It's a bad idea to generate ANY HTML in the code. Keep the presentation in the presentation layer (templates). No matter how obvious or useful a particular choice may seem now, it will cause you heartache down the road.
Regarding the select box, Imagine that I as a template designer wanted to substitute a column of checkboxes or radio buttons for the select box. With the proposal below it would be impossible, yet that is merely a matter of presentation which should be able to be changed only by modifying the templates.
Adequate objections have already been made to the fully constructed url.
Good luck, and thank you all for a great, robust product. Keep making it more robust, don't make it less. Sincerely, Robert Flach
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
Owen Leonard wrote: 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 Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System
Hi koha-devel, On Thu, 13 Apr 2006 11:20:58 -0400 "Kyle Hall" <kyle.m.hall@gmail.com> wrote:
This discussion made me think of a great article I read awhile back.
This article is interesting. Here is how I understand and conclude about it: you can understand template engines two ways, the first way is to separate HTML code from scripting code (Perl, PHP, WhatYouWant), the second way is to separate business logic from presentation logic. If you want to separate HTML and Perl, you need a basic template engine with var replacement and block iterations (no "if/else"). This is a good way to see templates for pure HTML designer. If you want to separate business logic from presentation logic, you need an advanced template engine: - conditionnal if/elsif/else - pagination systems - localized strings access For example the capacity to toggle lines color in a table. Such advanced template engines exist but many people think that you'd better use the scripting language, because it's useless to learn a new language and it degrades performances. Now returning to Koha, I think we have a template engine in the middle : we have if/else but no conditions and we clearly can't separate business logic from presentation logic ($toggle is one example but there are others). My personnal experience is to work with a very simple template engine, without if/else and it works fine. I've never participated in a project using an advanced template engine, so I can't really say if it is the solution to all presentation related problems. Bye -- Pierrick LE GALL INEO media system
Hi Robert, On Thu, 13 Apr 2006 10:03:09 -0500 "Robert Flach, Poet and Critic" <webmaster@allauthors.com> wrote:
Regarding the select box, Imagine that I as a template designer wanted to substitute a column of checkboxes or radio buttons for the select box. With the proposal below it would be impossible, yet that is merely a matter of presentation which should be able to be changed only by modifying the templates.
You're perfectly right, I had not think of this kind of customization :-/
Adequate objections have already been made to the fully constructed url.
What's your opinion about replacing links with form buttons?
Good luck, and thank you all for a great, robust product. Keep making it more robust, don't make it less.
That's the goal of everybody here :-) Hope you don't think I want to break anything. I want to improve based on my ideas and experience. If I say mistakes sometimes, no problem for recognizing it! Bye -- Pierrick LE GALL INEO media system
Robert, On Thu, 13 Apr 2006 10:03:09 -0500 "Robert Flach, Poet and Critic" <webmaster@allauthors.com> wrote:
It's a bad idea to generate ANY HTML in the code. Keep the presentation in the presentation layer (templates). No matter how obvious or useful a particular choice may seem now, it will cause you heartache down the road.
This remember a case were I didn't find any solution with template : N levels nested lists. <ul> <li>1 <ul> <li>1.1 <ul> <li>1.1.1</li> <li>1.1.2</li> </ul> </li> <li>1.2 <ul> <li>1.2.1</li> <li>1.2.2</li> </ul> </li> </ul> </li> <li>2</li> </ul> You don't know in advance the number of level. It can be 2 or 10. Is that feasible in a template engine? (not with simple template engine in my opinion). Personnaly, I resigned and coded it into PHP and gave an HTML string to the template. I'm not sure this case happens in Koha, but I think it's to easy to say "no HTML in script". Robert, you're opinion? (a solution for my problem?) -- Pierrick LE GALL INEO media system
participants (3)
-
Kyle Hall -
Pierrick LE GALL -
Robert Flach, Poet and Critic