cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Externalizing JXTG tag configuration
Date Wed, 11 May 2005 13:29:47 GMT
Leszek Gawron wrote:

> Daniel Fagerstrom wrote:
>
>> 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 ;)
>
> Instructions are not components:
>
>>   <component 
>> role="org.apache.cocoon.template.jxtg.script.InstructionFactory"
>>              
>> class="org.apache.cocoon.template.jxtg.script.DefaultInstructionFactory"> 
>>
>>     <instruction name="template"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartTemplate"/>
>>     <instruction name="forEach"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartForEach"/>
>>     <instruction name="if"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartIf"/>
>>     <instruction name="choose"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartChoose"/>
>>     <instruction name="when"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartWhen"/>
>>     <instruction name="otherwise"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartOtherwise"/>
>>     <instruction name="out"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartOut"/>
>>     <instruction name="import"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartImport"/>
>>     <instruction name="set"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartSet"/>
>>     <instruction name="macro"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartDefine"/>
>>     <instruction name="evalBody"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartEvalBody"/>
>>     <instruction name="eval"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartEval"/>
>>     <instruction name="parameter"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartParameter"/>
>>     <instruction name="formatNumber"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartFormatNumber"/>
>>     <instruction name="formatDate"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartFormatDate"/>
>>     <instruction name="comment"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartComment"/>
>>     <instruction name="call"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartCall"/>
>>     <instruction name="withParam"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartParameterInstance"/> 
>>
>>     <instruction name="attribute"                  
>> targetNamespace="http://apache.org/cocoon/templates/jx/1.0" 
>>                  
>> class="org.apache.cocoon.template.jxtg.instruction.StartAttribute"/>
>>   </component>
>

This exactly what I called "frightening". Imagine a newbie seeing this 
in cocoon.xconf :-)

> Those evil tag libraries. Still Sylvain kicked forms presentation 
> rocket high (respect!) using jxtg and jx-macros.xml and IMO we should 
> replace macro file with java instructions - it's core functionality 
> and looks like cforms - jxtg mariage is tightening.


Hmm... their respective parents have to meet beforehand ;-)

This leads to a question: obviously, cforms-specific tags shouldn't be 
defined in the template block, and so there should be a way for the 
cforms block to provide the additional tag definitions to jxtg. How can 
we do that? The return of XSP's taglib-per-namespace?

> This does not look good:
>
>>     <jx:macro name="widget" 
>> targetNamespace="http://apache.org/cocoon/forms/1.0#template">
>>       <jx:parameter name="id"/>
>>             <jx:set var="widget" 
>> value="${cformsHelper.getWidget(widget, id)}"/>
>>       <jx:if test="${cformsHelper.isVisible(widget)}">
>>         <jx:set var="cformsDummy" 
>> value="${cformsHelper.generateWidget(widget, locale)}"/>
>>         <jx:evalBody/>
>>         <jx:set var="cformsDummy" 
>> value="${cformsHelper.flushRoot(widget)}"/>
>>       </jx:if>
>>     </jx:macro>
>
> cformsDummy all around the place. I may rewrite the functionality 
> myself if noone objects. As we are approaching a stable JXTG 2.0 fast 
> I think of switching to CForms a little bit. It will be a good start.


cformsDummy is because there's no <jx:call> to call arbitrary code 
without JXTG SAXing the result.

If you decide to rewrite jx-macros, please either do it in a temporary 
newjx-macros file, that will later replace the current one, or test 
carefully form samples before committing!!

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message