cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: PipelineEvents eat children
Date Thu, 21 Feb 2008 03:58:18 GMT
On 20.02.2008 21:04, solprovider@apache.org wrote:

> 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):
> <transform>
>    <map:parameter name="name"
> value="{exists:file://path/file1.xml,file1returnValue,file://path/file2.xml,file2returnValue,file://path3/file3.xml,file3returnValue,defaultValue}"/>
> </transform>
> 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.

If your logic is that complex you should use a controller beforehands 
(like flow script). The sitemap was never supposed to be a controller. 
Even existing elements allowing kind of control (map:act) in the sitemap 
were considered erroneous.

> 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.

That's another problem.

> "My main point against this functionality is a conceptional difference."
> Why should users care about the conceptual difference between
> PipelineEvents and ParentProcessors?

Implementation is not a concept, the implementation only follows the 
concept or the requirements. I already metioned the actual difference in 
the last mail.

Joerg

Mime
View raw message