You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2005/05/11 16:00:37 UTC
[VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
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.
[ ] 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.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE RESULTS] CForms instruction set for jxtg rendering vs.
jx-macros.xml file
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: [VOTE RESULTS] CForms instruction set for jxtg rendering vs.
jx-macros.xml file
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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?
Sylvain said that he is workking on a proposal about refactoring the
CForms API in the end of the "CForms view model?" thread and also
proposed to have we could have more reflection friendly repeaters. Vadim
proposed to use XMLizable in the API instead of direct seting of content
handlers. With these changes the jx-macros probably will be quite
straight forward.
I would propose that you wait and see.
/Daniel
Re: [VOTE RESULTS] CForms instruction set for jxtg rendering vs.
jx-macros.xml file
Posted by Upayavira <uv...@odoko.co.uk>.
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
Well, I'd prefer the second, after having heard the suggestion. However,
from Reinhard's tests, if it is the evaluation of expressions that
causes the lack of speed, changing CForms to make it jxpath friendly
wouldn't help here. So maybe the first option is all that is possible?
Thoughts anyone?
Regards, Upayavira
Re: [VOTE RESULTS] CForms instruction set for jxtg rendering vs.
jx-macros.xml file
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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?
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
Posted by Upayavira <uv...@odoko.co.uk>.
Leszek Gawron wrote:
> Upayavira 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.
>>> [ ] 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.
>>
>>
>>
>> And have the code for these extensions in the forms block (ie. forms
>> depends upon templates)? +1
>
> forms block of course - just like current jx-macros.file.
>
>> Can your code handle that?
Then +1 from me.
Upayavira
Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Upayavira 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.
>> [ ] 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.
>
>
> And have the code for these extensions in the forms block (ie. forms
> depends upon templates)? +1
forms block of course - just like current jx-macros.file.
> Can your code handle that?
will have to :)
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
Posted by Upayavira <uv...@odoko.co.uk>.
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.
> [ ] 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.
And have the code for these extensions in the forms block (ie. forms
depends upon templates)? +1
Have them in the templates block? Don't like it. Because it creates an
unnecessary dependency.
Can your code handle that?
Regards, Upayavira
Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom 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.
>> [ ] It's a bad idea - leave jx-macros.xml untouched!
>> [x] It's not jx-macros.xml fault. CForms should be changed if current
>> solution isn't right.
>
>
> It might be a naive view, but IMO from a view POV a form model should be
> a rather simple data structure and the kind of thing that a good
> template language should excel in rendering.
>
> If the rendering macros become ugly it is IMO a sign that we have work
> left to do. Either the form model need to be made more view friendly, or
> we need to find more powerfull general purpose instructions to the
> template language (or both). Or the problem is more complicated than I
> think ;)
>
> Anyway, I think we should try to understand the issue a little bit
> better before we try to just hack around it.
+1
Vadim
Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
> [ ] It's a bad idea - leave jx-macros.xml untouched!
> [x] It's not jx-macros.xml fault. CForms should be changed if current
> solution isn't right.
It might be a naive view, but IMO from a view POV a form model should be
a rather simple data structure and the kind of thing that a good
template language should excel in rendering.
If the rendering macros become ugly it is IMO a sign that we have work
left to do. Either the form model need to be made more view friendly, or
we need to find more powerfull general purpose instructions to the
template language (or both). Or the problem is more complicated than I
think ;)
Anyway, I think we should try to understand the issue a little bit
better before we try to just hack around it.
/Daniel
Re: [VOTE] CForms instruction set for jxtg rendering vs. jx-macros.xml
file
Posted by Leszek Gawron <lg...@mobilebox.pl>.
just for the record :)
> [+1] Yes go for it.
> [ ] 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.
>
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65