Vadim Gritsenko wrote:
Very interesting reasoning, Vadim. I do see your point.Christian Haul wrote:...A last thought: would it be necessary to have those pipelines match aAfter 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.
pattern or would it be sufficiant to have them names?
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.
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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
