cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Pruy <Rainer.P...@Acrys.COM>
Subject Re: PipelineEvents eat children
Date Thu, 21 Feb 2008 14:15:43 GMT
I must state, I never really thought of matchers and selectors as applicable to non-primary
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.


Joerg Heinicke schrieb:
> 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]

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: -  Email:
Registered: Frankfurt am Main, HRA 31151

View raw message