cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: PipelineEvents eat children
Date Thu, 21 Feb 2008 02:04:05 GMT
On Wed, Feb 20, 2008 at 7:40 PM, Joerg Heinicke <> wrote:
> On 19.02.2008 21:17, wrote:
>  > 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>
> > 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.
>  Solprovider and I already discussed this on the users mailing list [1] -
>  though it seems he does not agree to my reasoning. My main point against
>  this functionality is a conceptional difference: Example 1 is about
>  selecting pipeline components while example 2 is about configuration.
>  IMO it should not be possible to conditionally inject different sets of
>  parameters.
>  The original requirement Solprovider had was to inject a different
>  parameter *value* based on the outcome of the "resource exists
>  selector". My argument was that the correct approach of dynamically
>  evaluating a parameter value is an input module - even though he can't
>  reuse the existing "resource exists selector" in that case. Using an
>  input module would be without any repeating code in the sitemap:
>  <map:transform>
>    <map:parameter name="choice" value="{exists:whatever}"/>
>  </map:transform>
>  Additionally the input module would be reusable while the code in the
>  sitemap would be that bloated whenever this functionality is needed. So
>  even for maintenance reasons this approach seems to be preferable.
>  Also compared with Spring we are consistent. Spring does not provide any
>  conditionals in their configuration files. Instead they provide dynamic
>  evaluation of property placeholders though - just like our input modules.
>  That's why I'm strongly against adding this functionality to the
>  sitemap.
>  (I have held back this mail (for nearly 24 hours) so that others could
>  form their own view. But it seems not too many people are interested ...)
>  Joerg
>  [1]

Writing a reusable InputModule that can handle:
   if(resource1.exists()){ return parameter1;}
   else if(resource2.exists()){return parameter2;}
   else if(resource3.exists()){return parameter3; }
   else return finalparameter;
is possible. The line in the XMAP would be (assuming only 3 files are checked):
   <map:parameter name="name"
I can write the InputModule in a few minutes and solve my immediate
concern.  Maintenance would be a nightmare.

This solution cannot use other Selectors.
This solution cannot set several parameters without reprocessing the
entire list.
This solution cannot handle setting a parameter based on multiple
conditions: if(file1.exists() and file2.exists()) return "both";

This solution does not allow every Matcher and Selector to be used to
set parameters for every Generator, Transformer, and Serializer that
allows parameters.

Many new possibilities are created with the proposed solution:
The DirectoryGenerator can set the "sort" and other parameters based
on request parameters.
Most Transformers use parameters that could be chosen by Selectors.
The PDFSerializer can set the "ownerPassword" and other parameters
based on the current user or request parameters.

The fix is one short function added to
PipelineEventComponentProcessingNode and called in the line that sets
the Parameters of the three child classes. Maintenance would be easy.

I do not understand Joerg's objections:

"IMO it should not be possible..."
Why not?  Anything is possible in Cocoon by adding Java code such as
InputModules.  This is not about what is possible; this is about what
is easy and expected.  Cocoon should be usable without knowing Java.
Nothing in the documentation suggests the second example from the
original post should not work.  Cocoon does not even throw an error to
state the XMAP code is invalid.

"My main point against this functionality is a conceptional difference."
Why should users care about the conceptual difference between
PipelineEvents and ParentProcessors?  The map: elements look equal
when writing an XMAP.  Why should users need to learn that some things
just don't work?

Why not make Cocoon easier and more functional?

(I have held back from creating a JIRA because I was told the dev ML
gains better awareness.  I will not commit code until the change is
approved. The only response is that things should not work like
expected and that functionality will be lost if using Spring so do not
fix currently broken functionality because more might be lost later.
Can someone clarify if this is policy for the Cocoon project?)


View raw message