cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Fagerstrom" <>
Subject [Contribution] Pipe-aware selection
Date Thu, 28 Mar 2002 23:35:54 GMT
I finally found some time to finish a first version of pipe-aware selection.
It has some rough edges and there is no caching yet, but as I think it will
be useful for the current form handling and validation development, I would
like to share my results this far. The example is fairly pointless, I will
try to build something better as soon as I have cached up with the technical
details in the Cocoon input form discussion.

/Daniel Fagerstrom

The README file:

Pipe-aware selectors

This contribution makes it possible to have selectors in a pipeline
that reacts on the output from the previous step in the pipeline.


and the rest of the discussions in the threads:
XML-Based Selection (Redirect Serializer?)
and Pipe-aware Selectors
for motivation. There have also been some discussion about pipe aware
selection in the current threads about form handling and validation.

The main idea is that if the input to Cocoon is XML or is transformed
to XML in an early step, it is useful to be able to make choices
dependent on this input. The standard selector model in Cocoon does
not allow for this.

Hypothetical usage example

<map:match pattern="userDataInsert.xml">
  <map:generate type="stream"/>
  <map:transform src="userData.xsd" type="validator"/>
  <map:select type="xpath">
    <map:when test="/*/@fatal-error">
      <map:transform src="structureErrors.xsl"/>
    <map:when test="/*/@field-error">
      <map:transform src="userDataForm.xsl"/>
      <map:transform type="file-writer" dest="userData.xml"/>
      <map:select type="xpath">
        <map:when test="/result/file-writen='true'">
          <map:transform src="reportInsertResult.xsl"/>
          <map:transform src="reportInsertError.xsl"/>

In this example the yet to be implemented "validator transformer"
annotates invalid input elements with error describing
attributes. These annotated input is feed back to "userDataForm.xsl",
that create a partially filled in form with appropriate error messages.


Pipe aware selection is only implemented for the TreeProcessor.  To
make a selector pipe aware it must implement the marker interface
PipeAware. In SelectNode (that performs selection in the
TreeProcessor) non-pipe aware selectors are handled exactly as
before. For PipeAware selectors the following happen:

* The current EventPipeline is processed and the result is put as a
DOM-tree in an objectModel parameter: "pipeline-result".
* A new EventPipeline is created with a special DOMGenerator as
generator. The DOMGenerator streams the DOM-tree in the objectModel.
* The SelectNode proceeds as for ordinary selection, but the PipeAware
Selector, can e.g. apply XPaths on the DOM-tree in the objectModel.


Caching is yet to be implemented. The EventPipeline before the
selector will be cashed according to the ordinary scheme. The
pipeline that starts with the DOMGenerator would be cashable if the
DOMGenerator was cashable, which could be achieved by calculating a
CacheKey from the DOM-tree. This scheme seem however unnecessarily
inefficient as the selection has to be recalculated even if it is in
principle determined from the previous pipeline.
I need some more thinking about this, I would appreciate any input.

Running the example

Apply the patch. Copy the example directory to the mount directory.

The example does not do anything useful at all it just tests the

Implementation details

I tried to minimize the changes to existing classes but I had add a
method to InvokeContext and of course some code to SelectNode in
the treeprocessor.


SelectNode: added some functionality to handle PipeAware selectors.

InvokeContext: added the method resetPipelines()

PipeAware: marker interface.

DOMGenerator: streams the DOM-tree in the objectModel.

XPathSelector: an xpath is applied on the DOM-tree in the
objectModel. (BTW, I could not find any documentation about how
namespaces are handled in the XPathProcessor, any pointers?).


There are a lot of references to the variable "pipeline-result" in the
objectModel, this variable should be accessed through the
ObjectModelHelper. (I didn't want to change existing code if I could
avoid it).

In PipeSelectNode, DOMGenerator is supposed to be declared in the
sitemap under the name "dom-generator", this is a ugly hack, but the
only solution that I found that didn't required additions to the
EventPipeline interface.


Meaningful examples

View raw message