On 20.02.2008 21:04, [EMAIL PROTECTED] 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
