cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Externalizing JXTG tag configuration
Date Wed, 11 May 2005 10:02:09 GMT
Leszek Gawron wrote:

> right now we have:
>
> registerInstruction("template", StartTemplate.class.getName());
> registerInstruction("forEach", StartForEach.class.getName());
> registerInstruction("if", StartIf.class.getName());
> registerInstruction("choose", StartChoose.class.getName());
> registerInstruction("when", StartWhen.class.getName());
> registerInstruction("otherwise", StartOtherwise.class.getName());
>
> which puts all tag definitions into a proper map. I'd like to 
> externalize that. Few issues:
>
> It was mentioned on the list that it would be the best to store that 
> configuration in sitemap-language.xml.


Uh? What does it have to do in sitemap-language.xml?

> From what I see it does not contain any component specific 
> configuration. I we are to follow that path I have some questions:
> - should we modify that file at build time? (block inclusion should 
> cause writing configuration int the file)
> - how to get the config from that file at runtime?
>
> Implementation details: I'd like to create a JxtgInstructionFactory 
> component that is thread safe (configuration should be parsed and 
> shared for all JXTG parsers for now). The JxtgTagFactory interface 
> looks like this:
>
> public interface JxtgInstructionFactory {
>    public StartInstruction createInstruction( StartElement startElement,
>                               Attributes attrs,
>                               Stack elementStack )
>                                   throws ProcessingException;
> }
>
> I could also start from putting the configuration into cocoon.xconf 
> and then refactor if needed.


The question is whether we want users to be able to add new tags, or if 
this configuration is only to be used by sitemap-level components (e.g. 
JXTG) to define some fixed language.

A fixed language means either code as of today or a conf file hidden in 
the jar files.

An expandable language means people can add new tags, but IMO shouldn't 
change the base language tags. Not talking about the simple fact also 
that it would be frightening to have that in cocoon.xconf!!! So the 
configuration could be a base configuration in the jar file, augmented 
with user-defined tags.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message