cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Externalizing JXTG tag configuration
Date Wed, 11 May 2005 12:47:33 GMT
Daniel Fagerstrom wrote:
> 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.

+1, +1!

> 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.

Complete agreement here too.

> 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 ;)

Exactly; -1 on any additional configurability.


View raw message