forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Dispacther and XPath
Date Sat, 25 Aug 2007 10:14:01 GMT
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. [@id = '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//div[@id='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/div[@id='footer']
or /html/body/div/span/div[@id='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


Mime
View raw message