Andreas Hartmann wrote:
>> as mentioned in another posting, i think the user should not be
>> required to touch java code in order to use and tune the behaviour
>> of templates.
>
> I have to admit that I disagree. Once we followed this strategy in
> the Lenya project, and it caused a lot more harm than benefit.
i would fully share your objections if the feature i'm proposing were a
central mechanism in the core of lenya. it would of course be bad style
to implement some parts of the "business logic" with XSLT in an
otherwise java-based framework.
but all i'm suggesting is to provide a hook to control the behaviour of
the ConfigurableInstantiator. in the default case, the configuration
file boils down to a simple list of files, which is what you originally
suggested.
> Patching config files using XSLTs etc. has some disadvantages which
> can be tolerated in a limited development environment, but not in an
> open source project of this scale:
>
> - First of all, there's no IDE-based consistency ensurance. Element
> names might change, configuration options might change. If it's Java,
> the compiler will complain, and you can apply automatic refactoring.
> If it's XSLT or something like that, you'll lose control.
but: this mechanism is only used as a *customization hook*, i.e. the
developers don't need to worry about it. if it breaks, i get to keep the
pieces. all you need to make sure is to provide a usable default, and
that's simple.
the user OTOH gains a lot of control.
i think the inheritance behaviour of a template is a property of this
template and should thus be reflected in one of its configuration files.
in unix speak, it's *policy* and should not be in the kernel (or the
business logic in this case) IMHO. the kernel provides *mechanism*.
(no matter how this is implemented in detail. the xslt stuff was just
what came to mind first because it's already there and makes the
mechanism very flexible and intuitive to use.)
> - Even the fact that configurations are stored in XML files is an
> implementation detail. No components should directly manipulate
> configurations of other components (publication <-> instantiator).
the instantiation of a publication is by nature a direct manipulation of
its configuration. the current java code does nothing else. i think i
understand the spirit of your objection, but i think it does not apply
to the creation of a new publication. in all other cases during
run-time, i would agree.
> - XSLTs tend to be easily understandable by the person writing them,
> and to nobody else :) Java encourages inline documentation using
> Javadocs, can be refactored to improve readability and
> maintainability.
with the lenya tree documentation effort we're thinking of, i'm going to
demonstrate that the magic <!-- --> tag in xml can be put to other uses
than containing the apache license :)
of course, it's not as formalized as javadoc, but it's exactly in the
place where the user needs it to be.
> - Lenya is a Java-based framework. It is strongly encouraged to be
> familiar with Java anyway if you want to start serious development of
> a CMS using Lenya.
i strongly disagree, and i hope this is not the position of all lenya
developers. here's why:
* the stuff i'm proposing is not an arcane customization, but an
essential feature that's already there, but not quite usable. i'm sure
every new user wants to create a publication eventually :)
* there is a difference between *using* lenya and developing on the
basis of lenya. i want to use lenya, and i want to use a feature that's
already been advertised.
* extensive hacking of lenya's java core for more or less trivial
functions is a problem. even if i were a lot more java-capable than i
am, i would be reluctant to do it, since it is a maintenance burden
later on. (you might argue there's modularization and all, but still: if
i saw the need to add or modify java code, i would try to do it in
cooperation with the lenya devs, make it generally useful and try to get
it accepted into the tree if at all possible.)
>> xsl OTOH is a mandatory skill for lenya anyway, and ideally it
>> would be used for most of the non-gui-interaction with lenya's
>> internals.
>
> IMO the same is true for Java. Use Java for implementation of
> functionality and XSLT for presentation and XML processing.
i agree with this. but to reiterate: i'm not talking about
functionality, i'm talking about configuration and control (or, in other
words, policy vs. mechanism).
regards,
jörn
--
"Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga."
"Without new works, without the present the past will cease to be of
interest."
- Ásmundur Sveinsson (1893-1982)
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
