Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of Rainer.Pruy@acrys.com
 designates 212.222.64.34 as permitted sender)
Message-ID: <47BD878F.10201@acrys.com>
Date: Thu, 21 Feb 2008 15:15:43 +0100
From: Rainer Pruy <Rainer.Pruy@Acrys.COM>
Organization: Acrys Consult GmbH & Co. KG
User-Agent: Thunderbird 2.0.0.9 (X11/20071114)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: PipelineEvents eat children
References: <dfe834320802191817q4f8192d2y1154954106b8b9ba@mail.gmail.com>
 <47BCC87F.7030600@gmx.de>
In-Reply-To: <47BCC87F.7030600@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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, solprovider@apache.org 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: office@acrys.com
Registered: Frankfurt am Main, HRA 31151