Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Robert Koberg" <rob@koberg.com>
To: <cocoon-dev@xml.apache.org>
Subject: RE: XML input module (was: RE: Nice changes!)
Date: Fri, 4 Oct 2002 09:38:06 -0700
Message-ID: <ADECJLDNBFNBOJBLKCMOIEHECNAA.rob@koberg.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <601F6322AD71D5118D6C0003472515290660D002@sjmemexc1.stjude.org>

Hi,

> -----Original Message-----
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@stjude.org]
> Sent: Friday, October 04, 2002 9:34 AM
> To: 'cocoon-dev@xml.apache.org'
> Subject: RE: XML input module (was: RE: Nice changes!)
>
>
> > > Maybe, maybe not. One would need to use a lot extension functions to
> > > achieve similar things (e.g. j2ee, databases and stuff) but that might
> > > be portable to other pipeline systems (?). OTOH Apache Cocoon a lot
> > > about SoC and it will need to be seen if that works as well with your
> > > suggested approach.
> >
> > Instead of extensions you could use custom URIResolvers to return the
> result
> > from anywhere (or just do something and return succes/fail) to an
> representation
> > usable by a transformation.
>
> That would work, but where I'm heading I essentially want the equivalent of
> a uri-resolver to be coded using XSLT looking not only at the URI but also
> the current context.

in XSLT 1.0 you can do:

<xsl:apply-templates
  select="document($util_function, $client_site)"/>

Where you pass the href and base arguments to the resolver. The 2cnd arg being
the context.

best,
-Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org