jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: XSL transform tags refactoring
Date Tue, 15 May 2001 08:03:34 GMT
On Wed, May 09, 2001 at 01:36:12PM -0700, Morgan Delagrange wrote:
> Hi all,
> 
> I didn't mean to issue a proclamation here.  :)  Are there dissenting
> views to handling relative paths via getResource(), or is this silent
> consent?  I'll probably go ahead and implement getResource() if there are
> no immediate objections, but we can easily change it before the release.

Hi,

I was feeling keen, so went ahead and implemented the "ambidextrous" suggestion
of Craig's:

Craig McClanahan:
> However, using this also restricts you to resources in the same web app,
> whereas building an http URL is more general purpose.  It wouldn't be hard
> to make the tag ambidextrous -- for example, if the specified path starts
> with a slash, assume that it's a context-relative resource, but otherwise
> treat it as a URL.

In addition, page-relative paths are handled by first converting to
context-relative, and then using getResource(). Hope this is the right
approach.


Oh, and I also changed the code so the "name" attribute can point to an
org.w3c.dom.Node (it can currently point to String, Reader, InputStream or
StringReader).

Patch, and two rough example pages attached.

thanks,

--Jeff


> - Morgan

[..]
> > > > On Mon, 7 May 2001, Morgan Delagrange wrote:
> > > > 
> > > > > Reviewing this patch brings up an interesting design question.  This
patch
> > > > > builds an http url, but maybe that's not the way to go.  Using this
> > > > > method:
> > > > > 
> > > > >   String xsl = application.getResource("style.xsl").toString();
> > > > > 
> > > > > we can create a file url, which is going to be significantly more
> > > > > performant.  Which is preferable?
[..]

Mime
View raw message