Very interesting. It's like a dream come true for me and probably Jeremy. I'll be spending some time to review the code in the next day or so. It'll be interesting to hear what Stefano has to say about this. He hasn't been a big fan of "data" aware selectors.
Does the implementation only cover the efficient subset of XPath which does not require DOM representation and can be evaluated only by monitoring SAX events? Do you remember the 4 or so typical examples which Konstantin and I mentioned, that can be implemented efficintly? Regards, Ivelin ----- Original Message ----- From: "Daniel Fagerstrom" <[EMAIL PROTECTED]> To: "Cocoon-Dev@Xml. Apache. Org" <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 5:35 PM Subject: [Contribution] Pipe-aware selection > 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. > > Motivation > ---------- > > See > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101494021330277&w=2 > and the rest of the discussions in the threads: > XML-Based Selection (Redirect Serializer?) > http://marc.theaimsgroup.com/?t=101480865500001&r=1&w=2 > and Pipe-aware Selectors > http://marc.theaimsgroup.com/?t=101536052100002&r=1&w=2 > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101554683923592&w=2 > 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> > <map:when test="/*/@field-error"> > <map:transform src="userDataForm.xsl"/> > </map:when> > <map:otherwise> > <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:when> > <map:otherwise> > <map:transform src="reportInsertError.xsl"/> > </map:otherwise> > </map:select> > </map:otherwise> > </map:select> > <map:serialize/> > </map:match> > > 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. > > Design > ------ > > 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 > ------- > > 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. > Test: > http://localhost:8080/cocoon/mount/pipeSelector/test.html?myparam=a > and > http://localhost:8080/cocoon/mount/pipeSelector/test.html > > The example does not do anything useful at all it just tests the > functionality. > > 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. > > Classes: > > 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?). > > Todo > ---- > > 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. > > Cachability!!! > > Meaningful examples > ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
