(resend) Re: My revolutionary idea... JSPT!

[Eduardo Pelegri-Llopart <Ed...@Sun.COM>]

The JSP expert group has been interested for quite a while in a
mechanism for supporting abstraction of a JSP fragment.  Different ideas
have been considered, and during the JSP 1.2 design stage I encouraged
the expert group to consider the problem.  Unfortunately JSP 1.1 had
been released very recently, many partners in the expert group were busy
with their own products and there was no time to build the consensus on
the importance of this.

I still believe a mechanism to do something like JST is a good idea.  I
have not looked at the specifics of Allaire's JST in quite a bit, so I
can't comment on that, but I hope that experience with that mechanism
and others can be used at some point in the future to define a standard
mechanism.  As Scott mentions, at this point no decisions have been made
on whether this is best done in a JSP 1.3 JSR or separatedly...

	- eduard/o

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.
> 
...
> 
> Scott Stirling
> Allaire
> 
> 
> -----Original Message-----
> From: Mike Cannon-Brookes
> To: taglibs-dev@jakarta.apache.org
> 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:mcannon@internet.com]
> > Sent: Saturday, December 23, 2000 12:15 AM
> > To: taglibs-dev@jakarta.apache.org
> > 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
> > mcannon@internet.com - internet.com Corp
> >