[Koha-devel] OPAC dir structure redesign

[Ian Walls]

I'd like to interject here again the idea of creating a stable API for
template variables, so that if people feel the need to template out there
out theme, they can do so without having to re-engineer it mid-release.
Any changes to this API would need to be well publicized between major
releases.

In order to accomplish this, the following steps would need to occur:

   1. Identify the variables demanded by each page
   2. Consolidate variables that are shared into centralized
   includes/objects
   3. Fill in any missing variables or generalize where appropriate
   4. Document

The Koha community could make it a policy to only officially support one
theme with the main release, but any other institution, entity or
individual could maintain and distribute their own theme customized for
particular needs.  They would only need to follow the change log in the API
documentation to do so, and would only need to do the maintenance work at
most once every 6 months.

Cheers,


-Ian


On Mon, May 6, 2013 at 4:29 AM, Mason James <mtj at kohaaloha.com> wrote:

>
> On 2013-05-6, at 8:21 PM, Mirko wrote:
>
> > Mason James schrieb am 06.05.2013
> >
> >>
> >> On 2013-05-6, at 5:42 PM, Katrin Fischer wrote:
> >>
> >>> Hi,
> >>>
> >>> I agree that maintaining 2 themes is a bit harder to do in
> >>> Koha development,
> >>
> >>> but I am not sure this necessarily means we have to remove
> >>> functionality that could be quite useful for some Koha
> >>> projects.
> >>>
> >>> Couldn't we keep the functionality and still decide to only
> >>> officially support one theme in releases?
> >>
> >>
> >> I'm just going to say this.. we have already make this mistake a
> >> few times now with Koha and themes
> >>
> >> afaik, Koha has had at least 3 previous themes, using the current
> >> directory structure
> >>
> >> ensuring that those previous theme files were maintained and
> >> correct proved to be an impossible task, and all of those themes
> >> were eventually removed
> >>
> >>
> >> i am certain if we don't fix this problem, for this cycle of
> >> themes - the same fate will occur again...
> >>
> >
> > I think what Katrin is saying -- and I'd like to concur with -- is
> > that we should keep the function, not keep maintaining different
> > themes. There would only be one maintained theme in Koha out of the
> > box and libraries that use their own custom theme will have to
> > maintain it themselves.
> >
> > The whole theme thing is kind of irrelevant if we reduce it to CSS,
> > we can have that in the appropriate sysprefs.
> >
> > My library actually just has decided to create a custom theme for
> > the university's corporate identity, so I am biased, but I assume a
> > lot of libraries will run into problems if that functionality will
> > disappear.
> >
> > -- Mirko
>
>
>
> yeah, i was just talking to Chris on IRC, and i now agree with you both :P
>
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20130506/6f06d04b/attachment.html>