tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danno Ferrin" <shem...@earthlink.net>
Subject Re: Jsp scripting elements revisited
Date Sun, 23 Jan 2000 19:07:51 GMT

<rubys@us.ibm.com> worte:

[snip]

> > Don't take this the wrong way, but is there any demonstratable harm to
> > what was done?  (removing the support)
>
> It shipped.  Many companies (mine especially) take backwards compatibility
> very seriously - even if the issue is being compatible with a bug.

And it was a bug.  Does backward compatibilty mean don't fix bugs?

> It also was function that I was planning on building upon.  See below.

Backward compatibility is fine, but I don't buy that it should be bug
compatible either.  Since this is open source I don't think that the
backward bug compatibility issue exists since the vendor can tweak it as is.
If java had #ifdef and #define support this wouldn't be as traumatic an
issue as it has been.

How about I put the support back but in but the implementation code first
test against a constant that has a static final value of false, and if the
compatibility is needed then the vendor can change the source code to true
and recompile it?

[snip]

>
> I have support for self-contained ECMA 262/NetRexx/JPython blocks working
> on my machine.  I also have JACL, TCL, LotusScript and VBScript and Perl.
> I've nearly got PHP there.  The language does not have to be a compiled to
> a Java byte code language to work.
>
> I said I had it working on my machine.  I privately maintain what amounts
> to a parallel branch and have been actively working to merge the two.
> I've got it down to two source files that need to be changed, but have not
> checked them in because they contain unauthorized extensions to the spec.
> I'm still working on it.

How about posting what you do have as a revolution, ala the catalina code.
Then we could see whaqt is really going on without abstract discussions.
Perhaps someone out there has a slick solution to our problems.  More eyes
couldn't hurt.

> I don't have blocks which start in one tag and end in another working yet.
> I had hoped to integrate what I had before working on that first.
>
> On the 14th of January, the distance between my code base and the official
> Jasper baseline increased.

And it took a week to notice?  This tells me that what you are doing is more
likely revolutionary and not evolutionary, see my above block.

> > Perhaps we could convince some sadistic CS professor to make the
> > scripting tags as a TLD a senior project to some unsuspecting innocents.
> > But the tags would have to be written on a per-language basis, adding
> > JPython would require re-writing the tags.  The current setup of the
> > taglib API keeps that issue completely compartmentatlized away from the
> > tag libraries.  As long as the languages fully use the JVM any part can
> > be written in any language as long as the JVM protocols are kept.
>
> Not true.  The tags could be written as <jsp:scriptlet language="java">.

Which would require a change in the spec.  It also would allow seperate
languages in the same jsp page which would be a) cool and b) encourage
component based includes.  Couldn't you just use a diffrent name space for
the tags you want to do rather than integrating them directly with jsp?

> > +1 on the "JSP Standard Actions Tag Library"  If I get time I can even
> > write it, I just need to get moved in an settled down.
>
> Cool!
>
> > 0 on the JSP scriting elements as tag libraries.  Congrats if you can
> > make it work, I just am not into that sort of self inflicted pain.  If
> > you figure out how to get declerations reliably working let us all know.
>
> I fully expect that this effort will expose some serious issues in the
> current spec for tag libraries.  I've alerted Eduard/o on this
> possibility, and he seems quite supportive of this effort.
>
> <humor> I just hope that nobody hears this and decides to remove the tag
> lib support from Jasper in the interim. </humor>

I guess you havent gotten my latest cvs commit then. ;)

> > I still think that there is value to having more that just scriptlets
> > handeled as a special case in the compiler.  Section 5.3.4 actually
> > endorses it for tag libraries.  Consider that for the typical JSP
> > lifesycle the page is compiled once and executed hundreds, thousands,
> > maybe millions or more times.  Now if for each page execution we are
> > making the same decision each time that invariably has the same result
> > each time, such as which method gets called to set the value of a
> > particualr property, then those add up, alot.  But if we could make that
> > decision _once_, even if it takes ten times as long to do it, and make
> > the implemenation of those pages assume that decision then almost
> > always a time savings will be seen.
>
> I submit that compile time tag libraries need to be a priority for the
> next revision of the JSP spec.
>



+1, some requirements though

* Any taglib implementing it must also implement the current bean driven
taglib mechanism.  This is because the compile time speed up could be in a
diffrent language than the page.  The page could be an ADA95 program fed
into the ada compiler after all.

* A means for turning this option off on a per library basis, perhaps an
extra attribute to the taglib directive would be good.  For eaxample <%@
taglib prefix="foo" uri='mytaglib.tld' integrate='no' %>

* Let the tag library veto the use of the extensions after being given info
on the JSP engine, the current directives (page, taglib, and specificaly
that page language tag), and other relavant information.  If optimization is
vetoed then use the bean based tag handlers.

* As a reccomendation for implementation, have the optimization be a set of
scripting elements returnd by the translation time bean handler, these
elements are a series of declerations, directives, scriptlets, and actions
that should be treated as though they appeared right in the page.  This is
what brought to mid the veto requirement, the optimized implementaion may be
in java but the page language may be visual basic.

--Danno

p.s. I am going to land some code refactoring stuff in jasper just as soon
as M1 goes golden, there is one class name change but I will post details
when I do it.



Mime
View raw message