Leszek Gawron wrote:

Daniel Fagerstrom wrote:

Leszek Gawron wrote:

<snip/>

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.

done already :)

Nice :)

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?

to implement cforms instructions instead of jx-macros.xml file which looks quite ugly because of hacks that had to be made to implement it.
This will also speed up forms processing.

I'm afraid that I'm not going to be helpfull at all ;) First, to me it seem like you suggesting something that part of the community was strongly against. If you want to implement it you have to ask if people have changd their minds or explain how your proposal is different from what people where against and ask if it is ok.


Second, the ugliness in jx-macros should IMO be handled by making CForms more template friendly (and maybe we lack some functionality in JXTG). From my POV a form package should contain a view model. And the view model should be easy to traverse and render for a simple template language. The fact that CForms isn't easy to traverse and render means IMO that there are more work to do in CForms. As an example it is IMO a mix of concern to let CForms generate SAX.

Third, there is no reason that a Java implementation of the CForms macros should be significally faster than a macro implemementation. If it is, it means that we should analyze where the bottlenecks in macros are, and remove them.

/Daniel



Reply via email to