All right, now I can spill the beans. JSTs were something Tom Reilly, our
main JSP container engineer, conceived, prototyped and proposed to the JSP
spec leads at the end of the JSP 1.2 (I think -- I'm not positive about the
original timing) spec. cycle. We ended up pulling it back because it didn't
look like there'd be time to have it fully considered by the expert group
for JSP 1.2. Months passed and the idea fermented a bit, and Tom twiddled
around with it and got a few people internally interested in it. I don't
know if it would make more sense to develop JSTs as a separate JSR or under
the rubric of the next JSP JSR.
Anyway, it's no secret that Allaire has been porting the whole CFML language
to run on a Java runtime engine (JRun). That's really where the JST idea
came from, though if you look at the implementation (as Mike has), it's
solidly based on JSP and JSP-like syntax. Basically, as Mike alluded in his
original email on this thread, CFML has long allowed you to extend the
language with new tags in two ways:
1. By implementing exposed C++/Java APIs that allow developers to write
their own tags in "real" programming languages.
2. By allowing users to reuse CFML templates as tags themselves.
The second idea is what JSTs are. The main difference being that JSTs are
translated and compiled into standard JSP 1.1 tag handlers dynamically,
whereas CFML is proprietary.
So anyway, when Mike sent this email in December, he hit the nail right on
the head. I couldn't say anything about what we were doing with it (I
didn't reply at all), and it couldn't be released at the time because we
were all in the middle of dealing with the J2EE CTS (compatibility test
suite) so we could announce certification with the next release. JSTs (as
they are now) were pretty close to being done in October, but the priority
became J2EE certification over new features. Toward the end of 3.1 dev
cycle, we decided to drop them in.
While I'm on the topic of 3.1, Tom fixed a couple bugs related to JSPs and
added a couple features.
1. Using "true" instead of "yes" in TLDs used to cause JRun's TLD parser to
throw an Exception. That's fixed.
2. JRun used to treat all custom tag attribute values as Strings, and would
not properly convert values to the appropriate type of the property in the
tag handler. That's fixed.
3. A tag that extends BodyTag can now handle nexted <jsp:include
page="foo.xxx"/>
4. Tag handler caching/recycling has been implemented. This is a
performance enhancement that is most noticable when you have lots of custom
tags on a page.
One notable known problem in beta 1 is that JRun doesn't handle taglib URIs
that depend on absolute URLs. So using this technique to specify a TLD will
cause a translation exception. This unfortunately affects Struts and
Jakarta Taglibs, which all depend on this way of resolving TLDs out of the
box (the work-around is fairly easy (but a pain in the ass)). Hopefully
this will be fixed in beta 2.
Best regards,
Scott Stirling
Allaire
-----Original Message-----
From: Mike Cannon-Brookes
To: [EMAIL PROTECTED]
Cc: Scott Stirling
Sent: 3/10/01 2:19 AM
Subject: RE: My revolutionary idea... JSPT!
Just thought I'd mention that it looks like Allaire has picked up my
idea in
their latest release of JRun. Cheeky bastards ;)
Their newest release of JRun (3.1 beta 1) includes a feature called JST
which are JSP tags built and autocompiled from JSP files, instead of
from
java classes following the tag API. I haven't had a chance to
investigate it
much (installing it in the background now), but I know Scott is on this
list.
I'll report back to the group when I've tried it.
Care to fill us in on how it is going to work Scott? Will we see a JSR
on
this in the near future?
-mike
> -----Original Message-----
> From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, December 23, 2000 12:15 AM
> To: [EMAIL PROTECTED]
> Subject: My revolutionary idea... JSPT!
>
>
> > > Much of the other ugliness about JSP is the tremendous amount
> > of references
> > > and configuration files from the taglib directive, to the
> taglib.tld, to
> > > web.xml. And there just aren't enough taglibs and tools yet,
> > so everything
> > > from writing the tag handlers to packaging them, to writing the
> > JSPs that
> > > use them are being done by the same group of programmers. The
> > division of
> > > roles and responsibilities is well-addressed in the J2EE specs,
> > but not too
> > > well implemented in practice a lot of the time.
> >
> > You're absolutely correct. I'm trying to get my current shop to
> recognize
> > the differences in roles now myself, because I'm tired of being
> developer
> > and deployer all at the same time, which makes determining what
> tasks need
> > to get done by whom and when rather confusing.
>
> The rest of this thread is interesting, but this intrigued me most -
it
> harks back to a discussion I had with some Servlet 2.3 spec guys a
while
> back. Here's a braindump of that discussion:
>
> Follow my logic for a second, for this is not all the ravings of
> a crazy man
> ;)
>
> 1) Servlets were invented, they were fantastic for building web
> apps... but
> it's crap coding HTML in out.println() statements.
>
> 2) Smart programmers realised that _often_ the majority of the code
was
> HTML, therefore the paradigm was wrong.
>
> 3) They invented JSP, which is HTML with a little Java mixed in
> for spice -
> which is effectively compiled into a servlet.
>
> 4) Then they thought about it more, JSP was good... but it lacked
> easy ways
> to add code snippets - thus they created... tags! Tags are
> basically an easy
> way to wrap code that you use frequently behind an easy to use
interface.
> These programmers were very happy with themselves.
>
> IMHO they stopped short of web developer nirvana.
>
> How many of you write tags to produce dynamic HTML? Answer - none.
>
> Because as Scott said, it's very cumbersome to write tags - and
> if we start
> writing HTML in a Java class (tag) we're back to 1.
>
> Why not have a special form of JSP... that is compiled into a tag
> automatically!
>
> I'll say again:
> JSP compiles to Servlets
> JSPT (or a real name) compiles to JSP Tags.
>
> Why the hell would I want to do that you ask?
>
> Simple, the current include methods do not allow you to pass
parameters
> which are not strings.
>
> Imagine I want the following simple tag to output a box in HTML:
> <html:drawbox forecolor="ffffff" backcolor="333333" border="2">
> my content
> </html:drawbox>
>
> This is a real bitch at the moment. I have to write a class,
> which has HTML
> coded in there... if I want to change the HTML I have to recompile the
tag
> etc.
>
> Now imagine the following JSPT page.
>
> <%-- start drawbox.jspt --%>
> <table cellpadding=<%= tag.getParameter("border") %>
> cellspacing=0 border=0
> background="<%= tag.getParameter("forecolor") %>"><tr><td>
> <table background="<%= tag.getParameter("backcolor") %>"><tr><td>
> <%= tag.getBody() %>
> </td></tr></table>
> </td></tr></table>
> <%-- end drawbox.jspt --%>
>
> Any HTML nut will tell you that the above draws a box, of variable
width
> using two nested tables. And any JSP nut can probably see what the new
> implicit "tag" variable scope does (pass data and parameters from the
tag
> called to the page).
>
> If you wanted to change the HTML produced, just edit the JSPT file and
the
> server would recompile it into a tag automatically (just like it
compiles
> JSPs automatically on change).
>
> In summary of my crazy proposal:
>
> Advantages:
> - makes writing tags which produce any HTML much much faster,
> fantastic RAD
> - you can let web developers write tags (this is a BIG problem at the
> moment, writing a tag is too complex for the guy JSP is pitched at)
> - changing tags is a quick process, recompilation is automatic
> - it's a very minor change to the spec (fully fleshed out of course)
>
> Disadvantages:
> - doesn't work well for non HTML producing tags (fair enough,
> servlets still
> have their purpose too!)
> - JSP bean-requestpassing-non-scriptlet zealots will be up in arms
(just
> cause it doesn't fit their paradigm of how a web app should be
written)
> - Allaire will be angry you stole their easy CFM tag making ideas
(writing
> tags in ColdFusion is the best part about it - it's beautifully easy)
>
> There ya go... spec writers, flamers, the above zealots, tag lovers -
any
> comments or feedback or flames most appreciated as always.
>
> -mike
>
> Technology Director - Asia Pacific
> [EMAIL PROTECTED] - internet.com Corp
>
