Leszek Gawron wrote:
Leszek Gawron wrote:
I have refactored JXTG recently so now instructions like jx:for, jx:if are defined in separate file: src/block/template/java/org/apache/cocoon/template/template-instructions.xml
Right now we are rendering forms in jxtg using a macro file which is kind of ugly IMO - see yourself: src/blocks/forms/java/org/apache/cocoon/forms/generation/jx-macros.xml
I could fairly easily reimplement jx-macros.xml into more elegant java solution by implementing a separate set of instructions like ft:widget, ft:repeater and so on. If you let me of course.
I do not want to start a tag library war. If cforms and jxtg are core features they should closely support each other.
This is NOT the case of allowing arbitrary instruction sets to be created. CForms case only.
Plase cast your votes: [ ] Yes go for it.
2 in favour: me and Upayavira
[ ] It's a bad idea - leave jx-macros.xml untouched! [ ] It's not jx-macros.xml fault. CForms should be changed if current solution isn't right.
2 in favour: Daniel and Vadim
So what now?
Hmm... thought I had expressed myself on this...
Yes, go for it, but leave the current jx-macros.xml file so that both implementation can live together for a while.
As mentioned by Daniel, I'm planning some refactoring of the CForms API to make it more script-friendly, but this doesn't change the fact that CForms template language will still have to be implemented somehow.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
