cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Externalizing JXTG tag configuration
Date Wed, 11 May 2005 10:17:05 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.

We should not store it in sitemap-language.xml, it is a completely 
different concern, it should be a template language specific 
configuration file.

IIRC, Vadim suggested that we should use a configuration file that is 
stored in the code tree and used throught the resource protocol, in the 
same way that the tree processor uses 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.
>
I would prefer to have the template configuration in a separate file, 
not in cocoon.xconf. AFAICS there is no point in making the instructions 
Avalon components. It would be enough to have a configuration file that 
connnects the instruction name with the implementation class. Then the 
configuration file could be explicitly refered to in the JXTG code. We 
could also make the template configuration file path configurable in the 
JXTG configuration. But as many people where upset about allowing 
configurable template languages, I think we should avoid making it to 
easy to configure for non committers for the moment. I think we have 
more important things to do than to discuss why tag libraries sucks ;)

/Daniel


Mime
View raw message