Joern Nettingsmeier wrote:
a while ago, andreas suggested i file an enhancement bug for a
ConfigurableInstantiator that will take a list of files to copy. this is
probably a good idea. i wonder whether it could be made simpler than the
current one (which looks designed to frighten little children ;) if all
the patching is done not by individual sax calls but with external xsl
snippets and exported variables. like so:
* the user clicks "new publication", selects <pub_template>, enters
<pub_id> and <pub_name> and sets <pub_ac_behaviour> to either
"refer_to_template_ac", "copy_template_ac" or "create_new_ac". (the last
option would trigger the creation of a new admin account, so that the
user is not locked out.)
* the servlet looks in
context:///lenya/pubs/<pub_template>/config/instantiate.xml, which looks
like this:
[...]
the ac-related stuff would have all sorts of <xsl:choose> tags depending
on the value of $pub_ac_behaviour, but you get the idea.
i did not give an example for <file mode="fallback"/>, since i'm not
sure how to do it. is there a generic way to create an xml file that
basically says "look somewhere else", either with a fallback:// uri or a
static context:// uri?
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.
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.
- 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).
- 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.
- 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.
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.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
