Joern Nettingsmeier wrote:
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.
I guess I see your point, and my comments where indeed of quite general
nature. But when I see script-like XML, all my alarm bells start ringing :)
At a first glance, the mechanism described in your mail could as well
be implemented using Ant with the XConfToolTask. But, the longer I think
about it, I'm rather concerned about the fact that files are copied and
patched at all. I tried to take care of this in the repo layer re-design,
whereas it's not yet finished.
IMO
> <file mode="copy" src="publication.xml">
> <xsl:template match="lenya:name">
> <lenya:name><xsl:value-of select="$pub_name"/></lenya:name>
> </xsl:template>
> ...
should instead be
publication.setName(...);
publication.setDescription(...);
The same should apply to policies etc. The access controller should be
configurable using the API and create configuration files whenever it
considers this appropriate. If Lenya supports instanciation of
publications during run-time, it should also allow this without copying
and patching any configuration files.
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*.
I prefer thinking in terms of separate modules which communicate through
well-defined interfaces, not configuration files. But maybe I don't
understand you correctly.
(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.
Yes, it is a manipulation of the configuration, but it should happen
only using well-defined interfaces. publication.xconf and publication.xml
are implementation details, although the documentation advises to manipulate
them manually (IMO that's not a favourable situation).
the current java code does nothing else.
Because the API doesn't offer the corresponding interfaces, due to the
fact that publication templating is quite new and not yet mature.
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.
OK - it looks like other projects leverage the documentation options
of XSLT better than we do :) You're right, my point wasn't valid.
- 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.
Actually it certainly is the position of the minority :)
But I'll try to defend it nevertheless ...
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.
IMO Lenya is not a product that you just use. It could be someday in
the future, but this is a long way. We carry a quite large burden of
a lack of modularization and well-defined interfaces, lots of scripting
and patching. My major intention is to reduce that to a clean Java API
which can be used to develop applications.
* extensive hacking of lenya's java core for more or less trivial
functions is a problem.
It shouldn't be necessary to "hack the core". Publications should IMO be
implemented using the core (repository) API and a set of modules for
specific functionality (particular resource types etc.).
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.)
OK - IMO it's just the other way round. If you use Java, you're on
the safe side. Your IDE informs you when something has changed, you
have autocomplete, easy debugging and all fancy bells and whistles.
If you're dealing with XML-based configuration and patching, you're
quite on your own. But, of course, this is just my point of view :)
Thanks for all your comments, it's always very interesting to hear what
people think about Lenya design decisions etc.!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
