You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2002/02/08 18:21:38 UTC
[RT] Cocoon Symmetry (short :)
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.
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.
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.
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.
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>
<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.
Hope this makes some sense and can be a start for a good discussion :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 7:28 pm +0100 8/2/02, Sylvain Wallez wrote:
>Vadim Gritsenko wrote:
Poor man's CMS, I like that ;)
>>Preamble: I do remember we had talks about inward flows, etc... Then
>>somebody (sorry, already forgot who it was) wrote about transformer
>>
>This is Jeremy Quinn (sharkbait@mac.com), the author of the FP taglib on
>Cocoon 1. He's currently looking for a simple way to store XML input by
>the user, to allow in-browser document edition.
I just managed to get the first version to compile, late last night; not
tried to run it yet (I am a bit tied up today).
It is called FileWritingTransformer, it is based heavily on
XMLDBTransformer (thanks Vadim for a great example ;).
Definition:
<map:transformer name="tofile"
src="org.apache.cocoon.transformation.FileWritingTransformer">
<map:parameter name="serializer" value="xml"/>
</map:transformer/>
Invocation:
<map:transform type="tofile">
[<map:parameter name="serializer" value="xml"/>]
</map:transform>
Input document example:
<page xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0">
...
<xfwt:write src="context://doc/editable/my.xml" [serializer="xml"]>
<page>
XML Object body
</page>
</xfwt:write>
...
</page>
Output document example:
<page xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0">
...
<xfwt:write src="/actual-path/to/context/doc/editable/my.xml"
result="success|failure" serializer="xml">
[failure message]
</xfwt>
...
</page>
You give the Transformer the name of a Serializer (previously set up in the
Sitemap) that you want it to use.
The Serializer can be set in 3 places depending ion requirements,
Definition, Invocation or in the xml stream. All these config options look
like FS, but while I am working out how best to use it, I thought I would
leave them all in.
The point is, that the stream could contain any number of fragments to
write to files, they should each be able to use a different Serializer if
required.
One last thing, I wrote the Transformer with the assumption that it should
not be able to create new files, just overwrite old ones.
I felt if you need new files created then you would write an Action to do
this (from a Template maybe).
My idea was that by simplifying things in this way, it would be more likely
that this component could meet generic needs. If people want to 'lock'
files during editing, or make a backup of a file before overwriting, then
this is an application issue that can be handled by Actions.
The next class I have planned will be a Configurable Generator, very much
like the RequestGenerator, but can optionally parse the contents of
individual Form Fields (depending on the config) into the Stream, so that
XML can be edited in different form fields.
Only thing that is still bugging me about this ..... I remember from the FP
days, when you send XML out in Form Fields to the Browser via the HTML
Serializer, any tags in your XML that have (unclosed) HTML equivalents
(like <br/>, <hr/>, <li/> etc.) get messed up by the Serializer!!
Code should be on it's way in a couple of days (I'll stick it in Scratchpad?).
Suggestions welcome!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Symmetry (short :)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> 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
> >
> This is Jeremy Quinn (sharkbait@mac.com), the author of the FP taglib
on
> Cocoon 1. He's currently looking for a simple way to store XML input
by
> the user, to allow in-browser document edition.
Ok :)
> >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.
> >
> >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.
> >
> I'm discussing off-list about this kind of things with Jeremy and I
> proposed, just like java.net.URL which is a two-way object, to extend
> Source so that is also becomes two-way :
I do remember this; also Berin has said something about Sources in
Avalon which are also two-way.
> public interface WriteableSource extends ModifiableSource {
> OutputStream getOutputStream();
> ContentHandler getContentHandler();
> }
>
> This allows for byte-based or XML-based repositories. A byte-based
> implementation will return a serializer to its input from
> getContentHandler, and an XML-based implementation will put a parser
in
> front of getOutputStream.
I don't get this. Why do you need output stream if Cocoon's pipeline is
SAX stream? Serializer will need only to call getContentHandler() on the
source and send everything to it. Then, source implementation will
convert SAX events into byte stream (for files, or HTTP byte stream for
remote sources (destinations :), or will forward events to XMLDB
resource) as it receives them. Did I miss something?
> Also WriteableSource extends ModifiableSource, because you're very
> likely to also read from where you write to.
Agreed.
> This integrates smoothly in
> the current Cocoon architecture : some SourceFactories will be able to
> create WriteableSources, other's won't.
May be. Have to look at it closely :)
> > 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.
> >
>
> I also had such thoughts : do you know Transmorpher at
> http://transmorpher.inrialpes.fr/ ? It implements all this with a
> sitemap-like language. The whitepaper is really interesting.
Nope.
> >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.
> >
> >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>
> >
> ><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.
> >
> A note about the syntax : for "separate" and "serialize" we should use
> "dest" instead of "src", which is confusing since this is where data
is
> sent, and not where it comes from.
That's something minor we can fix as we go :)
> >Hope this makes some sense and can be a start for a good discussion
:)
> >
> >Vadim
>
> Sure, as it fills an important need and it seems many people have some
> thoughts about it.
>
> Now we may have a problem with serializers : the request/response on
> which Cocoon is built requires a *single* response. A single
serializer
> can write to the response, and others should act by side effect on the
> environment (using a WriteableSource) and cannot write back to the
response.
>
> We could introduce a distinction between serializers and "writers"
that
> output to WriteableSources, but this would limit the reuseability of
> pipelines.
Agreed. I prefer do not make any distinctions.
> So maybe this could be checked by the enhanced pileline
> (which would be a tree) : there should be one and only one serializer
> writing to the response in a pipeline.
I think that even check is not required. If you think how separator
works (extracts certain elements and forwards to the other pipelines),
you will see that every map:part is processed consecutively. Suppose
that you have to serializers requiring output stream, than the first
serializer which gets output stream, will process it to the end, will
close it, and only then any other serializer will have a chance to get
ouput stream. And at this moment, it will be already closed.
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
>
This is Jeremy Quinn (sharkbait@mac.com), the author of the FP taglib on
Cocoon 1. He's currently looking for a simple way to store XML input by
the user, to allow in-browser document edition.
>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.
>
>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.
>
I'm discussing off-list about this kind of things with Jeremy and I
proposed, just like java.net.URL which is a two-way object, to extend
Source so that is also becomes two-way :
public interface WriteableSource extends ModifiableSource {
OutputStream getOutputStream();
ContentHandler getContentHandler();
}
This allows for byte-based or XML-based repositories. A byte-based
implementation will return a serializer to its input from
getContentHandler, and an XML-based implementation will put a parser in
front of getOutputStream.
Also WriteableSource extends ModifiableSource, because you're very
likely to also read from where you write to. This integrates smoothly in
the current Cocoon architecture : some SourceFactories will be able to
create WriteableSources, other's won't.
> 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.
>
I also had such thoughts : do you know Transmorpher at
http://transmorpher.inrialpes.fr/ ? It implements all this with a
sitemap-like language. The whitepaper is really interesting.
>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.
>
>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>
>
><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.
>
A note about the syntax : for "separate" and "serialize" we should use
"dest" instead of "src", which is confusing since this is where data is
sent, and not where it comes from.
>Hope this makes some sense and can be a start for a good discussion :)
>
>Vadim
>
Sure, as it fills an important need and it seems many people have some
thoughts about it.
Now we may have a problem with serializers : the request/response on
which Cocoon is built requires a *single* response. A single serializer
can write to the response, and others should act by side effect on the
environment (using a WriteableSource) and cannot write back to the response.
We could introduce a distinction between serializers and "writers" that
output to WriteableSources, but this would limit the reuseability of
pipelines. So maybe this could be checked by the enhanced pileline
(which would be a tree) : there should be one and only one serializer
writing to the response in a pipeline.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by Mikhail Fedotov <mi...@kittown.com>.
Hi!
> Please elaborate more. I don't see what a transformer
> isn't able to do in the current implementation.
I've been talking that it _can_ do almost the same thing
that a symmetric serializer is expected to do, i.e. we can
save response to disk, send something somewhere and do
virtually anything else in transformer. We don't need
specific serializer for that.
> But I don't see how this is related to the Subject
> "[RT] Cocoon Symmetry".
I mean that we [xml/cocoon addicts :)] _already have_
functionality of symmetric serializer via use of
transformers, the only deviation is that we still need to
wait for some response after request. And this is good
since it allows to keep track of request results.
That's the point of special symmetric serializer ?
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by giacomo <gi...@apache.org>.
On Sun, 10 Feb 2002, Mikhail Fedotov wrote:
> Hi!
>
> > This asymmetric limitation is intentional and due to the
> > architecture of the web: the response goes back to the
> > requestor. Always.
>
> > In SMTP, for example, this is different.
>
> I'm not thinking about cocoon as a tool only for formatting
> and showing requested stuff. For example, I might need to
> send a message via email or any other way without any
> response, and then get response in the form of another
> request from remote system. Meaningful response in both
> cases would be "I've got your message, thanks" or
> "something wrong at the stage or parsing or processing or
> sending, when the actual sending happens in some
> transformer.
Nothing prevents you doing so in the current cocoon machinery.
> So there is no programming problem with that asynchronous
> stuff if the whole process doesn't take much time, if just
> has to be done as an transformer which does the job of
> serializing your stuff the way you want and then gives
> back simple response to say that everything is ok.
>
> The only problem is that this transformer does things that
> thasformers aren't supposed to do, but it don't think it
> is a big problem.
Please elaborate more. I don't see what a transformer isn't able to do
in the current implementation.
> Hmm... We have some email-related logicsheets. Why don't
> implement the same thing as a transformer ? One XML on
> input with email-related fragment, another XML on output
> with that fragment replaced with "Your message was sent
> successfuly" stuff, and then we apply some fancy
> formatting using xslt formatter. This way we can evade
> compiling of xsp.
You're absolutely welcome to send some code and patches to achieve
that. But I don't see how this is related to the Subject "[RT] Cocoon
Symmetry".
Giacomo
>
> Mikhail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by Mikhail Fedotov <mi...@kittown.com>.
Hi!
> This asymmetric limitation is intentional and due to the
> architecture of the web: the response goes back to the
> requestor. Always.
> In SMTP, for example, this is different.
I'm not thinking about cocoon as a tool only for formatting
and showing requested stuff. For example, I might need to
send a message via email or any other way without any
response, and then get response in the form of another
request from remote system. Meaningful response in both
cases would be "I've got your message, thanks" or
"something wrong at the stage or parsing or processing or
sending, when the actual sending happens in some
transformer.
So there is no programming problem with that asynchronous
stuff if the whole process doesn't take much time, if just
has to be done as an transformer which does the job of
serializing your stuff the way you want and then gives
back simple response to say that everything is ok.
The only problem is that this transformer does things that
thasformers aren't supposed to do, but it don't think it
is a big problem.
Hmm... We have some email-related logicsheets. Why don't
implement the same thing as a transformer ? One XML on
input with email-related fragment, another XML on output
with that fragment replaced with "Your message was sent
successfuly" stuff, and then we apply some fancy
formatting using xslt formatter. This way we can evade
compiling of xsp.
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by giacomo <gi...@apache.org>.
On Sun, 10 Feb 2002, Stefano Mazzocchi wrote:
> Vadim Gritsenko wrote:
<snipped/>
> >
> > 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.
Absolutely!
> 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'.
And to complete the picture "resources" are complete pipelines.
This helps us finding a better way to structure the sitemap.
- complete: G -> T* -> S ==> <resource>
- generating: G -> T* ==> <source> (this needs a better name)
- serializing: T* -> S ==> <view>
Maybe we should solve the unfinished semantic with the "internal-only"
pipelines first (which you are mentioning as generating pipelines).
And now we could have the <pipeline>s section be the mapping
descriptions from whatever to <resource>s which could pick up <view>s
and/or compose themselfs by means of <source>s.
> So, we already have this semantic, we just have to expand it a little.
That's what I've already mentioned. There is in my opinion no need to
distinguish in from out flow as the mechanism is request -> response
which includes input processing and output processing. For me a general
form of the process is:
request (1)
+
--> analysis of the request (2)
+
--> prepare analysis result for processing (3)
+
--> process request (4)
+
--> prepare processing results for response (5)
+
--> response (6)
(1) this is what we get from the servlet engine
(2) this is what we do to abstract the environment
(3) this is what the sitemap is doing to match/select/act/generate upon
request aspects.
(4) this is what generators/transformers might do to satisfy the request
in a general sense.
(5) this is what transformers do to fit the respose to a certain
environment
(6) this is what the serializer in question produces
(1),(2) and (3) is what the in flow is about
(4) is the core processing of a request
(5) and (6) is what the out flow is about
You probably see that some parts do overlap (mainly generation and
transformation) but this is because both type of processing can be used
to different kind of actions.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Symmetry (short :)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
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.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
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.
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'.
The idea is to be possible for a pipeline to be 'separated' and content
injected into another pipeline, awaiting for the requestor to make
another request on another URI.
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.
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. (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)
> 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
> 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)
> <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.
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.
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Symmetry (short :)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: giacomo [mailto:giacomo@apache.org]
>
> On Fri, 8 Feb 2002, Vadim Gritsenko wrote:
>
> Well, I still solve inwards flows with two pipelines:
>
> <map:match pattern="in-pipe">
> <map:generate type="stream"/>
> <map:transform type="save-to-xmldb">
> <map:parameter name="node" value="/page/content"/>
> </map:transform>
> <map:serializei type="/dev/null"/>
> </map:match>
>
>
> <map:match pattern="in">
> <map:generate src="cocoon:/in-pipe"/>
> <map:transform/>
> <map:serialize/>
> </map:match>
>
>
> The first pipeline represents the "input" pipe and can be protected in
a
>
> <pipeline internal-only="true">
>
> pipeline. This "in-pipe" pipeline has what ever generator you need to
> get to data comming in. For XML data send by a client I use the
> StreamGenerator and use a custom Transformer to save the payload where
> ever I need to have it (sure you can generalize those transformers to
be
> configurable, etc.)
I'm aware of such possibility, and it does not seem to me as a generic
and flexible enough way, not to tell that it's not goes well with the
overall Cocoon beauty. In the preamble I mentioned this - Transformer
with side effect - way.
> In the sample above I use a transformer capable to
> select a node or node set (/page/content) out of the SAX stream
> generated and save it into a XML db. It will leave a status in the SAX
> pipe.
>
> The second pipeline represents the "out-pipe" to give a response to
the
> client. It will prepare the response using a xslt transformer.
>
> Sure you can combine those two pielines as separation in this specific
> context doesn't make sense. But I wanted to make sure you distinguish
> the input-pipeline from the output-pipeline.
They are distinguished well: input pipelines are on the top of the
sample, output - on the bottom; input pipelines do not have serializers,
output pipelines do not have generators; both of them are internal-only
by semantic and can be protected by internal-only="yes" syntax.
> So, you can have whatever kinds of storing components you
> need implemented as a transformers.
Yes. But for some reason they better look like serializers.
> If the request payload is not xml
> you need to do the storing at the generator level.
Or even better: serializer level.
> I don't think it's a big deal to come up with simple transformers and
> generators to accomplish our needs
Yes, you can overcome lack of separation concern by adding all the
needed transformers.
> but one for sure
Don't be so sure, 'cause...
> is that you
> don't get true symmetry because the current sitemap always needs to
> have a serializer at the end of a pipeline even it is never used (as
in
> all "internal-only"pipelines).
...there is a true symmetry here: output pipeline always needs to have a
generator at the beginning of a pipeline even it is never used.
Let's continue :)
Vadim
> Giacomo
>
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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>
> >
> > <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.
> >
> >
> > Hope this makes some sense and can be a start for a good discussion
:)
> >
> > Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Symmetry (short :)
Posted by giacomo <gi...@apache.org>.
On Fri, 8 Feb 2002, Vadim Gritsenko wrote:
Well, I still solve inwards flows with two pipelines:
<map:match pattern="in-pipe">
<map:generate type="stream"/>
<map:transform type="save-to-xmldb">
<map:parameter name="node" value="/page/content"/>
</map:transform>
<map:serializei type="/dev/null"/>
</map:match>
<map:match pattern="in">
<map:generate src="cocoon:/in-pipe"/>
<map:transform/>
<map:serialize/>
</map:match>
The first pipeline represents the "input" pipe and can be protected in a
<pipeline internal-only="true">
pipeline. This "in-pipe" pipeline has what ever generator you need to
get to data comming in. For XML data send by a client I use the
StreamGenerator and use a custom Transformer to save the payload where
ever I need to have it (sure you can generalize those transformers to be
configurable, etc.) In the sample above I use a transformer capable to
select a node or node set (/page/content) out of the SAX stream
generated and save it into a XML db. It will leave a status in the SAX
pipe.
The second pipeline represents the "out-pipe" to give a response to the
client. It will prepare the response using a xslt transformer.
Sure you can combine those two pielines as separation in this specific
context doesn't make sense. But I wanted to make sure you distinguish
the input-pipeline from the output-pipeline.
So, you can have whatever kinds of storing components you
need implemented as a transformers. If the request payload is not xml
you need to do the storing at the generator level.
I don't think it's a big deal to come up with simple transformers and
generators to accomplish our needs but one for sure is that you
don't get true symmetry because the current sitemap always needs to
have a serializer at the end of a pipeline even it is never used (as in
all "internal-only"pipelines).
Giacomo
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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>
>
> <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.
>
>
> Hope this makes some sense and can be a start for a good discussion :)
>
> Vadim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org