> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
Hi Stefano,
> Vadim Gritsenko wrote:
> >
> > Hi all,
> >
> > Preamble: I do remember we had talks about inward flows, etc... Then
> > somebody (sorry, already forgot who it was) wrote about transformer
> > which writes file as a side effect... Then Kinga proposes to add
> > handlers reacting on input stream/documents... And recently I have
got
> > an idea that it should be quite an elegant way to handle all this if
> > Cocoon is designed symmetrically: whatever abstractions we have to
> > handle outgoing flow, let apply to the in-flow.
>
> Let me start saying that I consider 'simmetry-driven design' the
source
> of all FS.
I could guess this ;)
> So, my FS alarms will be tuned to 'sensible' as we go along.
>
> > First of all, we already (almost) have symmetry in pipelines:
generators
> > are symmetrical to serializers. Generators are able to produce XML
> > content out of almost anything we can think of: physical file, HTTP
> > resource, SQL database, XMLDB database, incoming request, etc.
> > Unfortunately, serializers are somewhat limited comparing to the
> > generators: the only out option we have is output stream. Let's
expand
> > this to the other sources as well. Then we can have, say, file
> > serializer. Coupled with the ability of Sources to handle input
streams,
> > one can save XML stream into file, XMLDB, and other sources were
> > protocol handler exists.
>
> This asymmetric limitation is intentional and due to the architecture
of
> the web: the response goes back to the requestor. Always.
I'm not trying to change this: pipeline must have serializer writing to
the Response output stream.
> In SMTP, for example, this is different. The above is the main reason
> why our (Pier's and mine) proposal for the Mailet API addition to the
> Servlet Framework was rejected: we should have abstracted the concept
of
> 'where does the response goes' that is now implicitly hardwire back to
> the requestor.
>
> So, I perfectly see your point since I already hit that wall once.
>
> > Second. Now Cocoon perfectly handles aggregation, both on sitemap
level
> > and using aggregated transformers. But what we have opposite to the
> > aggregation? Nothing. Let's add separation notion: result will be
> > several SAX streams. Every stream will have a destination pipeline.
This
> > pipeline will be retrieved by "separator", and generator of the
pipeline
> > will be replaced by the "separator" which will feed SAX events into
this
> > pipeline. As you see, it is same mechanism aggregator employs but
> > reversed.
>
> This is admittedly a cool concept but only if designed to replace
> functionality implemented by 'fragment extractors'.
I would say: if designed so 'fragment extractors' is one of the
applications of this concept.
> The idea is to be possible for a pipeline to be 'separated' and
content
> injected into another pipeline,
Yes, that's an idea I'm trying to propose.
> awaiting for the requestor to make
> another request on another URI.
And this is just one of possible usages of the idea.
> This would allow an *easy* way to factor out and rasterize, say,
MathML
> namespaces into included GIFs.
>
> But yes, I think your 'separator' abstraction might be powerful enough
> to allow this.
Agree.
> The only problem I see is that if we go down this path, we have to
> explicitly indicate the 'destination' of the request, since this is
not
> a property of the serializer.
It's not a property of a *serializer*, but this is a property serializer
is *given* by sitemap. Some examples:
<!-- default: response out stream -->
<map:serialize type="jpg" />
<!-- ugly, but straightforward -->
<map:serialize type="jpg" src="C:/Temp/out.pdf"/>
<map:serialize type="jpg" src="xmldb:xindice:/docs/{1}"/>
<!-- analogue to the fragment extractor -->
<map:serialize type="jpg" src="session:{prefix}-jpg"/>
> (ie, I might use the PDFSerializer both to
> send back the serializer to the client or to send an email to somebody
> with it. It's not the serializer's concern, but it's the sitemap's
> concern to attach the right outputStream to the serializer)
Sitemap concern is to specify Source (or Resource), which will provide
outputStream.
> > Third. To top all this, symmetrical component is to be developed to
the
> > X/C Include transformers. As "separator", it will extract parts of
the
> > stream and send them to the other pipelines.
>
> Hmmm, what about X/C Fragment? that would do parallel with
>
> aggregation <----> separation
> inclusion <----> fragmentation
Yes - if it is just naming convention. I agree to any name.
> > At last, let's consider an example. Let it be some request from the
user
> > to perform modification of the XML resource stored in the file (poor
> > man's CMS ;)
> >
> > <!-- inflow internal -->
> > <map:match pattern="get-data">
> > <map:generate src="data.xml"/>
> > <map:serialize type="/dev/null"/>
> > </map:match>
>
> Hmmm, the need of dummy components shows that we have some problems
with
> the sitemap semantics (see below)
It has some positive sides though: (enforced) presence of serializer in
the today's out-flow pipelines allows easy debugging: you can invoke
them manually (till access is disabled by internal-only=true)
> > <map:match pattern="get-mods">
> > <map:generate type="request"/>
> > <map:transform src="request2data-mods.xsl"/>
> > <map:serialize type="/dev/null"/>
> > </map:match>
> >
> > <!-- main -->
> > <map:match src="update">
> > <map:act type="validate-user-input">
> > <map:aggregate>
> > <map:part src="get-mods" element="mods"/>
> > <map:part src="get-data" element="data"/>
> > </map:aggregate>
> > <map:transform src="apply-mods--return-data-and-result.xsl"/>
> > <map:transform src="add-index-update.xsl"/>
> > <map:transform src="add-news-page-update.xsl"/>
> > <map:separate>
> > <map:part src="put-data" element="data"/>
> > <map:part src="update-index" element="index-update"/>
> > <map:part src="update-news" element="index-update"/>
> > <map:part src="update-result" element="result"/>
> > </map:separate>
> > </map:act>
> > </map:match>
> >
> > <!-- outflow internal -->
> > <map:match pattern="put-data">
> > <map:generate type="/dev/null"/>
> > <map:serialize type="file" src="data.xml"/>
> > </map:match>
> >
> > <map:match pattern="update-index">
> > <map:generate type="/dev/null"/>
> > <map:transform type="lucene"/>
> > <map:serialize type="/dev/null"/>
> > </map:match>
> >
> > <map:match pattern="update-news">
> > <!-- ... -->
> > </map:match>
> >
> > <map:match pattern="result">
> > <map:generate type="/dev/null"/>
> > <map:transform type="result2html"/>
> > <map:serialize type="html"/>
> > </map:match>
> >
> > PS: /dev/null: Currently, aggregator ignores serializer. That's to
show
> > that this is the dummy serializer.
>
> Ok, I think you are suggesting something good but I see a few concepts
> that we must think about more:
>
> 1) serializers should have no notion of where their output goes. this
is
> a property of the pipeline.
Agree. If this means that output should be specified via src="". But
type of serializer should mean type of the output it producing, not
destination of this output.
> 2) there are three types of pipeline:
>
> - complete: G -> T* -> S
> - generating: G -> T*
> - serializing: T* -> S
>
> interesting enough, for the in-out flow, internal-only pipelines are
> 'generating pipelines' and views are 'serializing pipelines'.
>
> So, we already have this semantic, we just have to expand it a little.
Ahem.
1. Semantically, views are "exit points" for the other pipelines. They
are not supposed to be used standalone, but to generate different
*views* of the same resource.
2. Technically, views do not have a URI to identify them - which is
required to resolve a Source (Resource in the future).
3. Pragmatically, what would be the behavior of the separator if I
request view, using cocoon-view=links? Does it mean we have to introduce
views of views (recursion)?
Let not spoil view concept, it goes in totally different direction. And
you will be able to use views *with* the concept I'm proposing to
generate, ahem, different views of the same complex pipeline with the
aggregators/separators.
Makes sense?
Vadim
> What do you think?
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
> --------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
