cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From solprovi...@apache.org
Subject PipelineEvents eat children
Date Wed, 20 Feb 2008 02:17:46 GMT
Classes extending SimpleParentProcessingNode decide which children to
process and call invoke() on those children.
Classes extending PipelineEventComponentProcessingNode assume all
children are configuration for the parent node.  Any children not
understood by the component are ignored.

Compare these examples:
<map:select>
   <map:when test="first">
      <map:transform>
         <map:parameter name="choice" value="first"/>
      </map:transform>
   </map:when>
   <map:otherwise>
      <map:transform>
         <map:parameter name="choice" value="other"/>
      </map:transform>
   </map:otherwise>
</map:select>

And:
<map:transform>
   <map:select>
      <map:when test="first">
         <map:parameter name="choice" value="first"/>
      </map:when>
      <map:otherwise>
         <map:parameter name="choice" value="other"/>
      </map:otherwise>
   </map:select>
</map:transform>

The first example works because no ParentProcessingNodes are children
of a PipelineEvent.
The second transform will have the parameter "choice" default to the
empty string because the map:select element was ignored.

Differentiating the elements may make sense to Cocoon devs, but is not
obvious to Cocoon users.  The second example is obviously better code:
shorter with decision-making closer to the effect. The differentiation
only exists due to Cocoon storing the PipelineEvents for the second
phase of processing.

Workarounds are possible after a user learns about the limitations of
certain elements -- difficult since these limitations are not
mentioned on the Cocoon website.  The workarounds can become very
messy.  Imagine three Selectors each need to set parameters for one
transform.  Much code would be duplicated or an extra pipeline added
for each Selector.  Both methods reduce maintainability, and the
latter adds processing.

The obvious solution is for the PipelineEvent nodes to test each child
with isInvocable() [or isComponent() or isProcessingNode()?] and call
child.invoke() where appropriate.  This is feasible as only three
PipelineEvent classes exist: GenerateNode, TransformNode, and
SerializeNode.

Another (better?) solution would test child nodes before passing
control to the PipelineEvent nodes.

This affects Cocoon-2.1 through Cocoon-2.1.11.  Has this been fixed in
Cocoon-2.2?

Thoughts?

solprovider

Mime
View raw message