cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Sat, 23 Nov 2002 20:17:32 GMT
Vadim Gritsenko wrote:
> Christian Haul wrote:
> 
> ...
> 
>> A last thought: would it be necessary to have those pipelines match a
>> pattern or would it be sufficiant to have them names?
>>  
>>
> 
> After reading it second time... And seems that Christian also has 
> concern about syntax... There are two ways to understand word "pipeline" 
> and Sylvain's proposal.
> 
> 
>    First Way: A-la Cocoon Source
>    --------------------------------
> 
> Figurally speaking: ProcessingPipeline which "extends" another 
> ProcessingPipeline invokes sitemap (as cocoon source usually do), builds 
> ProcessingPipeline object, and "inserts" it in place of own 
> "pipeline"-typed component. Note: When sitemap is processed, all 
> <pipeline> tags are scanned until complete ProcessingPipeline is built.
> 
> Example sitemap:
>    <pipeline>
>      <match pattern="*.xml">
>        <generate type="file" src="docs/{1}.xml"/>
>        <serialize type="xml"/>
>      </match>
>      <match pattern="*.jpg">
>        <read mime-type src="images/{1}.jpg"/>
>      </match>
>    </pipeline>
>  
>    <pipeline>
>      <match pattern="*.html">
>        <generate type="pipeline" src="{1}.xml"/>
>        <transform src="xml2html.xslt"/>
>        <serialize type="html"/>
>      </match>
>    </pipeline>
> 
> Pipeline built after execution of "test.html" request:
>        <generate type="file" src="docs/test.xml"/>
>        <transform src="xml2html.xslt"/>
>        <serialize type="html"/>
> 
> 
> 
>    Second Way: A-la Text Substitution
>    ------------------------------------
> 
> Figurally speaking: <pipeline> which "extends" another <pipeline> finds 
> named <pipeline> tag and inserts the whole its content in place of 
> "pipeline"-typed component. Note: only named <pipeline> is used, all 
> other pipeline tags are ignored.
> 
> Example sitemap (differs from the above!):
>    <pipeline name="mypipeline">
>      <match pattern="*.html">
>        <generate type="file" src="docs/{1}.xml"/>
>        <serialize type="xml"/>
>      </match>
>      <match pattern="*.jpg">
>        <read mime-type src="images/{1}.jpg"/>
>      </match>
>    </pipeline>
>  
>    <pipeline>
>      <match pattern="*.html">
>        <generate type="pipeline" src="mypipeline"/>
>        <transform src="xml2html.xslt"/>
>        <serialize type="html"/>
>      </match>
>    </pipeline>
> 
> After expansion is made (and serializer is removed):
>    <pipeline>
>      <match pattern="*.html">
>        <match pattern="*.html">
>          <generate type="file" src="docs/{1}.xml"/>
>        </match>
>        <match pattern="*.jpg">
>          <read mime-type src="images/{1}.jpg"/>
>        </match>
>        <transform src="xml2html.xslt"/>
>        <serialize type="html"/>
>      </match>
>    </pipeline>
> 
> Pipeline built after execution of "test.html" request:
>        <generate type="file" src="docs/test.xml"/>
>        <transform src="xml2html.xslt"/>
>        <serialize type="html"/>
> 
> 
> Results are the same, but please note the differences.
> 
> Implementation via the first way is better named as "cocoon"-type 
> components, second way can be named as "pipeline"-type components.

Very interesting reasoning, Vadim. I do see your point.

I don't think you are proposing that we move on the second approach, but 
in case others wonder, I see the first design model much more desirable 
than the second. Here is why:

1) named pipelines remind me of named xslt templates. I think everybody 
here experienced the massive abuse named templates, since they look much 
more 'procedural' to people.

It is very common to see <xsl:for-each> and then <xsl:call-template>, 
while the very same thing could have been accomplished with a simple 
declarative template match.

The sitemap was built to be highly declerative. This was a problem when 
we didn't have a nice way to include procedural flow logic, but now that 
we have the flowscript, we must make all possible efforts to keep the 
sitemap semantics the more declarative as possible.

2) named pipeline will increase the chance of name collisions, unless a 
serious effort for pipeline identification uniqueness is applied.

Note that a pipeline unique identifier will likely become a URI, thus 
falling back on the first case.

3) having named pipelines allows different pipelines to match the same 
URI space and reside in the same sitemap. That might create confusion.

                                 - o -

This said, I really don't like the concept of having something that is 
so important as pipeline inheritance being applied at the same semantic 
level of components that can be removed from the system.

I mean: we managed to have <aggregate> (which is nothing but a 
generator) built into the sitemap semantics, but we fail to have 
something radically important as pipeline inheritance as a 'regular' 
component.

The perceived difference between something like

  <generate type="pipeline" src=".."/>
  <transform .../>
  <serialize .../>

and (I'm just making up a tag name, this is not mandatory at all)

  <delegate-to-pipeline src="{1}.xml"/>
  <transform .../>
  <serialize .../>

or even

  <generate .../>
  <call-pipeline src="{1}.xml"/>
  <transform .../>
  <serialize .../>

is *very* different.

We must provide our users with "incremental learning paths". The value 
of <map:aggregate> compared to <map:generate type="aggregator"> is that 
users perceive the value of having such a concept built into the sitemap 
and they can plan ahead to make an effort to learn the concept or, 
simply, to put it on a side and learn it when they have time.

Flattening everythig at component level just because it is convenient 
implementation-wise is, IMO, a bad design pattern for development of 
usable technology.

What do you people think?

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message