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 James Strachan <ja...@metastuff.com> on 2001/03/21 19:32:00 UTC
[OT]: Compile time tags. (XSLT preprocessing of JSP)
Here's an off topic idea I've been pondering about lately...
I like JSP and custom tags, that we can astract away complex presentation or
business logic away behind XML tags. I like the fast development cycle of
JSP as well - edit a JSP, press reload in your browser and voila!
I've noticed that alternatives to JSP use XSLT to implement "tags". For
example Cocoon's XSP and Resin's XTP
http://xml.apache.org/cocoon/xsp.html
http://www.caucho.com/articles/xtp_templates.xtp
It got me wondering, how about adding XSLT based "compile time" tags to our
toolset when using standard JSP?
What's required? Well just that we use the XML format for JSPs and that we
apply an XSLT document to our JSPs before our servlet engine tries to run
them. This XSLT can then preprocess certain XML tags to do simple formatting
or adding dynamic code. The tags could be put into namespaces just like
regular JSP custom tags. More on what we can do with compile time tags
later...
----
Implementation:
If the servlet engine doesn't support the XML format fully (which I've found
to be true in many engines I try) then we could always use this XSLT
preprocessing stage to turn the XML format of JSP into the standard style
<%= %> format.
Right now today we can implement XSLT preprocessing using an Ant build
system to build all JSP files before use our web application.
However this breaks our nice fast "edit JSP & reload browser" development
environment. So it would be cool if we could integrate the XSLT
'preprocessing' stage directly into our JSP compiler.
For example it would be great if we had a configuration hook to, say,
Tomcat/Jasper that for a certain web-app we wish to apply a certain XSLT
stylesheet to preprocess all of the XML format JSP files. If it were
implemented in Jasper, we could then reuse Jasper across other servlet
engines (Jetty, WebLogic et al) to get the same feature in other app
servers. In production, we may choose to use the Ant build process approach
to do the XSLT preprocessing as the JSP probably won't be changing much.
I wonder if anyone on the list has tried this idea?
I've taken a quick peek at the Jasper source code and it looks like it
shouldn't be too hard to add some kind of configurable pre-processor into
it. (Though it would be great if the JSP spec had an entry for XSLT
pre-processing of JSP using the web deployment descriptor ;-).
----
Examples:
Compile time tags can only use compile time attributes, though they could
output JSP scriptlet expressions. For example here's an example of a normal
regular HTML form in a piece of JSP.
<FORM action="something.jsp" method="get">
<P>
First name:
<INPUT type="text" name="firstname" />
<BR />
Last name:
<INPUT type="text" name="lastname" />
<BR />
email:
<INPUT type="text" name="email" />
</P>
<BR />
<INPUT type="submit" value="Send">
<INPUT type="reset">
</FORM>
Using XSLT preprocessing, we could preprocess the above using XSLT to
include scriptlet expressions to fill in the values of the fields based on
the current state of the form:-
<FORM action="something.jsp" method="get">
<P>
First name:
<INPUT
type="text" name="firstname"
value='<%= getFormValue( pageContext, "firstname") %>'/>
<BR />
Last name:
<INPUT
type="text" name="lastname"
value='<%= getFormValue( pageContext, "lastname") %>'/>
<BR />
email:
<INPUT
type="text" name="email"
value='<%= getFormValue( pageContext, "email") %>'/>
</P>
<BR />
<INPUT type="submit" value="Send">
<INPUT type="reset">
</FORM>
Where the function "getFormValue()" can be used to fetch the values of the
fields in the form using any real Java code, maybe a custom form package or
by just pulling the values out of the servlet request parameters.
This means that from the developer / designers perspective the JSP remains
'clean' and HTML like without the scriptlet expressions it - all the clever
stuff happens when we compile this JSP into Java code.
Also note that this means we don't need to write a Jsp custom tag for each
type of <input> tag, having JavaBean properties for all possible attribute
values we wish to use. At run time no tags are created, the only bit of
dynamic Java code on the page will be the calls to getFormValue(). So the
page will be really effiicent.
Note that I'm not advocating a replacement of JSP custom tags here - just
advocating the use of both XSLT preprocessing with JSP custom tags as a
really neat way of building web-apps. Doing XSLT preprocessing in an 'ant
build process' is a bit of a bind for a JSP developer so I'm advocating its
inclusion into the 'JSP compile' step.
Comments?
<James/>
James Strachan
=============
email: james@metastuff.com
web: http://www.metastuff.com
__________________________________________________________________
If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited.
Views expressed are those of the author and do not necessarily
represent those of Citria Limited.
__________________________________________________________________
Re: [OT]: Compile time tags. (XSLT preprocessing of JSP)
Posted by Eduardo Pelegri-Llopart <Ed...@Sun.COM>.
Forgot to point out that additions/changes should be done on
a non-javax package (something like org.apache.jasper.experimental)
so that people using the new facilities know they are depending on
non-portable, experimental code.
- eduard/o
Eduardo Pelegri-Llopart wrote:
> Anyhow, as I said, I am interested in seing experimentation with the
> concept. If somebody wants to try it, I would design it as a
> transformation class that is delivered with a Tag Library (in a way
> similar to that of TagLibraryValidator). I guess I would try adding
> methods to get a DOM or a JDOM out from a PageData, and have the
> transformer class work on it.
>
Re: [OT]: Compile time tags. (XSLT preprocessing of JSP)
Posted by Eduardo Pelegri-Llopart <Ed...@Sun.COM>.
Hi Jeff.
Hopefully I am not sounding as I am looking down on translation-time
transformations. I am actually quite sympathetic to them due to
previous professional experience (you could do a search on "burs
pelegri" if you want). Still, I was trying to state my belief on the
relative merits of each approach for this particular application domain.
Anyhow, as I said, I am interested in seing experimentation with the
concept. If somebody wants to try it, I would design it as a
transformation class that is delivered with a Tag Library (in a way
similar to that of TagLibraryValidator). I guess I would try adding
methods to get a DOM or a JDOM out from a PageData, and have the
transformer class work on it.
On a different direction. You say:
> The neat thing about XML+XSLT approach is that one can (potentially) validate
> the generated XML after each taglib has been applied. Each taglib can have
> an XML Schema (or TReX or whatever) associated with it, and this can, with
> great preciseness, validate that the JSP/XSP is valid at that point.
The TagLibraryValidator that we have added in JSP 1.2 is intended to
help with validation of the generated content. But we do not have much
experience with it yet. The hard part, of course, is that what you want
to validate is not the JSP but the output of the JSP (and ditto for the
XSP), and whenever there is some dynamic content gnerated one needs to
make some assertions about what shape it has. In that, I think that
whenever one drops into raw java code (be it JSP scriptlets or XSP java
fragments) it is very hard to analyse what is happening. I think that
JSP without scriptlets is easier to reason about but, as I said, we have
no real experience. If you have any on the XSP side, I would love to
see how that can be translated into JSPs.
> ESQL XSP taglib benefits...
cool, share them here! :-) :-)
Thanks for the comments, and, btw, I too are quite interested in TReX.
- eduard/o
Jeff Turner wrote:
>
> On Wed, Mar 21, 2001 at 03:25:22PM -0800, Eduardo Pelegri-Llopart wrote:
> > Here we go... :-)
> >
> > Yes, this is the "translation-time transformation" feature for JSP that
> > we have kept in the set of potential features since 0.9x. We almost
> > added them to JSP 1.2, if you look carefully, most of the machinery is
> > already there; there is a PageData class that provides a (read-only)
> > view of a page at translation time, and this view is made available to a
> > TagLibraryValidator class...
> >
> > We did not include the feature in 1.2 because:
> >
> > - We need to first understand well how to provide reasonable debug
> > information with what we have. Things get quite more complicated when
> > you add transformations (a tag library can break another...)
>
> The neat thing about XML+XSLT approach is that one can (potentially) validate
> the generated XML after each taglib has been applied. Each taglib can have
> an XML Schema (or TReX or whatever) associated with it, and this can, with
> great preciseness, validate that the JSP/XSP is valid at that point.
>
> > - We were not sure how to best expose a page for transformation. For
> > validation using an InputStream seems OK (not great, but OK). But for
> > transformation we would need to decide between DOM, JDOM, whatever.
> >
> > - It is a different programming model and it was not clear there was a
> > big benefit for it. Most of the benefit of an efficient implementation
> > comes from a few tags (things like <if>, <repeat>, <i18n>) and once
> > there is a standard tag library, the container can do that anyhow.
> >
> > Regarding using XSLT specifically as a way of defining semantics, my
> > understanding of the cocoon experience is that this is mixed. XSLT is
> > not the simplest language in the world, in any case it *is* a different
> > language to Java, so you need to learn two languages, and, IMHO, in many
> > (but not all!) cases it is easier to write code that *does something*
> > rather than write code that generates code that *does something*.
>
> Just to make the distinction clear: only taglib authors would have to deal with
> XSLT. Your regular taglib user doesn't care; they just use a new set of tags.
>
> >From the taglib developer's point of view, one has to either:
>
> - Reading the JSP spec, learning the subtleties of the API, write Java code
> - Learn XSLT, learn to "think declaratively", write Java code embedded in XML
>
> I have done both, and neither is trivial. I found learning XSLT to be easier
> (it's a transferrable skill), and XSLT provides flexibility that a static API
> could never match.
>
> > Experience wiht the number of tag libraries available for JSP when
> > compared with XSP seems to validate this analysis.
>
> Slightly unfair given JSP's "industry standard" status. Still, look at Cocoon's
> ESQL taglib; nothing in the JSP world can touch it :) I maintain the LDAP
> taglib (http://kenny.socialchange.net.au/~jeff/ldaptaglib) that has for months
> provided what jakarta-taglibs' has only recently acquired.
>
> --Jeff
>
> > Yet, the general idea is still around and I would not be surprised if we
> > approach it again for JSP 1.3. In the meantime experimentation would be
> > useful. I know of at least one other implementation that is
> > experimenting on this. The trickier part is how to do that without
> > confusing people about this being part of the JSP standard; doing it on
> > the main Tomcat CVS branch seems too prone to confusions to me.
> >
> > Hope this helps!
> > - eduard/o
> >
> > James Strachan wrote:
> > >
> > > Here's an off topic idea I've been pondering about lately...
> > >
> > > I like JSP and custom tags, that we can astract away complex presentation or
> > > business logic away behind XML tags. I like the fast development cycle of
> > > JSP as well - edit a JSP, press reload in your browser and voila!
> > >
> > > I've noticed that alternatives to JSP use XSLT to implement "tags". For
> > > example Cocoon's XSP and Resin's XTP
> > >
> > > http://xml.apache.org/cocoon/xsp.html
> > > http://www.caucho.com/articles/xtp_templates.xtp
> > >
> > > It got me wondering, how about adding XSLT based "compile time" tags to our
> > > toolset when using standard JSP?
> > >
> > > What's required? Well just that we use the XML format for JSPs and that we
> > > apply an XSLT document to our JSPs before our servlet engine tries to run
> > > them. This XSLT can then preprocess certain XML tags to do simple formatting
> > > or adding dynamic code. The tags could be put into namespaces just like
> > > regular JSP custom tags. More on what we can do with compile time tags
> > > later...
> > >
> > > ----
> > > Implementation:
> > >
> > > If the servlet engine doesn't support the XML format fully (which I've found
> > > to be true in many engines I try) then we could always use this XSLT
> > > preprocessing stage to turn the XML format of JSP into the standard style
> > > <%= %> format.
> > >
> > > Right now today we can implement XSLT preprocessing using an Ant build
> > > system to build all JSP files before use our web application.
> > >
> > > However this breaks our nice fast "edit JSP & reload browser" development
> > > environment. So it would be cool if we could integrate the XSLT
> > > 'preprocessing' stage directly into our JSP compiler.
> > >
> > > For example it would be great if we had a configuration hook to, say,
> > > Tomcat/Jasper that for a certain web-app we wish to apply a certain XSLT
> > > stylesheet to preprocess all of the XML format JSP files. If it were
> > > implemented in Jasper, we could then reuse Jasper across other servlet
> > > engines (Jetty, WebLogic et al) to get the same feature in other app
> > > servers. In production, we may choose to use the Ant build process approach
> > > to do the XSLT preprocessing as the JSP probably won't be changing much.
> > >
> > > I wonder if anyone on the list has tried this idea?
> > >
> > > I've taken a quick peek at the Jasper source code and it looks like it
> > > shouldn't be too hard to add some kind of configurable pre-processor into
> > > it. (Though it would be great if the JSP spec had an entry for XSLT
> > > pre-processing of JSP using the web deployment descriptor ;-).
> > >
> > > ----
> > > Examples:
> > >
> > > Compile time tags can only use compile time attributes, though they could
> > > output JSP scriptlet expressions. For example here's an example of a normal
> > > regular HTML form in a piece of JSP.
> > >
> > > <FORM action="something.jsp" method="get">
> > > <P>
> > > First name:
> > > <INPUT type="text" name="firstname" />
> > > <BR />
> > > Last name:
> > > <INPUT type="text" name="lastname" />
> > > <BR />
> > > email:
> > > <INPUT type="text" name="email" />
> > > </P>
> > > <BR />
> > > <INPUT type="submit" value="Send">
> > > <INPUT type="reset">
> > > </FORM>
> > >
> > > Using XSLT preprocessing, we could preprocess the above using XSLT to
> > > include scriptlet expressions to fill in the values of the fields based on
> > > the current state of the form:-
> > >
> > > <FORM action="something.jsp" method="get">
> > > <P>
> > > First name:
> > > <INPUT
> > > type="text" name="firstname"
> > > value='<%= getFormValue( pageContext, "firstname") %>'/>
> > > <BR />
> > > Last name:
> > > <INPUT
> > > type="text" name="lastname"
> > > value='<%= getFormValue( pageContext, "lastname") %>'/>
> > > <BR />
> > > email:
> > > <INPUT
> > > type="text" name="email"
> > > value='<%= getFormValue( pageContext, "email") %>'/>
> > > </P>
> > > <BR />
> > > <INPUT type="submit" value="Send">
> > > <INPUT type="reset">
> > > </FORM>
> > >
> > > Where the function "getFormValue()" can be used to fetch the values of the
> > > fields in the form using any real Java code, maybe a custom form package or
> > > by just pulling the values out of the servlet request parameters.
> > >
> > > This means that from the developer / designers perspective the JSP remains
> > > 'clean' and HTML like without the scriptlet expressions it - all the clever
> > > stuff happens when we compile this JSP into Java code.
> > >
> > > Also note that this means we don't need to write a Jsp custom tag for each
> > > type of <input> tag, having JavaBean properties for all possible attribute
> > > values we wish to use. At run time no tags are created, the only bit of
> > > dynamic Java code on the page will be the calls to getFormValue(). So the
> > > page will be really effiicent.
> > >
> > > Note that I'm not advocating a replacement of JSP custom tags here - just
> > > advocating the use of both XSLT preprocessing with JSP custom tags as a
> > > really neat way of building web-apps. Doing XSLT preprocessing in an 'ant
> > > build process' is a bit of a bind for a JSP developer so I'm advocating its
> > > inclusion into the 'JSP compile' step.
> > >
> > > Comments?
> > >
> > > <James/>
> > >
> > > James Strachan
> > > =============
> > > email: james@metastuff.com
> > > web: http://www.metastuff.com
> > >
> > > __________________________________________________________________
> > >
> > > If you are not the addressee of this confidential e-mail and any
> > > attachments, please delete it and inform the sender; unauthorised
> > > redistribution or publication is prohibited.
> > > Views expressed are those of the author and do not necessarily
> > > represent those of Citria Limited.
> > > __________________________________________________________________
Re: [OT]: Compile time tags. (XSLT preprocessing of JSP)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Mar 21, 2001 at 03:25:22PM -0800, Eduardo Pelegri-Llopart wrote:
> Here we go... :-)
>
> Yes, this is the "translation-time transformation" feature for JSP that
> we have kept in the set of potential features since 0.9x. We almost
> added them to JSP 1.2, if you look carefully, most of the machinery is
> already there; there is a PageData class that provides a (read-only)
> view of a page at translation time, and this view is made available to a
> TagLibraryValidator class...
>
> We did not include the feature in 1.2 because:
>
> - We need to first understand well how to provide reasonable debug
> information with what we have. Things get quite more complicated when
> you add transformations (a tag library can break another...)
The neat thing about XML+XSLT approach is that one can (potentially) validate
the generated XML after each taglib has been applied. Each taglib can have
an XML Schema (or TReX or whatever) associated with it, and this can, with
great preciseness, validate that the JSP/XSP is valid at that point.
> - We were not sure how to best expose a page for transformation. For
> validation using an InputStream seems OK (not great, but OK). But for
> transformation we would need to decide between DOM, JDOM, whatever.
>
> - It is a different programming model and it was not clear there was a
> big benefit for it. Most of the benefit of an efficient implementation
> comes from a few tags (things like <if>, <repeat>, <i18n>) and once
> there is a standard tag library, the container can do that anyhow.
>
> Regarding using XSLT specifically as a way of defining semantics, my
> understanding of the cocoon experience is that this is mixed. XSLT is
> not the simplest language in the world, in any case it *is* a different
> language to Java, so you need to learn two languages, and, IMHO, in many
> (but not all!) cases it is easier to write code that *does something*
> rather than write code that generates code that *does something*.
Just to make the distinction clear: only taglib authors would have to deal with
XSLT. Your regular taglib user doesn't care; they just use a new set of tags.
>From the taglib developer's point of view, one has to either:
- Reading the JSP spec, learning the subtleties of the API, write Java code
- Learn XSLT, learn to "think declaratively", write Java code embedded in XML
I have done both, and neither is trivial. I found learning XSLT to be easier
(it's a transferrable skill), and XSLT provides flexibility that a static API
could never match.
> Experience wiht the number of tag libraries available for JSP when
> compared with XSP seems to validate this analysis.
Slightly unfair given JSP's "industry standard" status. Still, look at Cocoon's
ESQL taglib; nothing in the JSP world can touch it :) I maintain the LDAP
taglib (http://kenny.socialchange.net.au/~jeff/ldaptaglib) that has for months
provided what jakarta-taglibs' has only recently acquired.
--Jeff
> Yet, the general idea is still around and I would not be surprised if we
> approach it again for JSP 1.3. In the meantime experimentation would be
> useful. I know of at least one other implementation that is
> experimenting on this. The trickier part is how to do that without
> confusing people about this being part of the JSP standard; doing it on
> the main Tomcat CVS branch seems too prone to confusions to me.
>
> Hope this helps!
> - eduard/o
>
> James Strachan wrote:
> >
> > Here's an off topic idea I've been pondering about lately...
> >
> > I like JSP and custom tags, that we can astract away complex presentation or
> > business logic away behind XML tags. I like the fast development cycle of
> > JSP as well - edit a JSP, press reload in your browser and voila!
> >
> > I've noticed that alternatives to JSP use XSLT to implement "tags". For
> > example Cocoon's XSP and Resin's XTP
> >
> > http://xml.apache.org/cocoon/xsp.html
> > http://www.caucho.com/articles/xtp_templates.xtp
> >
> > It got me wondering, how about adding XSLT based "compile time" tags to our
> > toolset when using standard JSP?
> >
> > What's required? Well just that we use the XML format for JSPs and that we
> > apply an XSLT document to our JSPs before our servlet engine tries to run
> > them. This XSLT can then preprocess certain XML tags to do simple formatting
> > or adding dynamic code. The tags could be put into namespaces just like
> > regular JSP custom tags. More on what we can do with compile time tags
> > later...
> >
> > ----
> > Implementation:
> >
> > If the servlet engine doesn't support the XML format fully (which I've found
> > to be true in many engines I try) then we could always use this XSLT
> > preprocessing stage to turn the XML format of JSP into the standard style
> > <%= %> format.
> >
> > Right now today we can implement XSLT preprocessing using an Ant build
> > system to build all JSP files before use our web application.
> >
> > However this breaks our nice fast "edit JSP & reload browser" development
> > environment. So it would be cool if we could integrate the XSLT
> > 'preprocessing' stage directly into our JSP compiler.
> >
> > For example it would be great if we had a configuration hook to, say,
> > Tomcat/Jasper that for a certain web-app we wish to apply a certain XSLT
> > stylesheet to preprocess all of the XML format JSP files. If it were
> > implemented in Jasper, we could then reuse Jasper across other servlet
> > engines (Jetty, WebLogic et al) to get the same feature in other app
> > servers. In production, we may choose to use the Ant build process approach
> > to do the XSLT preprocessing as the JSP probably won't be changing much.
> >
> > I wonder if anyone on the list has tried this idea?
> >
> > I've taken a quick peek at the Jasper source code and it looks like it
> > shouldn't be too hard to add some kind of configurable pre-processor into
> > it. (Though it would be great if the JSP spec had an entry for XSLT
> > pre-processing of JSP using the web deployment descriptor ;-).
> >
> > ----
> > Examples:
> >
> > Compile time tags can only use compile time attributes, though they could
> > output JSP scriptlet expressions. For example here's an example of a normal
> > regular HTML form in a piece of JSP.
> >
> > <FORM action="something.jsp" method="get">
> > <P>
> > First name:
> > <INPUT type="text" name="firstname" />
> > <BR />
> > Last name:
> > <INPUT type="text" name="lastname" />
> > <BR />
> > email:
> > <INPUT type="text" name="email" />
> > </P>
> > <BR />
> > <INPUT type="submit" value="Send">
> > <INPUT type="reset">
> > </FORM>
> >
> > Using XSLT preprocessing, we could preprocess the above using XSLT to
> > include scriptlet expressions to fill in the values of the fields based on
> > the current state of the form:-
> >
> > <FORM action="something.jsp" method="get">
> > <P>
> > First name:
> > <INPUT
> > type="text" name="firstname"
> > value='<%= getFormValue( pageContext, "firstname") %>'/>
> > <BR />
> > Last name:
> > <INPUT
> > type="text" name="lastname"
> > value='<%= getFormValue( pageContext, "lastname") %>'/>
> > <BR />
> > email:
> > <INPUT
> > type="text" name="email"
> > value='<%= getFormValue( pageContext, "email") %>'/>
> > </P>
> > <BR />
> > <INPUT type="submit" value="Send">
> > <INPUT type="reset">
> > </FORM>
> >
> > Where the function "getFormValue()" can be used to fetch the values of the
> > fields in the form using any real Java code, maybe a custom form package or
> > by just pulling the values out of the servlet request parameters.
> >
> > This means that from the developer / designers perspective the JSP remains
> > 'clean' and HTML like without the scriptlet expressions it - all the clever
> > stuff happens when we compile this JSP into Java code.
> >
> > Also note that this means we don't need to write a Jsp custom tag for each
> > type of <input> tag, having JavaBean properties for all possible attribute
> > values we wish to use. At run time no tags are created, the only bit of
> > dynamic Java code on the page will be the calls to getFormValue(). So the
> > page will be really effiicent.
> >
> > Note that I'm not advocating a replacement of JSP custom tags here - just
> > advocating the use of both XSLT preprocessing with JSP custom tags as a
> > really neat way of building web-apps. Doing XSLT preprocessing in an 'ant
> > build process' is a bit of a bind for a JSP developer so I'm advocating its
> > inclusion into the 'JSP compile' step.
> >
> > Comments?
> >
> > <James/>
> >
> > James Strachan
> > =============
> > email: james@metastuff.com
> > web: http://www.metastuff.com
> >
> > __________________________________________________________________
> >
> > If you are not the addressee of this confidential e-mail and any
> > attachments, please delete it and inform the sender; unauthorised
> > redistribution or publication is prohibited.
> > Views expressed are those of the author and do not necessarily
> > represent those of Citria Limited.
> > __________________________________________________________________
Re: [OT]: Compile time tags. (XSLT preprocessing of JSP)
Posted by Eduardo Pelegri-Llopart <Ed...@Sun.COM>.
Here we go... :-)
Yes, this is the "translation-time transformation" feature for JSP that
we have kept in the set of potential features since 0.9x. We almost
added them to JSP 1.2, if you look carefully, most of the machinery is
already there; there is a PageData class that provides a (read-only)
view of a page at translation time, and this view is made available to a
TagLibraryValidator class...
We did not include the feature in 1.2 because:
- We need to first understand well how to provide reasonable debug
information with what we have. Things get quite more complicated when
you add transformations (a tag library can break another...)
- We were not sure how to best expose a page for transformation. For
validation using an InputStream seems OK (not great, but OK). But for
transformation we would need to decide between DOM, JDOM, whatever.
- It is a different programming model and it was not clear there was a
big benefit for it. Most of the benefit of an efficient implementation
comes from a few tags (things like <if>, <repeat>, <i18n>) and once
there is a standard tag library, the container can do that anyhow.
Regarding using XSLT specifically as a way of defining semantics, my
understanding of the cocoon experience is that this is mixed. XSLT is
not the simplest language in the world, in any case it *is* a different
language to Java, so you need to learn two languages, and, IMHO, in many
(but not all!) cases it is easier to write code that *does something*
rather than write code that generates code that *does something*.
Experience wiht the number of tag libraries available for JSP when
compared with XSP seems to validate this analysis.
Yet, the general idea is still around and I would not be surprised if we
approach it again for JSP 1.3. In the meantime experimentation would be
useful. I know of at least one other implementation that is
experimenting on this. The trickier part is how to do that without
confusing people about this being part of the JSP standard; doing it on
the main Tomcat CVS branch seems too prone to confusions to me.
Hope this helps!
- eduard/o
James Strachan wrote:
>
> Here's an off topic idea I've been pondering about lately...
>
> I like JSP and custom tags, that we can astract away complex presentation or
> business logic away behind XML tags. I like the fast development cycle of
> JSP as well - edit a JSP, press reload in your browser and voila!
>
> I've noticed that alternatives to JSP use XSLT to implement "tags". For
> example Cocoon's XSP and Resin's XTP
>
> http://xml.apache.org/cocoon/xsp.html
> http://www.caucho.com/articles/xtp_templates.xtp
>
> It got me wondering, how about adding XSLT based "compile time" tags to our
> toolset when using standard JSP?
>
> What's required? Well just that we use the XML format for JSPs and that we
> apply an XSLT document to our JSPs before our servlet engine tries to run
> them. This XSLT can then preprocess certain XML tags to do simple formatting
> or adding dynamic code. The tags could be put into namespaces just like
> regular JSP custom tags. More on what we can do with compile time tags
> later...
>
> ----
> Implementation:
>
> If the servlet engine doesn't support the XML format fully (which I've found
> to be true in many engines I try) then we could always use this XSLT
> preprocessing stage to turn the XML format of JSP into the standard style
> <%= %> format.
>
> Right now today we can implement XSLT preprocessing using an Ant build
> system to build all JSP files before use our web application.
>
> However this breaks our nice fast "edit JSP & reload browser" development
> environment. So it would be cool if we could integrate the XSLT
> 'preprocessing' stage directly into our JSP compiler.
>
> For example it would be great if we had a configuration hook to, say,
> Tomcat/Jasper that for a certain web-app we wish to apply a certain XSLT
> stylesheet to preprocess all of the XML format JSP files. If it were
> implemented in Jasper, we could then reuse Jasper across other servlet
> engines (Jetty, WebLogic et al) to get the same feature in other app
> servers. In production, we may choose to use the Ant build process approach
> to do the XSLT preprocessing as the JSP probably won't be changing much.
>
> I wonder if anyone on the list has tried this idea?
>
> I've taken a quick peek at the Jasper source code and it looks like it
> shouldn't be too hard to add some kind of configurable pre-processor into
> it. (Though it would be great if the JSP spec had an entry for XSLT
> pre-processing of JSP using the web deployment descriptor ;-).
>
> ----
> Examples:
>
> Compile time tags can only use compile time attributes, though they could
> output JSP scriptlet expressions. For example here's an example of a normal
> regular HTML form in a piece of JSP.
>
> <FORM action="something.jsp" method="get">
> <P>
> First name:
> <INPUT type="text" name="firstname" />
> <BR />
> Last name:
> <INPUT type="text" name="lastname" />
> <BR />
> email:
> <INPUT type="text" name="email" />
> </P>
> <BR />
> <INPUT type="submit" value="Send">
> <INPUT type="reset">
> </FORM>
>
> Using XSLT preprocessing, we could preprocess the above using XSLT to
> include scriptlet expressions to fill in the values of the fields based on
> the current state of the form:-
>
> <FORM action="something.jsp" method="get">
> <P>
> First name:
> <INPUT
> type="text" name="firstname"
> value='<%= getFormValue( pageContext, "firstname") %>'/>
> <BR />
> Last name:
> <INPUT
> type="text" name="lastname"
> value='<%= getFormValue( pageContext, "lastname") %>'/>
> <BR />
> email:
> <INPUT
> type="text" name="email"
> value='<%= getFormValue( pageContext, "email") %>'/>
> </P>
> <BR />
> <INPUT type="submit" value="Send">
> <INPUT type="reset">
> </FORM>
>
> Where the function "getFormValue()" can be used to fetch the values of the
> fields in the form using any real Java code, maybe a custom form package or
> by just pulling the values out of the servlet request parameters.
>
> This means that from the developer / designers perspective the JSP remains
> 'clean' and HTML like without the scriptlet expressions it - all the clever
> stuff happens when we compile this JSP into Java code.
>
> Also note that this means we don't need to write a Jsp custom tag for each
> type of <input> tag, having JavaBean properties for all possible attribute
> values we wish to use. At run time no tags are created, the only bit of
> dynamic Java code on the page will be the calls to getFormValue(). So the
> page will be really effiicent.
>
> Note that I'm not advocating a replacement of JSP custom tags here - just
> advocating the use of both XSLT preprocessing with JSP custom tags as a
> really neat way of building web-apps. Doing XSLT preprocessing in an 'ant
> build process' is a bit of a bind for a JSP developer so I'm advocating its
> inclusion into the 'JSP compile' step.
>
> Comments?
>
> <James/>
>
> James Strachan
> =============
> email: james@metastuff.com
> web: http://www.metastuff.com
>
> __________________________________________________________________
>
> If you are not the addressee of this confidential e-mail and any
> attachments, please delete it and inform the sender; unauthorised
> redistribution or publication is prohibited.
> Views expressed are those of the author and do not necessarily
> represent those of Citria Limited.
> __________________________________________________________________