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.