Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>
<snip/>
>>Isn't the regular URI-matching enough that you need an additional naming
>>scheme ?
>>
>>
>
>No, probably not, but in that case, we need another pipeline state.
>
> - [no attribute] -> similar to java 'public'
> - internal-only="true" -> similar to java 'private'
> - ?? -> similar to java 'protected'
>
>where the pipeline is accessible from the inside and from other blocks,
>but not exposed to the public URI space.
>
>Unfortunately, this requires a different attribute, something like
>
> <pipeline exposure="(public|internal|block)">
>
>
Interesting thought. Let's keep it for when we will discuss the
security-related topics of block.
<snip/>
>For example, we could have done:
>
> <map:generate type="aggregate">
>
>instead of
>
> <map:aggregate ...>
>
>but than we would have left the user the ability to 'remove'
>functionality from the sitemap.
>
>This is why I prefer to encode proper sitemap functionality in its
>semantics, even if, implementation-wise, it would be equivalent to reuse
>the existing component infrastructure.
>
>Do you see my point?
>
>
Yes, and I agree : visible semantic is better than a magical
implementation of another one.
<snip/>
>Admittedly, this very random thinking, but at least it will trigger
>something in your synapses (hopefully :)
>
>
Yes ! But what it triggered isn't exactly what you may have been waiting
for : I'm pretty sure now we both have the same understanding of this
pipeline inheritance and overloading stuff, but each of us re-used
existing but different terms with their associated meanings, leading to
this confusion.
However, you still did not catch what I want to explain. Let's give it
another try with your new <import>, which has no previous history,
unlike <call> or <transform>.
I wish we could join in front of a whiteboard, this would be much easier :)
What I (desperately ;) try to show you is that <import> without
explicitly saying what is to be imported from the target pipeline is
sometimes ambiguous in a _real_ sitemap, containing several matchers
building several different pipelines.
Let's consider a skin pipeline that renders an xdoc as an html page.
This pipeline requires a "doc" parameter which should be passed by the
caller (let's not argue about argument passing, as this is yet another
problem!) :
<pipeline name="doc2html">
<generate src="{doc}.xml"/>
<transform src="doc2html.xsl"/>
<serialize type="html"/>
</pipeline>
Now let's consider the typical doc generation statements :
<match pattern="*.html">
<import name="doc2html">
<parameter name="doc" value="{1}"/>
</import>
</match>
No problem here : we import the full "doc2html" pipeline.
Now, let's consider the case of the FAQ which has a special DTD :
<match pattern="faq.html">
<generate src="faq.xml"/>
<transform src="faq2doc.xsl"/>
<import name="doc2html">
<parameter name="doc" value="dummy"/>
</import>
</match>
We generate our FAQ, transform it into an xdoc and import the
transformation and serialization of doc2html. The "doc" parameter, used
by the generator, is actually useless and could even have been avoided.
Now let's assemble all this in a sitemap : the internal "doc2html" and
the externally visible pipeline, with "faq.html" matcher first, since it
is more specific than "*.html" :
<sitemap>
<pipeline name="doc2html">
<generate src="{doc}.xml"/>
<transform src="doc2html.xsl"/>
<serialize type="html"/>
</pipeline>
<pipeline>
<match pattern="faq.html">
<generate src="faq.xml"/>
<transform src="faq2doc.xsl"/>
<import name="doc2html">
<parameter name="doc" value="dummy"/>
</import>
</match>
<match pattern="*.html">
<import name="doc2html">
<parameter name="doc" value="{1}"/>
</import>
</match>
</pipeline>
</sitemap>
And here comes the ambiguity that I desperately try to show you : in the
current sitemap syntax, <serialize> marks the end of the pipeline
construction, and consequently the end of the processing of sitemap
statements.
<import>, on the contrary, can be considered as a generator, a
transformer or a serializer *depending on the context*. And the context
of the two matchers above (assembled in a sitemap) *is different* from
the context of each matcher considered separately.
So when we end the <match> for "faq.html", how can we know if pipeline
construction is finished (with the serializer of "doc2html") or if it
should continue with the following statements ? The answer is : we
cannot know.
And worse, if we continue evaluating statements, the second match
("*.html") matches, and we encounter another <import>. What happens here
? Since the pipeline being built already has a generator, will we append
(a second time) the transformer part of "doc2html" ?
That's why I say a more explicit semantic is required. The calling
pipeline *must* explicitly say what is to be included and what is to be
overloaded in the called pipeline. Consider the same sitemap with just
an additional "what" attribute to <import> :
<sitemap>
<pipeline name="doc2html">
<generate src="{doc}.xml"/>
<transform src="doc2html.xsl"/>
<serialize type="html"/>
</pipeline>
<pipeline>
<match pattern="faq.html">
<generate src="faq.xml"/>
<transform src="faq2doc.xsl"/>
<import name="doc2html" what="transform, serialize">
<parameter name="doc" value="dummy"/>
</import>
</match>
<match pattern="*.html">
<import name="doc2html" what="all">
<parameter name="doc" value="{1}"/>
</import>
</match>
</pipeline>
</sitemap>
I don't pretend this notation is nice, but it carries the required
information : this simple attribute has removed all ambiguities, and we
are able to know exactly what will happen.
Has this triggered something in your synapses ?
;-)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
