jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spike Washburn" <sp...@macromedia.com>
Subject Re: My revolutionary idea... JSPT!
Date Sat, 31 Mar 2001 14:27:09 GMT
JRun JSTs are part of JRun 3.1 which is in beta right now.

You can download the beta at:
http://www.allaire.com/handlers/index.cfm?ID=20379

Thanks,
Spike


----- Original Message -----
From: "Jon Baer" <jonbaer@digitalanywhere.com>
To: <taglibs-dev@jakarta.apache.org>
Cc: "Scott Stirling" <sstirling@allaire.com>
Sent: Friday, March 30, 2001 1:55 PM
Subject: Re: My revolutionary idea... JSPT!


> Hi,
>
> I know this is a "Jakarta Taglibs Forum", but can someone please tell me
where
> in the world the JRun JST's are documented?  Id like to try it out but
can't
> find one sample or anything in documentation, is there an updated doc
(someone
> have the URL?)
>
> Thanks.
>
> - Jon
>
> 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: 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
> > >
>


Mime
View raw message