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



Reply via email to