cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XML-Based Selection (Redirect Serializer?)
Date Fri, 01 Mar 2002 14:41:16 GMT
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:
> 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.


> 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

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.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message