Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Ok, only the InstructionFactory is a component, that is better. Is there any point in leting the InstructionFactory be a component?
Only the fact that I had to store the configuration somewhere and with cocoon.xconf I had the proper tools at hand.
As said I would prefer template configuration in a separate file. Also I don't like the repetition of the target name space, we could declare that in a enclosing tag e.g. "instructions".
Like: <instructions targetNamespace="jx"> <instruction name="for" class="StartFor"/> <instruction name="for" class="StartFor"/> <instruction name="for" class="StartFor"/> </instructions> <instructions targetNamespace="ft"> <instruction name="widget" class="StartWidget"/> </instructions> ?
Fine for me.
yes.
Do you have any proposal how could we create an extendable instruction configuration that could be extended by another block?
Why do you want that?
<snip/>
Sure, just go ahead. I would even prefer o.a.c.template.script.instruction.Instruction as it shoulddn't have anything to do with JXTG.
It looks like jxtg part could be dropped from:
o.a.c.template.jxtg o.a.c.template.jxtg.environment o.a.c.template.jxtg.expression o.a.c.template.jxtg.instruction o.a.c.template.jxtg.script o.a.c.template.jxtg.script.event
there is no single o.a.c.template.SomeClas
yes, you can drop the jxtg part. The main reason for it was that I wanted to separate the jxtg specific code from the general template framework. But as long as we only one template language that doesn't make much sense. If/when I start implementing a attribute template language I might continue the work towards a more general template framework.
/Daniel
