jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <ja...@metastuff.com>
Subject Re: [OT]: Compile time tags. (XSLT preprocessing of JSP)
Date Thu, 22 Mar 2001 16:50:04 GMT
> > I'm happy to experiment :)
> As long as you don't stop playing with your other ideas, I'm happy too!
> :-). In particular, have you looked into adding SAX streams to your
> pipes?  That seems a natural extension...

I'm always try to play with all my ideas ;-)

Yes I've considered "tag pipelining" of XML quite seriously. I've a cool new
open source tag library to do just that, and much more besides but more on
that later when its better documented and available on the net...

Don't worry, you'll hear it first here... :-)

> > For example right now in JSP 1.2 the TagLibraryValidator returns a
String if
> > there is an error while validating the whole page. Returning an XML
> > would be a better idea, as multiple errors could be returned easily.
> >
> > <jsp:errors>
> >     <jsp:error line="20" column="5" tag="foo:bar">
> >         Missing attribute "d"
> >     </jsp:error>
> >     <jsp:error line="40" column="2" tag="foo:foo">
> >         This tag should be nested inside a <foo:c> tag
> >     </jsp:error>
> > </jsp:errors>
> That is an interesting idea.  Debugging info is one area that we have
> not been spending much time on, and which can use it!
> > ... different pipeline ideas...
> If you do things like reordering the input substantially (like moving
> things form beginning to end) pipelines don't really work as such...

I only really expect to adorn tags 'in place' in the preprocessing stage -
not move whole sections around from beginning to end - more like doing
transformation in place like XSLT does. For example

<logic:if test="booleanExpression">
    tag body

could be transformed to

    if ( booleanExpression ) {
    tag body

which gets compiled by the JSP compiler into a real Java "if" statement.

I'll leave it as an excercise to the reader to figure out how many Object
instantiations and Java method calls get saved, per request, by doing the
above with a "compile time tag" rather than a JSP custom tag.

This example highlights another reason why I like the idea of "compile time"
tags as an addition to the JSP tag developers tool box. Hiding complexity
behind XML tags in JSP is a Good Thing. However sometimes JSP custom tags
can feel a bit too heavyweight (or a bit too much effort to build) when a
simple preprocess step and a couple of lines of XSLT would be quicker to
implement and more efficient at request time.

When looking around at existing tag libraries and writing them myself I've
often had the feeling we're trying to rewrite the Java langauge in JSP tags.
Doing boolean expression branching and getting / setting bean properties of
objects (which you know the type of at compile time) seems to be that kind
of thing.

A different take this could be, when you're building web apps, if its simple
and easy to build some XSLT 'tags' to get things working and keep a clean
seperation of scripting & java code from your XML JSP 'view'  then go for
it. If your tags are or become too complex they can be refactored into JSP
custom tags and shared acrosss web apps. Kinda like extreme programming for
JSP developers ;-)

I've looked back at some of my JSP tag libraries I've done in the past and
thought they'd actually be easier to do in XSLT at compile time.

> Effective debugging in the presence of source transformations is a hard
> issue.  The problem has been explored for a long time in language
> design, and, IHMO, has not been solved sucesfully.


I'm expecting validation to occur on the input XML JSP only, before any
transformation has occurred - not on the output of the transformation.

If validation and preprocessing were all done via SAX preprocessing we'd
probably want to chain all the validators together first, so they are all
validating the input, before any transformers get a look in.

Maybe if we get complex one day, we could add validators to the end of the
chain to validate the output of the preprocessing too, though figuring out
the offending line could be very tricky...


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.

View raw message