cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: Overloaded pipeline elements (Was Re: [RT] FOM)
Date Sat, 31 May 2003 15:49:11 GMT
Marc Portier wrote:
> Christian Haul wrote:
>> On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
>>> Christian Haul wrote:
>>>> <map:transformers>
>>>>   <map:transformer logger="sitemap.transformer.encodeURL" 
>>>>                    name="encodeURL"                    
>>>> src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
>>>>   <map:transformer logger="sitemap.transformer.browser"
>>>>                    name="renderForBrowser"
>>>> src="org.apache.cocoon.components.treeprocessor.sitemap.TransformerNodeBuilder">

>>>>       <map:select type="browser">
>>>>           <map:when test="netscape">
>>>>              <map:transform src="stylesheets/{foo}/netscape.xsl" />
>>>>           </map:when>
>>>>           <map:when test="explorer">
>>>>              <map:transform src="stylesheets/{foo}/ie.xsl" />
>>>>           </map:when>
>>>>           <map:when test="lynx">
>>>>              <map:transform src="stylesheets/{foo}/text-based.xsl" />
>>>>           </map:when>
>>>>           <map:otherwise>
>>>>              <map:transform src="stylesheets/{foo}/html.xsl" />
>>>>           </map:otherwise>
>>>>       </map:select>
>>>>   </map:transformer>
>>>> </map:transformers>
>>>> Even passing parameters to the transformer could be achieved easily by
>>>> adding them to the stack of sitemap variables.
>>>> There is one problem though: dependencies among such declarations
>>>> would make eager initilization difficult. Lazy initialization would
>>>> produce errors only run-time so a mixture needs to be applied.
>>> and to add IMHO it doesn't really help in
>>> - general sitemap readability
>>> - separating the logic bits from the pipeline-config bits
>>> ...but I might be the only one seeing this last emerging advantage in 
>>> this discussion? >>
>> Don't get it. If only generate, transform, and serialize is allowed,
>> then these fragments may be used to factor out common parts -- simple
>> parts to be precise. Hiding complexity away has proven successful in
>> programming. But that requires IMHO to allow some logic e.g. matchers
>> and selectors as well.
>> Another approach would be to assemble the pipeline fragments through
>> flow but that seems to spoil SoC.
>> Could you elaborate a little more how you envision this separation,
>> perhaps with a little example?
> I did envision that only simple parts would be defined. And that those 
> parts should get their dynamics from clear named arguments passed (via 
> sitemap params or URI, still don't know) and _not_ from peeking and 
> poking inside request/session/context settings

(have been offline because of a public holliday)

I don't see what's wrong with that since the request can be considered 
as implicit parameter. To the contrary, I would think this violates the 
OO design priciple of information hiding. Using the example, a 
transfomer that is supposed to generate the best representation for a 
client may use more than the browser identification but may also look 
into the capabilities and more.

The calling pipeline should IMHO not care how the perfect representation 
is determined or created.

Otherwise, I would fear that the approach would no scale to complex systems.

Please note that more or less the above is more or less possible by 
using the cocoon: protocol. The main difference here is that the result 
is not available through a URI but through a component hint.

In conjunction with blocks and blocks providing services for other 
blocks or visible from the outside, I believe that it makes sense to do 
the first through component hints alone and the second through URIs.

> Furthermore your remark on spoiling SoC is precisely what I saw current 
> matcher, selectors, actions do?
> Now getting into your rightful demand for an example I thaught to take 
> up yours:
>  <map:transformers>
>    <map:transformer  name="encodeURL" ... />
>    <!-- transformer_renderForBrowser(foo, browser) -->
>    <map:transformer  name="renderForBrowser">
>       <map:transform src="stylesheets/{foo}/{browser}.xsl" />
>    </map:transformer>
>  </map:transformers>
>  <map:full-pipes>
>  <!-- invented this element to prevent confusion
>       with existing stuff, compare to resources
>       as they were intended acording to the mail
>       from Stefano: full-pipes -->
>     <!-- full-pipe_answerXForBrowser(answer, browser) -->
>     <map:full-pipe name="answerXForBrowser">
>       <map:generator src="{answer}.xml" />
>       <map:transformer type="renderForBrowser">
>         <map:parameter name="browser" value="{browser}"/>
>         <map:parameter name="foo" value="answers"/>
>       </map:transformer>
>       <map:serialize
>     </map:full-pipe>
>   </map:full-pipes>

Which illustrates that the transformer is almost useless and does not 
ease the understanding of the full pipeline because the full pipeline 
stays at a very low level of abstraction.

> and keep this distinct from where we can have decision logic:
>   <map:pipelines>
>     <map:pipeline>
>       <map:match ...>
>         <map:action ...>
>           <map:select ...>
>             <!-- x levels nested stuff deciding on
>                  {browser} and {answer} -->
>             <map:call name="answerXForBrowser">
>               <map:parameter name="browser"
>                  value="{../style-for-browser}" />
>               <map:parameter name="answer"
>             </map:call>
>    ... (and all closing stuff to become wellformed)

This does remind me a lot of named templates in XSLT only that those 
declare the expected parameters.

> Hm, can't say I'm really sure here, comments welcome.
> This is probably quite of a revolution compared to what we have now... 
> (so for backwards compat I could see how old style would still be 
> supported)

I think we should wait a little for the other post-2.1-RTs that are in 
the pipe and come back to this later.



C h r i s t i a n       H a u l
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message