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
