Koha 3, new features local "includes" directory
Hello, During the dev_week, in May, we spoke of a new method to have personalized templates. the idea being to have something more easy to changes than a full theme of templates. It's very hard to keep a full set of templates uptodate, the difficulties we have with default & npl on rel_2_2 branch show clearly this ! HTML::Template is really smart : it contains a TMPL_INCLUDE pragma that can be used to import outside templates. The directories where the templates are taken from is defined when you open the template. We have divided our PROG templates in different conceptual parts : * the header, in doc_head_open.inc & doc_head_close.inc (we have 2 so we can put a <title> in it) * the main menu, in menus.inc * the module menu, in menu-modulename.inc. Each module (acquisition, cataloguing, authorities, circulation, members, serials, parameters, tools, reports...) has it's own included file. * the main part of the page : it's specific to each template. * the footer, in intranet-bottom.inc I just have added a systempreference, called "intranet_includes" that let you define the directory where the included files will be taken from. by default, it's the "includes" directory. BUT, if you modify the value to "includes_npl", you'll arrive to something that look like the npl templates (roughly, it's just a Proof of Concept). -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
On Fri, Aug 11, 2006 at 12:21:38PM +0200, Paul POULAIN wrote:
During the dev_week, in May, we spoke of a new method to have personalized templates. the idea being to have something more easy to changes than a full theme of templates. It's very hard to keep a full set of templates uptodate, the difficulties we have with default & npl on rel_2_2 branch show clearly this ! I agree 100% here :-)
We have divided our PROG templates in different conceptual parts :
* the header, in doc_head_open.inc & doc_head_close.inc (we have 2 so we can put a <title> in it) * the main menu, in menus.inc * the module menu, in menu-modulename.inc. Each module (acquisition, cataloguing, authorities, circulation, members, serials, parameters, tools, reports...) has it's own included file. * the main part of the page : it's specific to each template. * the footer, in intranet-bottom.inc
I just have added a systempreference, called "intranet_includes" that let you define the directory where the included files will be taken from. by default, it's the "includes" directory. BUT, if you modify the value to "includes_npl", you'll arrive to something that look like the npl templates (roughly, it's just a Proof of Concept). So is the idea that we have:
main.tmpl includes/doc_head_open.inc includes/doc_head_close.inc includes/menu_modulename.inc includes/intranet_bottom.inc Meaning that main.tmpl never changes with different templates, only the includes do? The problem I have with this it doesn't solve the biggest template problem I encounter. Many of my clients want to make minor label changes to various elements on a main page, or even remove elements. For instance, they want to change 'Catalog Search' to 'Search the Catalog'. Most of the other changes they want can be done with the new layout and color css files in rel_2_2 ... any ideas for solving this problem without having to maintain multiple tempaltes? Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
comments interfiled On Fri, August 11, 2006 5:16 pm, Joshua Ferraro wrote: [snip]
Meaning that main.tmpl never changes with different templates, only the includes do? The problem I have with this it doesn't solve the biggest template problem I encounter. Many of my clients want to make minor label changes to various elements on a main page, or even remove elements. For instance, they want to change 'Catalog Search' to 'Search the Catalog'. Most of the other changes they want can be done with the new layout and color css files in rel_2_2 ... any ideas for solving this problem without having to maintain multiple tempaltes?
During devel week, Joshua suggested the possibility of variablising all labels. Whether particular template elements are used or not can also be controlled by a variable as well. This would certainly address the issue of small changes and provide a better scheme for localising content by both institution and language. The namespace can specify an institution then a language. This should simultaneously provide user easier facility for selecting different language interfaces for each user. CMS systems generally provide this localisation method. Chris Cormack had raised the concern that this would lead to increased CPU usage. One of the reasons that CMS systems tend to be slower than static pages is the provision for extensive variablisation in CMS systems. We should always have the provision for templates with significantly different content and static labels for the library that must have such customisation. Most libraries are liable to find that increasing the CPU speed of the server or adding load balancing servers is much less expensive than maintaining a local set of templates for attaining the same server response times. The most cost effective choice for a particular library would depend upon the extent of customisation required relative to the standard template in relation to the size of that library's user base for CPU usage. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783
participants (3)
-
Joshua Ferraro -
Paul POULAIN -
Thomas Dukleth