Our current template structure is something like: SITE/htdocs/SITE-tmpl/THEME/LANG/OBJECT where SITE = { intranet, opac } THEME = { default, npl, vanilla, ... } LANG = { <empty>, en, es, fr, pl, zh-TW, ... } OBJECT = { <empty>, includes, LANG=en?images } It's probably not ideal to have all of these in htdocs, as some aren't really for direct download. Languages and images are also subordinate to themes, which has some side-effects. I suggest splitting includes, languages and templates so we get something like: templates/TYPE/THING/SCOPE where TYPE = { htdocs, l10n, tmpl } THING = { images, includes, LANG, default, npl, vanilla, ... } SCOPE = { default, intranet, opac, ... (may grow if needed) } and language, style and theme are set independently in koha. koha then looks at templates/l10n/LANG:templates/tmpl/THEME :templates/tmpl/THEME/LANG for its files, which may include things from templates/htdocs served by the httpd. This will let koha themes, styles and translations be maintained and used independently. As this requires some rewriting of the httpd config, it should be possible to support the single-vhost installation which seems a FAQ (when you only have one hostname-port combination to run on). The downside is that we will need to provide guidelines for the themes, styles and translations and it may need some careful work to get the same performance as the current template compiler. So that we don't lose anything if it doesn't work, I will branch 3.0 when the time comes and develop/test it there. Comments? Thanks, -- MJ Ray - see http://mjr.towers.org.uk/email.html North End, Lynn, Norfolk, England Work: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request
Am 01.08.2006 um 00:10 schrieb MJ Ray:
Our current template structure is something like: SITE/htdocs/SITE-tmpl/THEME/LANG/OBJECT where SITE = { intranet, opac } THEME = { default, npl, vanilla, ... } LANG = { <empty>, en, es, fr, pl, zh-TW, ... } OBJECT = { <empty>, includes, LANG=en?images }
It's probably not ideal to have all of these in htdocs, as some aren't really for direct download. Languages and images are also subordinate to themes, which has some side-effects. The plan, when I developed the THEME/LANG/OBJECT directory was that it should be completely outside of the htdocs and then the relevant objects should be linked into the webspace.
But it's long time ago and i'm not really up to date with the koha-code.
I suggest splitting includes, languages and templates so we get something like: templates/TYPE/THING/SCOPE where TYPE = { htdocs, l10n, tmpl } THING = { images, includes, LANG, default, npl, vanilla, ... } SCOPE = { default, intranet, opac, ... (may grow if needed) } and language, style and theme are set independently in koha. koha then looks at templates/l10n/LANG:templates/tmpl/THEME :templates/tmpl/THEME/LANG for its files, which may include things from templates/htdocs served by the httpd.
I don't understand what you mean with the colons between the paths Could it be that your THING directory level mixes things which should be on different levels? In my opinion there are e.g. images and includes which are specific to a language. So all language specific things should be below the language directory. Next I introduced a "all" directory which unfortunately wasn't used so much. The idea was to have a directory named "all" on every level which helds all the objects common to all the other objects on the same level. E.g. you can have default/en/images/submit.gif which could be a button for a theme/lang combination, but you could also use default/ all/images/1.gif which could be a image equal for all languages of that theme. Then the scope. Why splitting more and more. Why not doing a move frome scope to theme. So we could have a default-librarian theme (i don't like the name intranet) and a default-opac theme. The backend then should be the same and the opac-themes or other reduced themes just don't use the whole functionality. I admit in having a nicer solution in splitting things which should be served and things outside the webspace. The quest is to have them together for maintenence and distribution and to have them separated on the server.
This will let koha themes, styles and translations be maintained and used independently.
You can do this at tis time with the existing structure. Dorian Meid
Dorian Meid <dnmeid@gmx.de> wrote:
The plan, when I developed the THEME/LANG/OBJECT directory was that it should be completely outside of the htdocs and then the relevant objects should be linked into the webspace.
But it's long time ago and i'm not really up to date with the koha-code.
Thanks for the feedback. That would make sense, but that's not how the installer's worked since before I joined. Also, would that mean lots of hard-or-symlinks or large Alias lists? [...]
koha then looks at templates/l10n/LANG:templates/tmpl/THEME :templates/tmpl/THEME/LANG for its files, which may include things from templates/htdocs served by the httpd. I don't understand what you mean with the colons between the paths
They're seperators of items in a list of directories, same as you see if you echo $PATH at the command line.
Could it be that your THING directory level mixes things which should be on different levels? In my opinion there are e.g. images and includes which are specific to a language.
Images with text should be the exception, not the norm. When they are used, they should nearly always be composed by CSS overlays of text onto a base image, for ease of translation and to keep themes language-independent as far as possible.
So all language specific things should be below the language directory.
I agree. [...]
Then the scope. Why splitting more and more. Why not doing a move frome scope to theme. So we could have a default-librarian theme (i don't like the name intranet) and a default-opac theme. The backend then should be the same and the opac-themes or other reduced themes just don't use the whole functionality.
I'm not sure about this. The feedback I get from customers is that it's very important that their opac looks very much like the rest of their web site, but it's less desirable for their librarian/intranet site to be themed. As kohadocs grows, it may be desirable to look like the manuals. The other motive is splitting up the namespace, to reduce the amount of things that koha needs to handle and to reduce the number of possible accidental collisions, where the same name is used in two situations. I don't feel that strongly about either of those. Does anyone have a strong reason for combining or splitting these?
This will let koha themes, styles and translations be maintained and used independently. You can do this at tis time with the existing structure.
It seems like people have to check a theme for updates whenever the master language of the theme is updated, and you cannot use a language on a theme it hasn't been prepared for. Have I missed some feature there? Thanks, -- MJ Ray - see http://mjr.towers.org.uk/email.html North End, Lynn, Norfolk, England Work: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request
MJ Ray a écrit :
Our current template structure is something like: SITE/htdocs/SITE-tmpl/THEME/LANG/OBJECT Comments?
Yes ;-) In fact, I think we also should investigate the general directory structure in Koha. We have (intellectually) : - scripts (.pl) that are for librarian interface - scripts (.pl) that are for OPAC - script that are for none of them (migration, cron scripts...) - templates - included files for templates - files (javascript, css...) that must be in the documentroot of the webserver - file & parameters for zebra - (am I missing something ?) I think all of them are mixed in actual CVS : in $KOHADIR, you'll fine acqui directory, .pl for acquisitins, misc directory, script that run on command line... in template dir, you'll find templates (outside of htdocs scope), includes (with things outside of htdocs -the .inc- and things in htdocs, .css & .js) This mix has a consequence : - Koha is quite hard to setup & maybe unsafe (useless things in htdocs is always poor from a security point of view) - Koha needs a buildrelease that tries to reorganize all of this. I suggest we completly change the directory structure in HEAD to have : * intranet = all directories for librarian interface. Will contain, for example : intranet/acqui/, intranet/circ/, intranet/cataloguing/ ... * opac = all scripts for opac. The good news is that is already exist ;-) * koha-tmpl/intranet-tmpl & koha-tmpl/opac-tmpl remains as they are for instance, except for includes directory. * template includes directory is splitted in 2 parts : - the htdocs : the various htdocs. Will contain all css & javascripts. documentroot will be affected to this directory, making impossible to open something else from the browser - includes : the directory that will contain various includes. The actual includes will be renamed as "default". includes as well as htdocs depends on theme as well as on language. Thus, we can't have the same directory structure as today (theme/lang/template & theme/lang/javascript and them/lang/css : the documentroot includes the templates themselves) We could add a htdocs directory at koha-tmpl level to solve this : koha-tmpl/intranet-htdocs/theme/lang/javascript and koha-tmpl/intranet-htdocs/theme/lang/css for includes, it's the same idea : we will have includes dedicated to themes & languages, so we need : koha-tmpl/intranet-includes/theme/lang/ Note, that this will require some (no so big) changes in the translator tool tmpl_process3.pl A last note : with the previous structure, KOHADIR should be empty from any file. empty ? not really, we could put the installer here, as does buildrelease. The installer would be highly simplified, needing only the config file & the virtual host to be created. That could be the 1st step to an idea I suggested during dev_week, that could be implemented : let install.pl do only the technical part of install & have a webbased interface for all librarian parameters (choosing marc flavour, setting up some parameters ...) PLEASE LET ME KNOW WHAT YOU THINK OF THIS SUGGESTION : if you think it's a good idea, then i'll ask Antoine to work on it (in september ?) -- 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 02:26:21PM +0200, Paul POULAIN wrote:
In fact, I think we also should investigate the general directory structure in Koha.
We have (intellectually) : - scripts (.pl) that are for librarian interface - scripts (.pl) that are for OPAC - script that are for none of them (migration, cron scripts...) - templates - included files for templates - files (javascript, css...) that must be in the documentroot of the webserver - file & parameters for zebra - (am I missing something ?) Zebra files include: server config files (koha.xml, ccl.properties, cql.properties, etc.) database-specific config files(bib1.att, record.abs, etc.) database-specific database files (registers, shadow, tmp, etc.)
I think all of them are mixed in actual CVS : in $KOHADIR, you'll fine acqui directory, .pl for acquisitins, misc directory, script that run on command line... in template dir, you'll find templates (outside of htdocs scope), includes (with things outside of htdocs -the .inc- and things in htdocs, .css & .js) This mix has a consequence : - Koha is quite hard to setup & maybe unsafe (useless things in htdocs is always poor from a security point of view) - Koha needs a buildrelease that tries to reorganize all of this. I agree. But it's also important that we be able to run off of a cvs repo as we do now.
I suggest we completly change the directory structure in HEAD to have : * intranet = all directories for librarian interface. Will contain, for example : intranet/acqui/, intranet/circ/, intranet/cataloguing/ ... * opac = all scripts for opac. The good news is that is already exist ;-) * koha-tmpl/intranet-tmpl & koha-tmpl/opac-tmpl remains as they are for instance, except for includes directory. * template includes directory is splitted in 2 parts : - the htdocs : the various htdocs. Will contain all css & javascripts. documentroot will be affected to this directory, making impossible to open something else from the browser - includes : the directory that will contain various includes. The actual includes will be renamed as "default". Why rename it to default?
includes as well as htdocs depends on theme as well as on language. Thus, we can't have the same directory structure as today (theme/lang/template & theme/lang/javascript and them/lang/css : the documentroot includes the templates themselves) We could add a htdocs directory at koha-tmpl level to solve this : koha-tmpl/intranet-htdocs/theme/lang/javascript and koha-tmpl/intranet-htdocs/theme/lang/css
for includes, it's the same idea : we will have includes dedicated to themes & languages, so we need : koha-tmpl/intranet-includes/theme/lang/
Note, that this will require some (no so big) changes in the translator tool tmpl_process3.pl Sounds good.
A last note : with the previous structure, KOHADIR should be empty from any file. empty ? not really, we could put the installer here, as does buildrelease.
The installer would be highly simplified, needing only the config file & the virtual host to be created.
That could be the 1st step to an idea I suggested during dev_week, that could be implemented : let install.pl do only the technical part of install & have a webbased interface for all librarian parameters (choosing marc flavour, setting up some parameters ...) This sounds great!
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
[big snip]
PLEASE LET ME KNOW WHAT YOU THINK OF THIS SUGGESTION : if you think it's a good idea, then i'll ask Antoine to work on it (in september ?)
I think its a good idea, the only thing im worried about is losing the cvs history of the files when moving them. Perhaps it might be better waiting for the switch to subversion (when savannah supports it) As it can do moves without losing history, unless we can do it in cvs Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
From: Paul POULAIN <paul.poulain@free.fr> I suggest we completly change the directory structure in HEAD to have :
I could work with that, but suggest tweaking that proposal to: * lib - all koha perl modules * scripts/intranet-cgi and scripts/opac-cgi - the cgi-bin scripts * scripts/admin - the helpers and daemons and so on to be installed * koha-tmpl - the templates and languages and so on This would make the forthcoming MakeMaker installer much simpler, just like CPAN packages.
[...] have a webbased interface for all librarian parameters=20 (choosing marc flavour, setting up some parameters ...)
I agree with this. I think there should be a web-based interface for the database installation/upgrade too, as it will help avoid the differences between various command shells and perl DBI. Please don't switch to subversion. If we are going to have the pain of switching, please move to something which does distributed (disconnected?) development and doesn't sulk when it can't reach the master server. Version Control is advancing: Darcs, git, ... Hope you like the suggested tweaks, -- MJ Ray - see http://mjr.towers.org.uk/email.html North End, Lynn, Norfolk, England Work: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request
On Tue, Aug 15, 2006 at 01:59:01PM +0100, MJ Ray said:
From: Paul POULAIN <paul.poulain@free.fr> I suggest we completly change the directory structure in HEAD to have :
I could work with that, but suggest tweaking that proposal to: * lib - all koha perl modules * scripts/intranet-cgi and scripts/opac-cgi - the cgi-bin scripts * scripts/admin - the helpers and daemons and so on to be installed * koha-tmpl - the templates and languages and so on
This would make the forthcoming MakeMaker installer much simpler, just like CPAN packages.
Ohhh, I like this Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
participants (6)
-
Chris Cormack -
Dorian Meid -
Joshua Ferraro -
MJ Ray -
mjr＠phonecoop.coop
-
Paul POULAIN