Hi Everyone, It seems that everyone had a email conversation about the way templating is being done in koha. I have been working on templating the opac. Let me explain what I have done, which is not to say that it is the right way :-) Firstly I should point out that I have been developing on the rel-1-2 branch, but will probably merge this into the 1.3 release. If you want to go and check it out go to http://opacdev.katipo.co.nz you can login using user:pword = frank:frank or finlay:finlay CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly. And then we have the structure: <theme>/<lang>/<scriptname>.tmpl I suggest that we try hard to keep the templates and scripts with the same names..... includes and images go under the <theme>/<lang>/ directory..... An example: The opac-search.pl script presents the search form in the opac. see: http://opacdev.katipo.co.nz/cgi-bin/koha/opac-search.pl it calls the opac-search.tmpl template which in this instance is found in the default/en/ theme and language. There is an include at the top: cat-top.inc and this is found in default/en/includes/cat-top.inc all the images in the templates are prefixed by the HTML::Template tag: <TMPL_VAR NAME="themelang"> eg. src="<TMPL_VAR NAME='themelang'>/images/search-button.gif" This template variable is automatically passed to includes and is automatically loaded into the template by the template loading subroutine..... Template loading: The relevant code in opac-search.pl is: use C$::Output; my $template = gettemplate("opac-search.tmpl", "opac"); The method gettemplate handles eveything about choosing theme and lang settings and finding a template etc. It then loads the "themelang" variable and returns the template. The "opac" string is simply to switch to the opac tree. however in the future this gettemplate method could perhaps be made to take a hash of options? Note: there is another candidate for the gettemplate code that Dorian wrote. His subroutine is called "pathtotemplate" and does many of the same things, except it doesnt actually intialise the template. I think that keeping the template intialising code to one line is a good idea, and I dont think there is any loss of flexibility if I allow gettemplate to pass a hash of options to the HTML::Template module. I like what andrew said with regard to something else the other day: "This way, simple scripts remain simple, and complex scripts become possible." That is a very good principle. As most of the time the scripts have one template associated, and no extra options on the template, the above one-liner will be enough. Anyway, I hope this has clarified what I have been up to. I will update the reading material on: http://koha.org/contribute/templating/ Finlay
On 2 Oct 2002, Finlay Thompson wrote:
I like what andrew said with regard to something else the other day:
"This way, simple scripts remain simple, and complex scripts become possible."
In the interest of honesty, I should point out that this isn't really my line. I believe I first ran across it in an article on UIs by Tom Christiansen (ask Google about "Interface Zen" or some such). -- Andrew Arensburger Actually, these _do_ represent the arensb@ooblick.com opinions of ooblick.com! Generic Tagline V 6.01
Finlay Thompson wrote:
i Everyone,
It seems that everyone had a email conversation about the way templating is being done in koha. I have been working on templating the opac. Let me explain what I have done, which is not to say that it is the right way :-)
Firstly I should point out that I have been developing on the rel-1-2 branch, but will probably merge this into the 1.3 release.
Did you commit it ? I'm not sure, i see almost nothing. If you've commited, let me know how many (and which) files are in the CVS.
If you want to go and check it out go to http://opacdev.katipo.co.nz you can login using user:pword = frank:frank or finlay:finlay
CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly.
OK, that's clear. Hope everybody reads this.
And then we have the structure: <theme>/<lang>/<scriptname>.tmpl I suggest that we try hard to keep the templates and scripts with the same names.....
not try very hard, but MUST...
includes and images go under the <theme>/<lang>/ directory.....
An example: The opac-search.pl script presents the search form in the opac. see: http://opacdev.katipo.co.nz/cgi-bin/koha/opac-search.pl
it calls the opac-search.tmpl template which in this instance is found in the default/en/ theme and language.
There is an include at the top: cat-top.inc and this is found in default/en/includes/cat-top.inc all the images in the templates are prefixed by the HTML::Template tag: <TMPL_VAR NAME="themelang"> eg. src="<TMPL_VAR NAME='themelang'>/images/search-button.gif" This template variable is automatically passed to includes and is automatically loaded into the template by the template loading subroutine.....
Nice, fast and clear. Great.
Template loading: The relevant code in opac-search.pl is:
use C$::Output; my $template = gettemplate("opac-search.tmpl", "opac");
So, the picktempate sub can be dropped (in Output.pm from both 1.2 and main branch) ? and most templated scripts must be touched (1-2 line modify)
I will update the reading material on: http://koha.org/contribute/templating/
Finlay
Looking at your code (v1.2) show : * we must add 2 rows in systempref table : -> opaclanguages -> opacthemes (note : why having opac and not intranet ?) * we must add 2 lines in the config file : -> opachtdocs -> intrahtdocs Am I right ? If yes, then, you're the templating coordinator, so I agree, and will soon move already templated scripts to the good directory structure. But i'll wait for your confirmation (am i right ? is there scripts that you still haven't commit ?) -- Paul
Hi Paul, I just had a quick look over your comments. Sounds like the go ahead. I'll write more tomorrow when Im a bit fresher, its real late here now. Finlay On Wed, 2002-10-02 at 20:35, paul POULAIN wrote:
Finlay Thompson wrote:
i Everyone,
It seems that everyone had a email conversation about the way templating is being done in koha. I have been working on templating the opac. Let me explain what I have done, which is not to say that it is the right way :-)
Firstly I should point out that I have been developing on the rel-1-2 branch, but will probably merge this into the 1.3 release.
Did you commit it ? I'm not sure, i see almost nothing. If you've commited, let me know how many (and which) files are in the CVS.
If you want to go and check it out go to http://opacdev.katipo.co.nz you can login using user:pword = frank:frank or finlay:finlay
CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly.
OK, that's clear. Hope everybody reads this.
And then we have the structure: <theme>/<lang>/<scriptname>.tmpl I suggest that we try hard to keep the templates and scripts with the same names.....
not try very hard, but MUST...
includes and images go under the <theme>/<lang>/ directory.....
An example: The opac-search.pl script presents the search form in the opac. see: http://opacdev.katipo.co.nz/cgi-bin/koha/opac-search.pl
it calls the opac-search.tmpl template which in this instance is found in the default/en/ theme and language.
There is an include at the top: cat-top.inc and this is found in default/en/includes/cat-top.inc all the images in the templates are prefixed by the HTML::Template tag: <TMPL_VAR NAME="themelang"> eg. src="<TMPL_VAR NAME='themelang'>/images/search-button.gif" This template variable is automatically passed to includes and is automatically loaded into the template by the template loading subroutine.....
Nice, fast and clear. Great.
Template loading: The relevant code in opac-search.pl is:
use C$::Output; my $template = gettemplate("opac-search.tmpl", "opac");
So, the picktempate sub can be dropped (in Output.pm from both 1.2 and main branch) ? and most templated scripts must be touched (1-2 line modify)
I will update the reading material on: http://koha.org/contribute/templating/
Finlay
Looking at your code (v1.2) show : * we must add 2 rows in systempref table : -> opaclanguages -> opacthemes (note : why having opac and not intranet ?)
* we must add 2 lines in the config file : -> opachtdocs -> intrahtdocs
Am I right ? If yes, then, you're the templating coordinator, so I agree, and will soon move already templated scripts to the good directory structure. But i'll wait for your confirmation (am i right ? is there scripts that you still haven't commit ?) -- Paul
Finlay Thompson wrote: [--snip--] Paul POULAIN wrote:
CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly.
OK, that's clear. Hope everybody reads this.
To help keep the folder stucture "meaningful", can I request that we place all templates in their own subdirectory... such as: koha/intra/htdocs/templates/
And then we have the structure: <theme>/<lang>/<scriptname>.tmpl
... and similarly templates/<theme>/<lang>/<scriptname>.tmpl [--snip--] R.
Roger Buck wrote:
Finlay Thompson wrote: [--snip--]
Paul POULAIN wrote:
CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly.
OK, that's clear. Hope everybody reads this.
To help keep the folder stucture "meaningful", can I request that we place all templates in their own subdirectory... such as:
koha/intra/htdocs/templates/
How about stylesheets associated with a template? Should stylesheets be placed in: koha/opac/htdocs/styles/<theme>/<theme>.css ... or maybe ... koha/opac/htdocs/templates/<theme>/<theme>.css ... or some other location? I am also wondering about a policy for location of javascripts, maybe something like: koha/opac/htdocs/templates/<theme>/<theme>.js Any ideas? R.
Roger Buck schrieb:
How about stylesheets associated with a template?
Should stylesheets be placed in:
koha/opac/htdocs/styles/<theme>/<theme>.css
... or maybe ...
koha/opac/htdocs/templates/<theme>/<theme>.css
... or some other location?
I am also wondering about a policy for location of javascripts, maybe something like:
koha/opac/htdocs/templates/<theme>/<theme>.js
Any ideas?
My ideas: 1st: koha/opac/htdocs is not true for everybody, I'd prefer to say serverroot. 2nd: The designer of a theme has his/her theme-directory as a theme-root. All theme related data resides below this directory. All language-specific theme data goes in <theme>/<language>/ . All language-independent theme data goes in <theme>/all/ . 3rd: For the ease of theme-design a 'templates'-subdirectory below htdocs (or public_html) makes no sense. We still are lacking a decision wether to mix the templates with the rest of the website-stuff or not. In my opinion storing the templates together with images, css and so on is not a big problem but it increases the html-like-aproach to designin a theme (some tags in the html get replaced automatically by the scripts). I think this is what html::template was made for. dorian
I am attempting to create a new theme for purpose of creating a "Koha theme howto" document. 1. I am using Steve's RC14 as the base distribution - is that OK? 2. I need to know how the theme variable is set. Do I need to create a new table... do I need to creata a new entry in ssytempreferences (if so, then what syntax)... do I need to make an entry in koha conf (if so then what syntax) or should I make a temporary entry in Output.pm... or should I do something else? 3. I need to create a structure to hold templates and related content. I am asking for specific guidance on 1 and 2 above. Following Dorian's response below, I am seeking general guidance on two other points: 4. Where to place all supplementary files associated with a particular theme. 5. What design approach to use with themes My understanding is that the reason for using using HTML::Template is mainly to "separate design - the HTML - from the data, which you generate in a Perl script" ...and.. "it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better." [1] http://www.perldoc.com/cpan/HTML/Template.html Based on the above, I assumed that designing a theme is little different to designing "normal" HTML. Based on Dorinas comments below about "html-like-aproach to designing a theme", it seems that themes may require a different design methodology? Dorian Meid wrote:
Roger Buck schrieb:
How about stylesheets associated with a template?
Should stylesheets be placed in:
koha/opac/htdocs/styles/<theme>/<theme>.css
... or maybe ...
koha/opac/htdocs/templates/<theme>/<theme>.css
... or some other location?
I am also wondering about a policy for location of javascripts, maybe something like:
koha/opac/htdocs/templates/<theme>/<theme>.js
Any ideas?
My ideas:
1st: koha/opac/htdocs is not true for everybody, I'd prefer to say serverroot.
2nd: The designer of a theme has his/her theme-directory as a theme-root. All theme related data resides below this directory. All language-specific theme data goes in <theme>/<language>/ . All language-independent theme data goes in <theme>/all/ .
3rd: For the ease of theme-design a 'templates'-subdirectory below htdocs (or public_html) makes no sense.
Why not?
We still are lacking a decision wether to mix the templates with the rest of the website-stuff or not.
OK... What are the advantages/disadvantages of storing templates with the rest of the website-stuff compared with other location?
In my opinion storing the templates together with images, css and so on is not a big problem but it increases the html-like-aproach to designin a theme (some tags in the html get replaced automatically by the scripts). I think this is what html::template was made for.
I have tried a few Google searches on designing with HTML::Template but have not found anything useful - Can anyone please suggest any links to more information? R.
Replying (long) to himself! Roger Buck wrote:
I am attempting to create a new theme for purpose of creating a "Koha theme howto" document.
Please see first draft of the documentation on wiki (OK Nick?): http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo All are invited to add/delete/modify as they see fit. Thoughts so far: Important to standardise file structure ASAP (my usual hobby-horse!) I have trialled most of these ideas from Dorian: Dorian Meid wrote:
1st: koha/opac/htdocs is not true for everybody, I'd prefer to say serverroot.
2nd: The designer of a theme has his/her theme-directory as a theme-root. All theme related data resides below this directory. All language-specific theme data goes in <theme>/<language>/ . All language-independent theme data goes in <theme>/all/ .
3rd: For the ease of theme-design a 'templates'-subdirectory below htdocs (or public_html) makes no sense. We still are lacking a decision wether to mix the templates with the rest of the website-stuff or not.
After trialing, all of the above now makes much more sense to me - Thanks Dorian, I agree.
In my opinion storing the templates together with images, css and so on is not a big problem but it increases the html-like-aproach to designin a theme (some tags in the html get replaced automatically by the scripts). I think this is what html::template was made for.
I still am not convinced about the last paragraph. From my trials , use of .css seems to offer some major advantages. I also see advantage to storing templates along with everything else in a single tree structure in the webspace? - see wiki for example code simplification when using .css combined with HTML::Template. As I NOW see it, the web space file system might look like: <serverroot>/<theme><lang>/ ./images ./includes ./styles ./jscripts ./help ./catalogue ./members ./whatever... This means that each theme is effectively almost a virtual server in terms of file structure (I think I have this right Dorian?). This would require a change in current CVS thinking. I know there are arguments in support of alternative structure(s)... but I have no specific information to work on. Suggestions are invited as I would like to trial them. I have constructed an embryonic trial site for this stuff at: http://www.library.nsw.org.au/ Please bear in mind that this is just purely alpha and I only get limited opportunity to work on this.... but I will try and make time to develop it so I can trial any suggestions that come in over over next few days :) Don't forget that the main link to Koha Templating is at: http://koha.org/contribute/templating/ I am still hoping to get some feedback on the following: Roger Buck wrote:
1. I am using Steve's RC14 as the base distribution - is that OK?
2. I need to know how the theme variable is set. Do I need to create a new table... do I need to creata a new entry in ssytempreferences (if so, then what syntax)... do I need to make an entry in koha conf (if so then what syntax) or should I make a temporary entry in Output.pm... or should I do something else?
3. I need to create a structure to hold templates and related content.
I am asking for specific guidance on 1 and 2 above.
Following Dorian's response below, I am seeking general guidance on two other points:
4. Where to place all supplementary files associated with a particular theme.
5. What design approach to use with themes
My understanding is that the reason for using using HTML::Template is mainly to "separate design - the HTML - from the data, which you generate in a Perl script" ...and.. "it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better." [1] http://www.perldoc.com/cpan/HTML/Template.html
Based on the above, I assumed that designing a theme is little different to designing "normal" HTML. Based on Dorinas comments below about "html-like-aproach to designing a theme", it seems that themes may require a different design methodology? [--snip--]
R.
Roger Buck wrote:
Replying (long) to himself! Roger Buck wrote:
I am attempting to create a new theme for purpose of creating a "Koha theme howto" document.
Please see first draft of the documentation on wiki (OK Nick?): http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo All are invited to add/delete/modify as they see fit.
Thoughts so far: Important to standardise file structure ASAP (my usual hobby-horse!) I have trialled most of these ideas from Dorian:
Finlay is our Templates Manager. I think he should say what he thinks of those suggestions, and choose which seems the best to him. About css, we've decided, a few months ago to separate Templating and CSS'ing koha. 1st we "template", then it could be possible to rewritte the "default" theme with css and full html4 compliance. -- Paul
Roger Buck schrieb: > Please see first draft of the documentation on wiki (OK Nick?): > > http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo > > All are invited to add/delete/modify as they see fit. cool, a few comments: 1. It's nice to have the themelang-variable, but you don't need it necessarily. If you template is in /children/es you images will be there too (assuming a setup with your dirs as below) 2. I'd prefer intranet-serverroot and opac-serverroot than koha/intra/htdocs/ and koha/opac/htdocs/. 3. The includes via ssi are getting replaced by includes via HTML::Template <TMPL_INCLUDE NAME=...> > Important to standardise file structure ASAP (my usual hobby-horse!) agree > > In my opinion storing the templates together with images, css and so on > > is not a big problem but it increases the html-like-aproach to designin > > a theme (some tags in the html get replaced automatically by the > > scripts). I think this is what html::template was made for. > > I still am not convinced about the last paragraph. From my trials , use > of .css seems to offer some major advantages. I also see advantage to > storing templates along with everything else in a single tree structure > in the webspace? - see wiki for example code simplification when using > .css combined with HTML::Template. Right, maybe my english is too bad, but this is what I thought. Your css-example to deal with intranet/opac is a little bit early. .css are nice, but we have to improve the designing-process step by step. For now all I want to do is to templatify all the koha-scripts. > > As I NOW see it, the web space file system might look like: > > <serverroot>/<theme><lang>/ > ./images > ./includes > ./styles > ./jscripts > ./help > ./catalogue > ./members > ./whatever... > > This means that each theme is effectively almost a virtual server in > terms of file structure (I think I have this right Dorian?). This would > require a change in current CVS thinking. Exactly as I see it. I'd love to hear Finlay's ok for this. > I am still hoping to get some feedback on the following: > > Roger Buck wrote: > > 1. I am using Steve's RC14 as the base distribution - is that OK? Sorry, don't know, since i'm working with the latest cvs-files for quite a while now. > > > > 2. I need to know how the theme variable is set. Do I need to create a > > new table... do I need to creata a new entry in ssytempreferences (if > > so, then what syntax)... do I need to make an entry in koha conf (if so > > then what syntax) or should I make a temporary entry in Output.pm... or > > should I do something else? At the moment you have to set a vaiable in the systempreferences. Name=opacthemes Value=theme1 theme2 theme3 ... you have to specify at least one theme The name OPACthemes is a little confusing as it is even for the intranet dorian
Hi, Just a quick note to say that Finlay is traveling about a bit in the South of New Zealand (where there are lots of sheep but far fewer internet cafe's), and so he may not be able to answer as promptly as usual. Thanks for understanding cheers Rachel > > Roger Buck schrieb: > > Please see first draft of the documentation on wiki (OK Nick?): > > > > http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo > > > > All are invited to add/delete/modify as they see fit. > cool, a few comments: > 1. It's nice to have the themelang-variable, but you don't need it > necessarily. > If you template is in /children/es you images will be there too > (assuming a setup with your dirs as below) > 2. I'd prefer intranet-serverroot and opac-serverroot than > koha/intra/htdocs/ and koha/opac/htdocs/. > 3. The includes via ssi are getting replaced by includes via > HTML::Template <TMPL_INCLUDE NAME=...> > > > Important to standardise file structure ASAP (my usual hobby-horse!) > agree > > > > In my opinion storing the templates together with images, css and so on > > > is not a big problem but it increases the html-like-aproach to designin > > > a theme (some tags in the html get replaced automatically by the > > > scripts). I think this is what html::template was made for. > > > > I still am not convinced about the last paragraph. From my trials , use > > of .css seems to offer some major advantages. I also see advantage to > > storing templates along with everything else in a single tree structure > > in the webspace? - see wiki for example code simplification when using > > .css combined with HTML::Template. > Right, maybe my english is too bad, but this is what I thought. > > Your css-example to deal with intranet/opac is a little bit early. > .css are nice, but we have to improve the designing-process step by > step. > For now all I want to do is to templatify all the koha-scripts. > > > > > As I NOW see it, the web space file system might look like: > > > > <serverroot>/<theme><lang>/ > > ./images > > ./includes > > ./styles > > ./jscripts > > ./help > > ./catalogue > > ./members > > ./whatever... > > > > This means that each theme is effectively almost a virtual server in > > terms of file structure (I think I have this right Dorian?). This would > > require a change in current CVS thinking. > > Exactly as I see it. > > I'd love to hear Finlay's ok for this. > > > I am still hoping to get some feedback on the following: > > > > Roger Buck wrote: > > > 1. I am using Steve's RC14 as the base distribution - is that OK? > Sorry, don't know, since i'm working with the latest cvs-files for quite > a while now. > > > > > > 2. I need to know how the theme variable is set. Do I need to create a > > > new table... do I need to creata a new entry in ssytempreferences (if > > > so, then what syntax)... do I need to make an entry in koha conf (if so > > > then what syntax) or should I make a temporary entry in Output.pm... or > > > should I do something else? > At the moment you have to set a vaiable in the systempreferences. > Name=opacthemes > Value=theme1 theme2 theme3 ... > you have to specify at least one theme > The name OPACthemes is a little confusing as it is even for the intranet > > dorian > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel > _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
Thanks Rachel for the heads up. Before going "live" with any of this (either in the manual, or to the user community at large) I really think we should ... uh... harmonize? the various theme related info since we've got a lot of thoughts floating abt in re that and templating in general. It would be sub optimal I think to have people do themes which we then "broke" by changing the templating/etc.... On that thought, should we perhaps have an (IRC) sitdown on templating and themes only? Or do we have a consensus that I've just missed in the rounds of email? I'll confess to having lost the ability to sort out all the back and forth in the "templating design" and "we've got a winner" threads -- too many >s, I suspect :) Nick -----Original Message----- From: koha-devel-admin@lists.sourceforge.net [mailto:koha-devel-admin@lists.sourceforge.net]On Behalf Of Rachel Hamilton-Williams Sent: Monday, October 07, 2002 5:11 PM To: dnmeid@gmx.de; koha delvelopers; Finlay Thompson Subject: Re: [Koha-devel] Koha Themes Howto Hi, Just a quick note to say that Finlay is traveling about a bit in the South of New Zealand (where there are lots of sheep but far fewer internet cafe's), and so he may not be able to answer as promptly as usual. Thanks for understanding cheers Rachel > > Roger Buck schrieb: > > Please see first draft of the documentation on wiki (OK Nick?): > > > > http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo > > > > All are invited to add/delete/modify as they see fit. > cool, a few comments: > 1. It's nice to have the themelang-variable, but you don't need it > necessarily. > If you template is in /children/es you images will be there too > (assuming a setup with your dirs as below) > 2. I'd prefer intranet-serverroot and opac-serverroot than > koha/intra/htdocs/ and koha/opac/htdocs/. > 3. The includes via ssi are getting replaced by includes via > HTML::Template <TMPL_INCLUDE NAME=...> > > > Important to standardise file structure ASAP (my usual hobby-horse!) > agree > > > > In my opinion storing the templates together with images, css and so on > > > is not a big problem but it increases the html-like-aproach to designin > > > a theme (some tags in the html get replaced automatically by the > > > scripts). I think this is what html::template was made for. > > > > I still am not convinced about the last paragraph. From my trials , use > > of .css seems to offer some major advantages. I also see advantage to > > storing templates along with everything else in a single tree structure > > in the webspace? - see wiki for example code simplification when using > > .css combined with HTML::Template. > Right, maybe my english is too bad, but this is what I thought. > > Your css-example to deal with intranet/opac is a little bit early. > .css are nice, but we have to improve the designing-process step by > step. > For now all I want to do is to templatify all the koha-scripts. > > > > > As I NOW see it, the web space file system might look like: > > > > <serverroot>/<theme><lang>/ > > ./images > > ./includes > > ./styles > > ./jscripts > > ./help > > ./catalogue > > ./members > > ./whatever... > > > > This means that each theme is effectively almost a virtual server in > > terms of file structure (I think I have this right Dorian?). This would > > require a change in current CVS thinking. > > Exactly as I see it. > > I'd love to hear Finlay's ok for this. > > > I am still hoping to get some feedback on the following: > > > > Roger Buck wrote: > > > 1. I am using Steve's RC14 as the base distribution - is that OK? > Sorry, don't know, since i'm working with the latest cvs-files for quite > a while now. > > > > > > 2. I need to know how the theme variable is set. Do I need to create a > > > new table... do I need to creata a new entry in ssytempreferences (if > > > so, then what syntax)... do I need to make an entry in koha conf (if so > > > then what syntax) or should I make a temporary entry in Output.pm... or > > > should I do something else? > At the moment you have to set a vaiable in the systempreferences. > Name=opacthemes > Value=theme1 theme2 theme3 ... > you have to specify at least one theme > The name OPACthemes is a little confusing as it is even for the intranet > > dorian > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel > _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
I'm guessing that an irc session will be hard to put together given that we have .de, .us, .nz, and .au involved ... we certainly should try to unify the theme info and get everyone on the smae page. -pate On Mon, 7 Oct 2002, Nicholas S. Rosasco wrote: > Thanks Rachel for the heads up. > > Before going "live" with any of this (either in the manual, or to the user > community at large) I really think we should ... uh... harmonize? the > various theme related info since we've got a lot of thoughts floating abt in > re that and templating in general. It would be sub optimal I think to have > people do themes which we then "broke" by changing the templating/etc.... > > On that thought, should we perhaps have an (IRC) sitdown on templating and > themes only? Or do we have a consensus that I've just missed in the rounds > of email? I'll confess to having lost the ability to sort out all the back > and forth in the "templating design" and "we've got a winner" threads -- too > many >s, I suspect :) > > Nick > > > > > -----Original Message----- > From: koha-devel-admin@lists.sourceforge.net > [mailto:koha-devel-admin@lists.sourceforge.net]On Behalf Of Rachel > Hamilton-Williams > Sent: Monday, October 07, 2002 5:11 PM > To: dnmeid@gmx.de; koha delvelopers; Finlay Thompson > Subject: Re: [Koha-devel] Koha Themes Howto > > > Hi, Just a quick note to say that Finlay is traveling about a bit in the > South of > New Zealand (where there are lots of sheep but far fewer internet cafe's), > and > so he may not be able to answer as promptly as usual. > > Thanks for understanding > > cheers > Rachel > > > > > > Roger Buck schrieb: > > > Please see first draft of the documentation on wiki (OK Nick?): > > > > > > http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo > > > > > > All are invited to add/delete/modify as they see fit. > > cool, a few comments: > > 1. It's nice to have the themelang-variable, but you don't need it > > necessarily. > > If you template is in /children/es you images will be there too > > (assuming a setup with your dirs as below) > > 2. I'd prefer intranet-serverroot and opac-serverroot than > > koha/intra/htdocs/ and koha/opac/htdocs/. > > 3. The includes via ssi are getting replaced by includes via > > HTML::Template <TMPL_INCLUDE NAME=...> > > > > > Important to standardise file structure ASAP (my usual hobby-horse!) > > agree > > > > > > In my opinion storing the templates together with images, css and so > on > > > > is not a big problem but it increases the html-like-aproach to > designin > > > > a theme (some tags in the html get replaced automatically by the > > > > scripts). I think this is what html::template was made for. > > > > > > I still am not convinced about the last paragraph. From my trials , use > > > of .css seems to offer some major advantages. I also see advantage to > > > storing templates along with everything else in a single tree structure > > > in the webspace? - see wiki for example code simplification when using > > > .css combined with HTML::Template. > > Right, maybe my english is too bad, but this is what I thought. > > > > Your css-example to deal with intranet/opac is a little bit early. > > .css are nice, but we have to improve the designing-process step by > > step. > > For now all I want to do is to templatify all the koha-scripts. > > > > > > > > As I NOW see it, the web space file system might look like: > > > > > > <serverroot>/<theme><lang>/ > > > ./images > > > ./includes > > > ./styles > > > ./jscripts > > > ./help > > > ./catalogue > > > ./members > > > ./whatever... > > > > > > This means that each theme is effectively almost a virtual server in > > > terms of file structure (I think I have this right Dorian?). This would > > > require a change in current CVS thinking. > > > > Exactly as I see it. > > > > I'd love to hear Finlay's ok for this. > > > > > I am still hoping to get some feedback on the following: > > > > > > Roger Buck wrote: > > > > 1. I am using Steve's RC14 as the base distribution - is that OK? > > Sorry, don't know, since i'm working with the latest cvs-files for quite > > a while now. > > > > > > > > 2. I need to know how the theme variable is set. Do I need to create a > > > > new table... do I need to creata a new entry in ssytempreferences (if > > > > so, then what syntax)... do I need to make an entry in koha conf (if > so > > > > then what syntax) or should I make a temporary entry in Output.pm... > or > > > > should I do something else? > > At the moment you have to set a vaiable in the systempreferences. > > Name=opacthemes > > Value=theme1 theme2 theme3 ... > > you have to specify at least one theme > > The name OPACthemes is a little confusing as it is even for the intranet > > > > dorian > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/koha-devel > > > > > _____________________________________________________________ > > Rachel Hamilton-Williams Katipo Communications > WEBMISTRESS ph 021 389 128 or +64 04 934 1285 > mailto:rachel@katipo.co.nz PO Box 12487, Wellington > http://www.katipo.co.nz New Zealand > Koha Open Source Library System > http://www.koha.org > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel >
Pat Eyler wrote:
we certainly should try to unify the theme info and get everyone on the same page.
It might not seem so but if you remove all the "noise", there does already seem to be a very high level of consensus about the direction of Koha templating :) I have placed what I think is most useful recent template specific email stuff here: http://www.saas.nsw.edu.au/wiki/index.php?action=save&page=ThemeNotes which links back to: http://www.saas.nsw.edu.au/wiki/index.php?action=save&page=ThemeHowTo There is probably lots of stuff I have missed - As usual, open to anyone to modify as you see fit. R.
Roger Buck wrote: Big apologies - Got my "copy and paste" wrong in previous links: [--snip--]
I have placed what I think is most useful recent template specific email stuff here: [--snip--]
Should have been: http://www.saas.nsw.edu.au/wiki/index.php?ThemeNotes
which links back to:
http://www.saas.nsw.edu.au/wiki/index.php?ThemeHowTo [--snip--] R.
Hi Everyone, I writing this from sunny Queenstown, New Zealand. Sorry for being so out of touch the last few days. So what to do about the templating? I think that we already have pretty much a consensus on what the plan is. The information on Roger's Wiki at http://www.saas.nsw.edu.au/wiki/index.php?page=ThemeHowTo is all pretty much how I see it. Just to paraphrase: 1) all templates should live in koha-tmpl, along with there associated includes and images (style sheets, javascripts, etc) 2) this cvs branch will eventually replace the koha-html tree all together. 3) under koha-tmpl there are two subtrees: intranet-tmpl/ and opac-tmpl/ corresponding to what should go into the <serverroot>/intranet/htdocs/ and <serverroot>/opac/htdocs/ directories on the live sites. 4) under each of these are /<theme>/<lang>/ directories. Each theme can have different language settings. At present I have been working only on the /default/en/ templates. 5) Theme, language selection: In the scripts there should be the lines: use C4::Output; my $template = gettemplate("opac-search.tmpl", "opac"); The gettemplate subroutine looks for the theme and language settings, looks for a template, loads the template and sets the <themelang> tag for use in all the includes etc. I.e. src="<TMPL_VAR NAME='themelang'>/images/search-button.gif" This is the concessus right now. There are some other issues however: Issue 1) Should we have a totally seperated html/website tree under each /<theme>/<lang>/ directory ? I think so. most, if not all of the includes and images are theme and language specific. Anything that is not language specifc can go in the /<theme>/<all>/ directory. I dont think there will be anything not theme specific. Issue 2) The "gettemplate" and "pathtotemplate" subroutines in Output.pm ? why two and which to use? There are two routines here because Dorian and I solved the same problem at the same time :-) The key design difference is that gettemplate actually loads the template and returns the template object. Whereas pathtotemplate returns a path that can be use to load the template. I think it is better to pass the template because it simplifies the script code: getting the template involves only one line. If there are extra options and settings that you want to pass to the HTML::Template->new() call, they can be passed through a new improoved gettemplate sub. (not hard to change.) however I cant image when you would want to do this, and if so it would not be commen. what do people think? Issue 3) What to do about systempreferences etc. ? How does koha select the theme and language? There has been some disscussion on this which I will try and paraphrase. Luckly the gettemplate routine doesnt really need to change at all so changing our minds about this issue is easy :-) At present there are two places for settings: the koha.conf file and the systempreferences table in the database. Gettemplate gets the 'opachtdocs' or 'intranethtdocs' settings in from the koha.conf file (through C4::Context whis is really cool btw) and then looks into the systempreferences table for the 'opaclanguages' and 'opacthemes' settings. These can be space seperated lists in order of preference. the subroutine then goes and looks in the directory for the specified files until it finds one. One option is to put everything in the database? another option is to have new database tables "themes" and "languages" with IP and userid fields so that settings can be kept between sessions and individual computers can have different settings? I think this is desirable. Issue 4) CSS ? Roger has suggested using a template variable 'type' to switch between the intranet and the opac. This, in my opinion, is a bad idea. I have been trying to remove all the 'type = opac || intra' code from koha. The opac and the intranet should use completely seperate code. all apart from the modules (thus the "opac" in gettemplate("<tmplatename>.tmpl", "opac") ) However, there is no reason we can have heaps of CSS in the templated koha. It just goes into files that are read in through <TMPL_INCLUDE NAME="stylesheet"> tags. Well thats about all for now. I hope that is helping :-) Finlay ps. other issues?
finlay@katipo.co.nz wrote:
Hi Everyone,
I writing this from sunny Queenstown, New Zealand. Sorry for being so out of touch the last few days.
Queenstown - Such a lovely environment. I wouldn't have been in touch at all!
So what to do about the templating?
I agree with everything I understand... and don't know enough to comment on the rest... so I leave that to you coders.
Issue 4) CSS ?
Roger has suggested using a template variable 'type' to switch between the intranet and the opac. This, in my opinion, is a bad idea.
I agree - it is a bad idea :) I chose "type" to illustrate the general case of how variables might be passed to .css <block class=variable> to improve efficiency and flexibility - anyhow, that was my intention. Again, I probably don't understand the options sufficiently to see a better alternative. [--snip--]
However, there is no reason we can have heaps of CSS in the templated koha. It just goes into files that are read in through <TMPL_INCLUDE NAME="stylesheet"> tags.
For any given website, I'm (mostly) used to having one stylesheet does all... which is probably the only reason that variables seemed like a good idea - I'll have to have some more practice with this before commenting further. Thanks for the clarity... must be all that fresh air and sunshine :) R.
participants (9)
-
Andrew Arensburger -
Dorian Meid -
Finlay Thompson -
finlay＠katipo.co.nz
-
Nicholas S. Rosasco -
Pat Eyler -
paul POULAIN -
Rachel Hamilton-Williams -
Roger Buck