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.
- Morgan
On Tue, 8 May 2001, Morgan Delagrange wrote:
>
>
> On Mon, 7 May 2001, Craig R. McClanahan wrote:
>
> >
> >
> > On Mon, 7 May 2001, Craig R. McClanahan wrote:
> >
> > >
> > >
> > > 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?
> > > >
> > > > File URLs:
> > > >
> > > > Pros:
> > > > Performance
> > > >
> > > > Cons:
> > > > Stylesheets must be flat files
> > > >
> > > > HTTP URLs:
> > > >
> > > > Pros:
> > > > Flexibility
> > > >
> > > > Cons:
> > > > Performance
> > > >
> > > > Or we could just punt and indicate the issues in the docs. Or we could
> > > > provide tags to build both file and http urls (I think this is
> > > > my preference). Opinions?
> > > >
> > >
> > > An additional ad
> > >
> > > I'm not sure your assumptions about performance are necessarily correct in
> > > all circumstances.
> > >
> > > For example, in Tomcat 4.0 the ServletContext.getResource() call returns a
> > > URL that starts "jndi:", because it uses an internal-to-Tomcat stream
> > > handler.
> > >
> >
> > I thought I had postponed this for later editing ... instead I sent
> > it. Drat.
> >
> > The point I was going to make is that the servlet container's URL
> > (returned by ServletContext.getResource()) is likely to be fast, because
> > it will be directly supported by the container (at some point in Tomcat
> > 4.0, for example, we'll add data caching support to the resources
> > implementation).
> >
> > 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.
>
> Hmm, it's a tough call, but it looks like we can work through it. Some
> containers (e.g. Tomcat 3.2, Weblogic) are going to return a file pointer,
> while others (Tomcat 4.0) are returning JNDI pointers, but in almost all
> cases using getResource() is going to be more performant than building an
> http URL. So the main drawbacks to getResouce() are 1) no extra-Webapp
> links (although technically we should be able to do it with
> RequestDispatcher), and 2) no dynamically generated pages. (There's also
> a chance that some XSLT parsers will choke on JNDI urls.)
>
> To me, no dynamically generated pages is almost a bonus. I've seen
> stylesheets erroneously use jsp parameters and jsp includes where they
> could much more effectively utilize xsl:param and xsl:include. I always
> encourage XSL authors to write stylesheets that can be used outside of a
> servlet container.
>
> I would just as soon make it work via getResource() and try that route
> first. We would include notes in the docs that relative paths do not
> support dynamically generated pages and that one should use fully
> specficied http urls in that case.
>
> - Morgan
>
> >
> > > > - Morgan
> > > >
> >
> > Craig
> >
> >
> > > >
> > > > On Mon, 7 May 2001, Jeff Turner wrote:
> > > >
> > > > > Nifty..
> > > > >
> > > > > Attached is a patch that allows the user to specify relative URLs (relative
>to
> > > > > the context root) in the "uri" attribute.
> > > > >
> > > > > --Jeff
> > > > >
> > > > > On Mon, Apr 30, 2001 at 11:21:02AM -0700, Morgan Delagrange wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I checked in a very preliminary version of some new XSL transform tags in
> > > > > > the repository on the "rel2" branch. The build script doesn't really work
> > > > > > yet; you'll need jaxp to compile it.
> > > > > >
> > > > > > It has new syntax compared to the current XSL tag library (see the example
> > > > > > JSP for now, until the docs are ready.) It is based
> > > > > > on TraX, so it should be pluggable with any trax parser. Right now it
> > > > > > does simple transformations based on URIs, Readers, InputStreams, Strings
> > > > > > and/or tag bodies.
> > > > > >
> > > > > > However, since it's based on TraX, it should be possible to also work with
> > > > > > DOMs and possibly SAX events. Also, we can take advantage of other nice
> > > > > > TraX features, like configurable output properties.
> > > > > >
> > > > > > I ripped out some features, like stylesheet caching, in this version to
> > > > > > make the TraX conversion simpler. In a follow-up email, I'm going to
> > > > > > nominate Rod Waldhoff as a committer, since he actually designed this tag
> > > > > > library and I mostly just ported it to TraX.
> > > > > >
> > > > > > - Morgan
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
