Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: XPathDirectoryGenerator
Date: Thu, 29 May 2003 12:45:58 +1200
Message-ID: <0DCA8D5F170C6645898F80562B35F53702CBDDB1@PICO.staff.vuw.ac.nz>
Thread-Topic: XPathDirectoryGenerator
Thread-Index: AcMlbuxru63yVin0RvuTSQbmZgX76gAC257Q
From: "Conal Tuohy" <Conal.Tuohy@vuw.ac.nz>
To: <cocoon-dev@xml.apache.org>

> Torsten Knodt wrote:
> > Hello,
> > I'm currently working on my patchset of the week ;). One=20
> part is a modularized=20
> > DirectoryGenerator. The only what is currently not included is the=20
> > XPathDirectoryGenerator. As it can simply be simulated by=20
> XInclude, why=20
> > having the code doubled? Or have I understood something=20
> wrong with this=20
> > thing?

> From: Gianugo Rabellino [mailto:gianugo@apache.org]

> I don't see how you might simulate the behaviour with=20
> Xinclude. The idea=20
> of the XPathDirectoryGenerator is returning a list of all the XML=20
> resources living in a given directory matching a given XPath=20
> (mimicking=20
> on a filesystem what an XPath query would do on a XML database). How=20
> would you do that with Xinclude?

My understanding of XPathDirectoryGenerator is that it generates a =
directory listing containing the xpath-matching fragments of each file.

It's true that you could use an ordinary DirectoryGenerator, transform =
the dir:file elements to xi:include elements with =
@href=3D"{@name}#xpointer(blah/blah)", then transform with xinclude =
transformer. So this would effectively mimic XPathDirectoryGenerator. =
But I think a single XPathDirectoryGenerator would be a lot simpler, and =
worth having.

Con