Re: PipelineEvents eat children
[EMAIL PROTECTED] wrote 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. No, it is not - fixing it this way would cause a lot of trouble and break the whole sitemap engine. The current sitemap has been drafted way back in the early days of Cocoon more than eight years ago. One basic concept is that selectors and matchers only define which components are used in the pipeline processing. They've never meant to be used for configuration selection of a single component. This has been discussed for Cocoon 2.0 and it has been this way for the whole time. During all these years this has never been a problem for Cocoon users as it is a very clear concept. Inside selectors you can have any other component like matchers, transformers, you name it. So if we follow your suggestion we have two different kind of selectors. Which will end in handling special cases and special case handling is always bad. Starting to allow selectors for choosing configuration parameters will end in a very very messy and not maintainable sitemap, so Joergs suggestions are a much better way of handling things. Just you can do something without Java coding does not mean that this is the best and cleanest way. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: PipelineEvents eat children
On Feb 20, 2008, at 7:40 PM, Joerg Heinicke wrote: That's why I'm strongly against adding this functionality to the sitemap. +1 (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 ...) Well, beside forming an opinion one needs time to come up with well though out reply - and that takes time... Vadim
Re: PipelineEvents eat children
I must state, I never really thought of matchers and selectors as applicable to
non-primary components.
I think, I can imagine tons of reasons causing such extension of current
functionality to grow into a nightmare of semantic changes
and incompatibilities.
However, this request and the discussion show that is is important with cocoon
documentation to distinguish clearly
what is a (sitemap) component and what are sub-elements that provide to using
/ configuring / etc. such components. As a consequence
this will lead to adding an error message to processing sitemap definitions for
flagging whenever a top level element within a
decisional element is not a (sitemap) component.
(Reading the docs always does lead your thought in such direction, but it
probably will help explicitly stating the difference somewhere.)
I do not see a binding reason to provide support for configuration variability
by means of decisional sitemap elements.
However, I doubt, adding an input module will easily provide same level of
reuse as would be available with decision semantics of
matchers/selectors. Or is there an input module that provides some generally
available if-the-else or even switch semantics, or
actually valuation of expressions on some other input module values? (xpath or
jexl expressions? is it in 2.2? admittedly, I never tried)
So, while I do see (and agree) with the structural cleanness of the input
module approach,
that causes immediate need for more powerful input modules.
Rainer
Joerg Heinicke schrieb:
On 19.02.2008 21:17, [EMAIL PROTECTED] 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] http://marc.info/?t=12030050381r=1w=4
--
Rainer Pruy
Managing Director
Acrys Consult GmbH Co. KG
Untermainkai 29-30, D-60329 Frankfurt, Germany
Phone: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: [EMAIL PROTECTED]
Registered: Frankfurt am Main, HRA 31151
Re: PipelineEvents eat children
On 19.02.2008 21:17, [EMAIL PROTECTED] 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] http://marc.info/?t=12030050381r=1w=4
Re: PipelineEvents eat children
On Wed, Feb 20, 2008 at 7:40 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:
On 19.02.2008 21:17, [EMAIL PROTECTED] 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] http://marc.info/?t=12030050381r=1w=4
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.
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
Re: PipelineEvents eat children
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
PipelineEvents eat children
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
