You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/05/07 05:15:38 UTC
Re: XSL transform tags refactoring
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
Re: XSL transform tags refactoring
Posted by Morgan Delagrange <mo...@apache.org>.
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?
> [..]
>
Re: XSL transform tags refactoring
Posted by Jeff Turner <je...@socialchange.net.au>.
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?
[..]
Re: XSL transform tags refactoring
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Morgan Delagrange" <mo...@apache.org>
> 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.
I actually just went through these kind of issues with the XTags library.
The <xtags:parse> tag can parse its body, a URL or a URI to a resource or
the result of calling some dynamic page or external web service.
If it helps any, here's the decision I came to:-
* parsing the body
<xtags:parse>
<root>
<child/>
</root>
</xtags:parse>
* parsing an absolute URL via the "url" attribute
<xtags:parse url="http://something.com"/>
* parsing a web app resource using an absolute URI relative to the web-app
context using the "uri" attribute
<xtags:parse uri="/data/foo.xml"/>
* parsing a web resource using a URI relative to the the current JSP
<xtags:parse uri="foo.xml"/>
So thats the basics covered in 2 attributes. Then for more complex
requirements such as parsing the output of a piece of JSP, when we get to
JSP 1.2, we'll be able to do...
<xtags:parse>
<jsp:include page="foo.jsp"/>
</xtags:parse>
until then I use the IO tag library to make these requests such as...
(though they are in a seperate http request so all session, request & page
scope state is lost)
<xtags:parse>
<io:request url="/foo.jsp"/>
</xtags:parse>
if it must be in the same request, its a hack but this usually works (if
scripting variables don't clash)
<xtags:parse>
<%@ include file="/foo.jsp" %>
</xtags:parse>
or to parse the output of an XML-RPC call...
<xtags:parse>
<io:xmlrpc url="/xmlrpc_echo.jsp">
<io:pipe>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>41</i4></value>
</param>
</params>
</methodCall>
</io:pipe>
</io:xmlrpc>
</xtags:parse>
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: XSL transform tags refactoring
Posted by Morgan Delagrange <mo...@apache.org>.
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
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: XSL transform tags refactoring
Posted by Morgan Delagrange <mo...@apache.org>.
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
> > > >
> > >
> > >
> >
> >
>
>
Re: XSL transform tags refactoring
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
> > >
> >
> >
>
>
Re: XSL transform tags refactoring
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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.
> - Morgan
>
>
> 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
> >
>
>
Re: XSL transform tags refactoring
Posted by Morgan Delagrange <mo...@apache.org>.
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?
- Morgan
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
>