Return-Path: 
 <dev-return-28308-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 69117 invoked from network); 25 Aug 2007 10:14:39 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 25 Aug 2007 10:14:39 -0000
Received: (qmail 28982 invoked by uid 500); 25 Aug 2007 10:14:35 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 28935 invoked by uid 500); 25 Aug 2007 10:14:35 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
List-Id: <dev.forrest.apache.org>
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 28923 invoked by uid 99); 25 Aug 2007 10:14:35 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Aug 2007 03:14:35 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [81.169.146.190] (HELO mo-p07-ob.rzone.de) (81.169.146.190)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Aug 2007 10:14:27 +0000
Received: from [192.168.1.33]
	(246.Red-88-16-252.dynamicIP.rima-tde.net [88.16.252.246])
	by post.webmailer.de (klopstock mo13) (RZmta 10.3)
	with ESMTP id y0625dj7P8oOnx for <dev@forrest.apache.org>;
	Sat, 25 Aug 2007 12:14:04 +0200 (MEST)
Subject: Re: Dispacther and XPath
From: Thorsten Scherler <thorsten@apache.org>
To: forrest dev <dev@forrest.apache.org>
In-Reply-To: <39245.192.168.1.71.1187955237.webmail@192.168.1.71>
References: <39245.192.168.1.71.1187955237.webmail@192.168.1.71>
Content-Type: text/plain
Date: Sat, 25 Aug 2007 12:14:01 +0200
Message-Id: <1188036842.27122.12.camel@cartman>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Content-Transfer-Encoding: 7bit
X-RZG-AUTH: z4gQVF2k7GZD04sUDABP6ox1Qu0=
X-RZG-CLASS-ID: mo07
X-Virus-Checked: Checked by ClamAV on apache.org

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