On Tue, 15 May 2001, Jeff Turner wrote:
> 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.
That could be the right approach. I am somewhat concerned with using
combinations of getResource() and URL, because getResource() will not
support dynamic pages, while URLs will, but in a limited fashion that
might confuse the user. In any case, I'll definitely take a look.
> 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).
Fantastic. I was planning to do this, so thanks for the assist.
> 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?
> [..]
>
