You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@swipnet.se> on 2002/03/01 00:44:18 UTC
RE: XML-Based Selection (Redirect Serializer?)
Stefano Mazzocchi wrote:
> Michael Homeijer wrote:
<snip/>
> > In the current situation, the pipelines parts for incoming data and the
> > parts for outgoing data are executed without having a
> possibility to change
> > the outgoing pipeline based on the data returned from the incoming part.
>
> Again, please, give us a clear example on this.
<snip/>
> My irrational perception says that having selectors react on what flows
> into the pipes mixes concerns: in fact, selectors should 'route' the
> content of the pipeline, while the pipelines content should 'passively'
> be routed around by the external machinery.
>
> What do others think about this?
IMHO, introducing xml based selectors would be a _major_ step in making
Cocoon as good for input handling as for output handling. Why is that? I
think an important asymetry between input and output handling in Cocoon is
that output handling is about data structures: XML, while input is mainly
handled in terms of simple data types, like strings in request headers and
parameters. Matchers, selctors and actions provide good mechanisms for
choosing output pipline based on such simple input.
While an XML document describes data as well as its interrelationships, the
request parameters does not include any information about relations at all,
this structure must be coded in the input handling code instead. No wonder
that it is hard to write reusable input handling components.
Maybe we would prefer to have structured data - XML in the request-body, as
for XForms, SOAP or WebDAV, or any input that would be easily transformed to
XML. Then, things become more complicated: The "natural" place for XML is a
pipeline so that we can reuse all the existing pipeline components and
especially so that e.g. xslt can be used to modify the input. Unfortunally
this is currently not a good idea becase, as soon as one have started a
pipeline it is not possible to do any conditional composition of the
pipeline anymore. And conditional processing is realy needed when input is
handled. First: it is a good idea to validate input data. One possiblity is
to have a "ValidationTransformer" that, based on a schema, annotates the
input elements with error data. If the input have field errors, we probably
want to resend the partially filled in input form with error messages
otherwise the data should continue to the next step in the pipeline. This
kind of validation handling could easily be implemented with an xml based
selector. See:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100745068703675&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100750124213953&w=2
for more details about xml input validation.
After having validated our data we might want to use a transformer with side
effects for storing it or for using it as input to some business logic.
Especially with the recent introduction of the WriteableSourceTransformer,
this seem like an important scenario. But transformers with side effects can
fail, and in this case they should generate an (XML) output that tells what
went wrong, and as different responses to the user for success and failure
seem appropriate, we have another use case for the xml based selector.
Time for an example:
<map:match pattern="userDataInsert.xml">
<map:generate type="stream"/>
<map:transform src="userData.xsd" type="validator"/>
<map:pipe-selector type="xpath">
<map:when test="/*/@fatal-error">
<map:transform src="structureErrors.xsl"/>
</map:when>
<map:when test="/*/@field-error">
<map:transform src="userDataForm.xsl"/>
</map:when>
<map:otherwise>
<map:transform type="file-writer" dest="userData.xml"/>
<map:pipe-selector type="xpath">
<map:when test="/result/file-writen='true'">
<map:transform src="reportInsertResult.xsl"/>
</map:when>
<map:otherwise>
<map:transform src="reportInsertError.xsl"/>
</map:otherwise>
</map:pipe-selector>
</map:otherwise>
</map:pipe-selector>
<map:serialize/>
</map:match>
The "pipe-selector" must collect all input XML in e.g. a DOM-tree before it
can make its chooice. The "validator" anotates the input data with
attributes that describe the result of the validation. The "file-writer" is
suposed to describe the result of the write in its output.
The functionality in the example could be implemented in current Cocoon by
e.g. placing all flow control logic in an xslt-transformer, but in that case
the sitemap does not say much about what happens in the aplication and reuse
is mainly based on import of xslt documents. Another possibility is to
prepare for all conditional processing by processing XML-data in an action
set, but if pipeline processing is needed, one have to write actions that
read and write dom-trees in the request attributes. This means that we will
need action-variants of several of the existing transformers - not that
elegant.
There has been some discusions about the need for "input pipelines" in
Cocoon, IIRC someone described the idea as: an input pipeline, followed of
an action set followed of an output pipeline. I think this idea is fairly
related to xml based selection. As there IMHO is a real need for several
chooice points in a pipeline (as in the example), I prefer xml based
selection.
To conclude: I belive that xml based selection together with transformers
with side effects can considerably reduce the need for actions and that it
would make it much easier to write Cocoon aplications that takes xml input.
What do you think?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> I have done some more thinking and have started to build a prototype. I
> decided that it would be easier to build it in the treeprocessor, so I will
> describe the design this far in terms of the treeprocessor interfaces and
> classes.
<snip/>
> Given that the design above actually work, it seem possible to implement
> pipe-aware selection without messing with any interfaces at all in Cocoon.
Ok, good.
> The somewhat implicit transport of the dom-tree is maybe a kludgy solution,
> it might be better to have a new interface that makes that communication
> more explicit. But in any case we should _not_ change the Selector
> interface.
Ok, I think we all agree on this point.
<snip/>
> With the design above I think the existing cash mechanisms should be usable
> as is, the EventPipeline before the selection could be cached and then the
> selection mechanism could be applied on the cached data and the content in
> the chosen "when clause" can be cached in turn. But this scheme would be
> unnecessarily inefficient: it would be better to also store a mapping
> between the cash key for the "input pipeline" and the "when clause" that is
> chosen for that input pipeline, so that the tests does not have to be
> recalculated.
ok
> <snip/>
>
> > > Performance: it would of course better to not be forced to store the
> > > SAX-events in DOM-tree, but I do not see much choice.
> >
> > Well, this is not a problem since XSLT processing works this way anyway,
> > but an XPath engine can be made much more incremental than a XSLT-one.
> Might be doable in principle, but I would guess that it could be hard to
> reuse this functionality from an existent XSLT implementation. I have some
> previous (very bad)
> experience from trying to reuse low level mechanisms in Xalan for an
> extension element, and have to forget about that experience before I will
> repeat that mistake ;)
ok
> > Also, it might be possible that not much load is given to these pipes
> > since they are mostly used in data INPUT which is normally much less
> > than data OUTPUT in any site.
> Yes, that is what I believe, IMHO it seem unnecessary to implement
> complicated optimizations before there are clear use cases for them. It
> should also be noted that selection based on validation _can not_ be done in
> streaming mode, the whole document must be validated before we know that it
> is valid, i.e. buffering is necessary.
hmmm, don't know, there are cases where XML validation can be a
sequential process, but the same thoughs on XSLT apply here.
Anyway, I'd love to place your eventual contribution in the scratchpad
and see what people think about it and what performance it gets.
Also, I would love to see how this merges with Vadim's thoughs on
'multiplexers'... but I have the impression that we can work
incrementally, so you shouldn't stop your effort.
Who knows: maybe the new interface you are wondering for above might be
Multiplexer and Vadim could reuse part of your code to implement it.
Bah, dunno, just thinking out loud...
--
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: Pipe-aware Selectors [was Re: XML-Based Selection (Redirect Serializer?)]
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>
> > The pipe-selector (ideas about a better name?) would look something like
> > this:
> > <pipe-selector type="xpath">
> > <when test="expr1">
> > <!-- pipeline fragment -->
> > </when>
> > <when test="expr2">
> > <!-- pipeline fragment -->
> > </when>
> > ...
> > <otherwise>
> > <!-- pipeline fragment -->
> > </otherwise>
> > </pipe-selector>
> >
> > The general idea is that the pipe-selector buffers it input in e.g. a
> > DOM-tree, then the tests can be applied to the buffered input.
> The pipeline
> > fragment in the first when clause where the test succeed is
> then feeded with
> > the buffered input, and its output is send to the pipeline
> component after
> > the pipe selector.
>
> Ok, I see your point clearly.
Good :)
> > How can this be implemented?
I have done some more thinking and have started to build a prototype. I
decided that it would be easier to build it in the treeprocessor, so I will
describe the design this far in terms of the treeprocessor interfaces and
classes.
<background-info>
For those who had not yet studied the treeprocessor there are two main
interfaces: ProcessingNodeBuilder, implemented by e.g. SelectNodeBuilder,
and ProcessingNode, implemented by e.g. SelectNode. The node builders are
used to construct a processing tree from the sitemap, and a FooNodeBuilder
typically puts an instance of FooNode in the tree. The tree typically get
the same structure as the elements in the sitemap. The ProcessingNodes
implement:
boolean invoke(Environment env, InvokeContext context)
where the InvokeContext among other things contains the current
EventPipeline and StreamPipeline, invoke drives the execution of a request.
Generators and Transformers are pushed into the EventPipeline, a Serializer
is put in the StreamPipeline and starts the execution of the pipeline.
Sitemap elements with children decide how to process the children.
</background-info>
To implement pipe aware selection as in the above sitemap example we need 4
classes: PipeSelectNodeBuilder, PipeSelectNode, DOMGenerator and
XPathSelector.
PipeSelectNodeBuilder: is like SelectNodeBuilder but puts PipeSelectNodes
instead of SelectNodes in the tree, it should possibly also implement
LinkedProcessingNodeBuilder to enable view-labels on a pipe-aware selector.
PipeSelectNode: extracts the current EventPipeline from the InvokeContext,
connects a DOMBuilder to the EventPipeline and executes it. The resulting
dom-tree is stored in the objectModel and a new InvokeContext is created
with a newly created EventPipeline that starts with a DOMGenerator, and the
StreamPipeline from the incoming InvokeContext. After these steps the invoke
method in PipeSelectNode will do exactly the same things as in the
SelectNode but with the new InvokeContext as input.
DOMGenerator: takes the stored dom-tree from the objectModel and applies a
DOMStreamer on it.
XPathSelector: implements the Selector interface, and its select method
takes the dom-tree from the object model and returns the (boolean) result of
the application of the XPath on it.
Given that the design above actually work, it seem possible to implement
pipe-aware selection without messing with any interfaces at all in Cocoon.
The somewhat implicit transport of the dom-tree is maybe a kludgy solution,
it might be better to have a new interface that makes that communication
more explicit. But in any case we should _not_ change the Selector
interface.
Of course all this should have been said in Java-code and not words ;) I
hope to be able to finish a first prototype soon.
<snip/>
> Hmmm, I don't think this behavior should extend Transformer's, smells
> like a bad design choice to me.
The above design takes away that.
<snip type="some incomprehensible thoughts on caching"/>
> Sorry, I think I lost you here. :/
A new trial:
With the design above I think the existing cash mechanisms should be usable
as is, the EventPipeline before the selection could be cached and then the
selection mechanism could be applied on the cached data and the content in
the chosen "when clause" can be cached in turn. But this scheme would be
unnecessarily inefficient: it would be better to also store a mapping
between the cash key for the "input pipeline" and the "when clause" that is
chosen for that input pipeline, so that the tests does not have to be
recalculated.
<snip/>
> > Performance: it would of course better to not be forced to store the
> > SAX-events in DOM-tree, but I do not see much choice.
>
> Well, this is not a problem since XSLT processing works this way anyway,
> but an XPath engine can be made much more incremental than a XSLT-one.
Might be doable in principle, but I would guess that it could be hard to
reuse this functionality from an existent XSLT implementation. I have some
previous (very bad)
experience from trying to reuse low level mechanisms in Xalan for an
extension element, and have to forget about that experience before I will
repeat that mistake ;)
> Also, it might be possible that not much load is given to these pipes
> since they are mostly used in data INPUT which is normally much less
> than data OUTPUT in any site.
Yes, that is what I believe, IMHO it seem unnecessary to implement
complicated optimizations before there are clear use cases for them. It
should also be noted that selection based on validation _can not_ be done in
streaming mode, the whole document must be validated before we know that it
is valid, i.e. buffering is necessary.
What do you think?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Pipe-aware Selectors [was Re: XML-Based Selection (Redirect
Serializer?)]
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> The pipe-selector (ideas about a better name?) would look something like
> this:
> <pipe-selector type="xpath">
> <when test="expr1">
> <!-- pipeline fragment -->
> </when>
> <when test="expr2">
> <!-- pipeline fragment -->
> </when>
> ...
> <otherwise>
> <!-- pipeline fragment -->
> </otherwise>
> </pipe-selector>
>
> The general idea is that the pipe-selector buffers it input in e.g. a
> DOM-tree, then the tests can be applied to the buffered input. The pipeline
> fragment in the first when clause where the test succeed is then feeded with
> the buffered input, and its output is send to the pipeline component after
> the pipe selector.
Ok, I see your point clearly.
> How can this be implemented?
>
> The pipe-selector is a transformer (i.e. implements the transformer
> interface) extended with a method that lets the sitemap constructor send an
> object to the pipe-selector that takes care of the tests and the pipeline
> fragment construction for the selected when clause in the pipe-selector.
>
> The actual tests can implement the selector interface if it is ok to put the
> DOM-tree with buffered input in the objectModel. A possible issue with this
> is that the tests in the selector are performed after that the whole
> pipeline is constructed. This might give the unintuitive effect that
> components later in the pipeline that effects the objectModel and is
> executed during sitemap construction time are executed before the test in
> the pipe-selector.
Hmmm, I don't think this behavior should extend Transformer's, smells
like a bad design choice to me.
> The sitemap stylesheet constructs a class for each pipe-selector instance in
> the sitemap. This class contains a method that returns a EventPipeline. The
> method executes the tests and constructs and returns an EventPipeline for
> the first when clause that succeed. The EventPipline starts with a generator
> puts the DOM-tree in the objectModell in a DOMStreamer.
>
> class PipeSelectorInternalPipeN01234 {
> public EventPipeLine constructPipe(SitemapRedirector redirector,
> Environment environment,
> List listOfMaps) { ... }
> }
>
> The code in sitemap_xmap for constructing the pipeline that contains a
> pipe-selector is like that for any pipeline that contains a transformer,
> with the difference that the "pipe-selector transformer" is given an
> instance of its PipeSelectorInternalPipe class.
>
> The algoritm for the PipeSelector is:
> * Its input is connected to a DOMBuilder.
> * The DOM-tree is put in the objectModel.
> * The constructPipe(...) method of the PipeSelectors
> PipeSelectorInternalPipe class is executed.
> * The returned EventPipeline is connected to the output of the PipeSelector
> and the EventPipelines process method is called.
>
> I hope that the description above is comprehensible.
I'm *seriously* worried about the need to buffer the input.
> > 2) how does this impact performance? how does this impact caching?
> >
> > [the first impacts the system usage, the second the interface of
> > Selectors or PipeSelectors]
>
> The simplest way to implement cashability is to base the cash key generation
> on _all_ of the pipeline fragments in the when clauses. This is fairly
> unsatisfying as it implies the construction of all of the pipeline fragments
> instead of only the one that is selected. It will also decrease the
> possibility to cash the PipeSelector and lead to unnecesary recalculation
> based on changes in "when clauses" that was not selected. The problem is
> that when the generateKey() method is called it is not known what "when
> clause" that will be choosen. If we however had a method like
> generateKey(key), where "key" is the hash key for the pipeline fragment
> before the PipeSelector, "key" uniquely determines the input to the
> PipeSelector and thus what "when clause" that will be selected, this
> information: the map from key to "when clause", could be stored and the used
> to compute the cach key for the PipeSelector only based on the pipeline
> fragment in the _selected_ when clause.
Sorry, I think I lost you here. :/
> Performance: it would of course better to not be forced to store the
> SAX-events in DOM-tree, but I do not see much choice.
Well, this is not a problem since XSLT processing works this way anyway,
but an XPath engine can be made much more incremental than a XSLT-one.
Also, it might be possible that not much load is given to these pipes
since they are mostly used in data INPUT which is normally much less
than data OUTPUT in any site.
> The main use for the
> PipeSelector will probably be to make selection based on XML input to Cocoon
> and on the output from transformers with side effects, I would guess that
> for these cases it will most of the time be quite small documents. Besides
> the need for buffering I do not think there should be any sources to
> performance botlenecks in a PipeSelector, but I do not know enogh about the
> internals of Cocoon to know for sure.
>
> What do you think?, would something along this lines work?
Yes, I think it might work, but I still can't see if this requires a
change in the Selector interface or if another sitemap component must be
added.
What do you guys 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: XML-Based Selection (Redirect Serializer?)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
<snip/>
> > To conclude: I belive that xml based selection together with
transformers
> > with side effects can considerably reduce the need for actions and that
it
> > would make it much easier to write Cocoon aplications that takes xml
input.
>
> I think you expressed a very valid point of the need for pipe-based
> selection.
:)
> I have two concerns:
>
> 1) a pipe-selector is really a selector or is it something else?
>
> [translated operationally: should we come up with another interface?]
I am not an expert in the inner workings of the sitemap, so what follows
might not work at all:
The pipe-selector (ideas about a better name?) would look something like
this:
<pipe-selector type="xpath">
<when test="expr1">
<!-- pipeline fragment -->
</when>
<when test="expr2">
<!-- pipeline fragment -->
</when>
...
<otherwise>
<!-- pipeline fragment -->
</otherwise>
</pipe-selector>
The general idea is that the pipe-selector buffers it input in e.g. a
DOM-tree, then the tests can be applied to the buffered input. The pipeline
fragment in the first when clause where the test succeed is then feeded with
the buffered input, and its output is send to the pipeline component after
the pipe selector.
How can this be implemented?
The pipe-selector is a transformer (i.e. implements the transformer
interface) extended with a method that lets the sitemap constructor send an
object to the pipe-selector that takes care of the tests and the pipeline
fragment construction for the selected when clause in the pipe-selector.
The actual tests can implement the selector interface if it is ok to put the
DOM-tree with buffered input in the objectModel. A possible issue with this
is that the tests in the selector are performed after that the whole
pipeline is constructed. This might give the unintuitive effect that
components later in the pipeline that effects the objectModel and is
executed during sitemap construction time are executed before the test in
the pipe-selector.
The sitemap stylesheet constructs a class for each pipe-selector instance in
the sitemap. This class contains a method that returns a EventPipeline. The
method executes the tests and constructs and returns an EventPipeline for
the first when clause that succeed. The EventPipline starts with a generator
puts the DOM-tree in the objectModell in a DOMStreamer.
class PipeSelectorInternalPipeN01234 {
public EventPipeLine constructPipe(SitemapRedirector redirector,
Environment environment,
List listOfMaps) { ... }
}
The code in sitemap_xmap for constructing the pipeline that contains a
pipe-selector is like that for any pipeline that contains a transformer,
with the difference that the "pipe-selector transformer" is given an
instance of its PipeSelectorInternalPipe class.
The algoritm for the PipeSelector is:
* Its input is connected to a DOMBuilder.
* The DOM-tree is put in the objectModel.
* The constructPipe(...) method of the PipeSelectors
PipeSelectorInternalPipe class is executed.
* The returned EventPipeline is connected to the output of the PipeSelector
and the EventPipelines process method is called.
I hope that the description above is comprehensible.
> 2) how does this impact performance? how does this impact caching?
>
> [the first impacts the system usage, the second the interface of
> Selectors or PipeSelectors]
The simplest way to implement cashability is to base the cash key generation
on _all_ of the pipeline fragments in the when clauses. This is fairly
unsatisfying as it implies the construction of all of the pipeline fragments
instead of only the one that is selected. It will also decrease the
possibility to cash the PipeSelector and lead to unnecesary recalculation
based on changes in "when clauses" that was not selected. The problem is
that when the generateKey() method is called it is not known what "when
clause" that will be choosen. If we however had a method like
generateKey(key), where "key" is the hash key for the pipeline fragment
before the PipeSelector, "key" uniquely determines the input to the
PipeSelector and thus what "when clause" that will be selected, this
information: the map from key to "when clause", could be stored and the used
to compute the cach key for the PipeSelector only based on the pipeline
fragment in the _selected_ when clause.
Performance: it would of course better to not be forced to store the
SAX-events in DOM-tree, but I do not see much choice. The main use for the
PipeSelector will probably be to make selection based on XML input to Cocoon
and on the output from transformers with side effects, I would guess that
for these cases it will most of the time be quite small documents. Besides
the need for buffering I do not think there should be any sources to
performance botlenecks in a PipeSelector, but I do not know enogh about the
internals of Cocoon to know for sure.
What do you think?, would something along this lines work?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XML-Based Selection (Redirect Serializer?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
>
> Stefano Mazzocchi wrote:
> >
> > What do others think about this?
>
> IMHO, introducing xml based selectors would be a _major_ step in making
> Cocoon as good for input handling as for output handling. Why is that? I
> think an important asymetry between input and output handling in Cocoon is
> that output handling is about data structures: XML, while input is mainly
> handled in terms of simple data types, like strings in request headers and
> parameters. Matchers, selctors and actions provide good mechanisms for
> choosing output pipline based on such simple input.
>
> While an XML document describes data as well as its interrelationships, the
> request parameters does not include any information about relations at all,
> this structure must be coded in the input handling code instead. No wonder
> that it is hard to write reusable input handling components.
This is true.
> Maybe we would prefer to have structured data - XML in the request-body, as
> for XForms, SOAP or WebDAV, or any input that would be easily transformed to
> XML. Then, things become more complicated: The "natural" place for XML is a
> pipeline so that we can reuse all the existing pipeline components and
> especially so that e.g. xslt can be used to modify the input. Unfortunally
> this is currently not a good idea becase, as soon as one have started a
> pipeline it is not possible to do any conditional composition of the
> pipeline anymore. And conditional processing is realy needed when input is
> handled. First: it is a good idea to validate input data. One possiblity is
> to have a "ValidationTransformer" that, based on a schema, annotates the
> input elements with error data. If the input have field errors, we probably
> want to resend the partially filled in input form with error messages
> otherwise the data should continue to the next step in the pipeline. This
> kind of validation handling could easily be implemented with an xml based
> selector. See:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100745068703675&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100750124213953&w=2
> for more details about xml input validation.
>
> After having validated our data we might want to use a transformer with side
> effects for storing it or for using it as input to some business logic.
> Especially with the recent introduction of the WriteableSourceTransformer,
> this seem like an important scenario. But transformers with side effects can
> fail, and in this case they should generate an (XML) output that tells what
> went wrong, and as different responses to the user for success and failure
> seem appropriate, we have another use case for the xml based selector.
>
> Time for an example:
>
> <map:match pattern="userDataInsert.xml">
> <map:generate type="stream"/>
> <map:transform src="userData.xsd" type="validator"/>
> <map:pipe-selector type="xpath">
> <map:when test="/*/@fatal-error">
> <map:transform src="structureErrors.xsl"/>
> </map:when>
> <map:when test="/*/@field-error">
> <map:transform src="userDataForm.xsl"/>
> </map:when>
> <map:otherwise>
> <map:transform type="file-writer" dest="userData.xml"/>
> <map:pipe-selector type="xpath">
> <map:when test="/result/file-writen='true'">
> <map:transform src="reportInsertResult.xsl"/>
> </map:when>
> <map:otherwise>
> <map:transform src="reportInsertError.xsl"/>
> </map:otherwise>
> </map:pipe-selector>
> </map:otherwise>
> </map:pipe-selector>
> <map:serialize/>
> </map:match>
>
> The "pipe-selector" must collect all input XML in e.g. a DOM-tree before it
> can make its chooice. The "validator" anotates the input data with
> attributes that describe the result of the validation. The "file-writer" is
> suposed to describe the result of the write in its output.
Yes, I clearly see your point.
> The functionality in the example could be implemented in current Cocoon by
> e.g. placing all flow control logic in an xslt-transformer, but in that case
> the sitemap does not say much about what happens in the aplication and reuse
> is mainly based on import of xslt documents. Another possibility is to
> prepare for all conditional processing by processing XML-data in an action
> set, but if pipeline processing is needed, one have to write actions that
> read and write dom-trees in the request attributes. This means that we will
> need action-variants of several of the existing transformers - not that
> elegant.
Agreed.
> There has been some discusions about the need for "input pipelines" in
> Cocoon, IIRC someone described the idea as: an input pipeline, followed of
> an action set followed of an output pipeline. I think this idea is fairly
> related to xml based selection. As there IMHO is a real need for several
> chooice points in a pipeline (as in the example), I prefer xml based
> selection.
>
> To conclude: I belive that xml based selection together with transformers
> with side effects can considerably reduce the need for actions and that it
> would make it much easier to write Cocoon aplications that takes xml input.
I think you expressed a very valid point of the need for pipe-based
selection.
I have two concerns:
1) a pipe-selector is really a selector or is it something else?
[translated operationally: should we come up with another interface?]
2) how does this impact performance? how does this impact caching?
[the first impacts the system usage, the second the interface of
Selectors or PipeSelectors]
anybody else?
--
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