cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Overloaded pipeline elements (Was Re: [RT] FOM)
Date Sat, 31 May 2003 20:03:03 GMT


Christian Haul wrote:
> 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.
> 
> Cheers.
> 
>     Chris.
> 


Yep,

I have to finetune my thoughts on this as well, so the extra time 
is welcome

and your reply now makes me see that the browser-compatibility 
thing is not the best example to be given (I just wanted to 
re-use your example not to throw in the need for getting into a 
new example domain)

browser-compatibility is obviously more in the technical 
publishing domain then it is in the business/arbitrary logic 
domain...

regards,
-marc=


-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message