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.


> > - 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
> > > 
> > 
> > 
> 
> 

Reply via email to