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 Thu, 29 May 2003 08:57:30 GMT


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?
> 
> 	Chris.

Chris,

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

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>


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)


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 might be blowing Stefano's FS and symmetric-design alarms 
completely here, but I can't help seeing the similarity in

   <map:pipelines>
     <map:pipeline>
       <map:match ...>
         <map:call function="answerXForBrowser()">

   function answerXForBrowser(){
	// decision logic ..

	sendPage('answerXForBrowser',
                  {'answer': .., 'browser': ..});
   }


Given that similarity I could see how in some cases the one 
approach would be benificial to the other, or even change over 
time for any particular reason.



-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