A mechanism for
Scott Stirling wrote:
>
> 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
> >
