On 22.Nov.2002 -- 11:43 AM, Christian Haul wrote:
> On 21.Nov.2002 -- 11:05 AM, Sylvain Wallez wrote:
> >
> > Q: I want do define a pipeline that will be used only as a
> > transformation service. Why must I write a <map:generate> and a
> > <map:serialize> in its definition ?
> >
> > A: Because the sitemap, as a pipeline building language, must be able to
> > determine the start of a pipeline and its end, even if not all its
> > components are used. Like opening and closing braces in Java, the
> > generator begins the pipeline definition and the serializer ends it.
>
> We have the notion of pipelines in the sitemap. Today they are only
> used to get different error handlers. Maybe we should rethink this and
> use the map:pipeline as boundaries.
>
> Another idea would be to place those pipelines acting as generator,
> transformer, serializer in the same part as we do with other
> components of that kind. Problem would be that they would need to use
> other components just introduced there.
>
> A last thought: would it be necessary to have those pipelines match a
> pattern or would it be sufficiant to have them names?
Looks like my reply was too concise to be understandable.
OK, next try:
Sylvain explained, that
A) a generator is a component that produces SAX events
B) a transformer is a component that consumes SAX events
and produces SAX events
C) a serializer is a component that consumes SAX events
and produces a binary stream
Now, I'd like to add
D) a reader is a component that produces a binary stream
A "pipeline" could be any of these (according to the suggestion).
To be more precise: Currently, a pipeline is only D). In conjunction
with the cocoon: protocol, we can have A) as well. A resource is a C)
while we can actually use it as B) as well because of a "bug" in 2.1
This comparison is a bit unfair as a resource for example is only
visible in the current sitemap.
But a pipeline is more: it is also a contract for the external URI
space.
Now, if we step back a little and look at the heart of things, why
would a pipeline need to be referenced by anything else than its name,
and why is a pipeline acting as a transformer placed anywhere else
than the map:transformers section?
This is probably a bit too radical and faces implementation
problems. OTOH, what about e.g.
<map:pipeline type="transformer" name="super_skin">
<!-- ... -->
</map:pipeline>
in the "traditional" map:pipelines section. This could be turned into
a plain Avalon component filling the "transformer" role using the
short hand "super_skin".
Wait -- now, what about the external URI space? That would of course
need the present notation of pipeline. Without a type attribute, that
is. To use one of the new transformers, nothing chances:
<map:pipeline>
<map:match pattern="*">
<map:generate type="file" src="{1}.xml"/>
<map:transform type="super_skin"/>
<map:serialize type="xhtml"/>
</map:match>
</map:pipeline>
I imagine that this could be done with only some tweaking of the
current implementation.
It would however, change the way we currently use the
map:pipelines/map:pipeline section in the sitemap. But there seems to
be little use of it anyways.
So, what about blocks? Blocks would need to provide a way to let other
block access components declared within. Interestingly enough, this
gets easier as we have to deal with fewer different concepts that need
to be visible outside: components, classes, URIs
Oh yes, textual replacement wouldn't do for this.
Does this relate to XSL named templates? No, I don't think it is
related in any way.
So, what do you think?
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
