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