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
