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=120300503800001&r=1&w=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
