On Fri, 2007-08-24 at 13:33 +0200, Sina K. Heshmati wrote: > In an attempt to dive into the Dispatcher, I have started to write some > contracts for the Baetle plugin. While working, Once an issue raised, I try > to get over it by studying the source code but if things get complicated, > then I'd rather ask the list. > > Here's an issue: Does Dispatcher really support XPath?
Yes, but a limited form. We are using http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/xml/dom/DOMUtil.html#getSingleNode(org.w3c.dom.Node,%20java.lang.String,%20org.apache.excalibur.xml.xpath.XPathProcessor) " /** * Return the <CODE>Node</CODE> from the DOM Node <CODE>rootNode</CODE> * using the XPath expression <CODE>path</CODE>. If the node does not * exist, it is created and then returned. This is a very simple method for * creating new nodes. If the XPath contains selectors ([,,,]) or "*" it is * of course not possible to create the new node. So if you use such XPaths * the node must exist beforehand. An simple exception is if the expression * contains attribute test to values (e.g. [EMAIL PROTECTED] = 'du' and * * @number = 'you'], the attributes with the given values are added. The * attributes must be separated with 'and'. Another problem are * namespaces: XPath requires sometimes selectors for namespaces, * e.g. : /*[namespace-uri()="uri" and local-name()="name"] Creating * such a node with a namespace is not possible right now as we use * a very simple XPath parser which is not able to parse all kinds * of selectors correctly. * * @param rootNode * The node to start the search. * @param path * XPath expression for searching the node. * @param processor * The XPath processor to use * @return The node specified by the path. * @throws ProcessingException * If no path is specified or the XPath engine fails. */" > > Let's say that I'd like my contract to decide where in the final document to > add the content it generates. For instance, > > <forrest:template ...> > <xsl:stylesheet ...> > <xsl:template match="/"> > <forrest:content> > <forrest:part xpath="/html/body//[EMAIL PROTECTED]'footer']"> > ... > > would append the generated content to the node selected by @xpath. Well the problem is // which means any sequence of, so e.g. /html/body/p/[EMAIL PROTECTED]'footer'] or /html/body/div/span/[EMAIL PROTECTED]'footer'] That will not work and I guess it is not what you want anyway. > > None of the current contracts that I know of, goes further than simple XPath > expressions (e.g. '/html/body'). See above JavaDocs for the xpaths which you can use. > > Do you think it's a bug that contracts with more complex XPath expressions > fail, or is it meant not to work like that at all? Can you point out the complex XPATH expression that you want to use? > > The only thing I didn't examine is the XPath processor used in the > org.apache.forrest.dispatcher.transformation.DispatcherTransformer class. > 'contractProcessingEnd()' is the method responsible for generating the final > content. We are using the DOMUtils from cocoon for that. salu2 > > Sina K. Heshmati > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
