tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Jsp scripting elements revisited
Date Sun, 23 Jan 2000 16:06:32 GMT

> I have no problem with that, but when the preson who wrote the spec (or
> is the most accountable party in that regard) says we are doing
> something i wrong then I tend to listen.

Listen is good.  So is due process.

> 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.

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

> of course eduard/o could just fake us all and add it
> into the spec. ;)

I don't believe that eduard/o said that the current spec was wrong in
this area, just perhaps not complete.  I would expect him to listen to
reasonable arguments for expanding this, and I propose to do exactly that.

> However one of the cavets in the 1.1PR1 spec was that it may lead to
> performance degredation.  WRT the bean code I am almost certian that we
> will se some degredation with set/getProperty and useBean becuase of the
> reflection that can be optimized out at compile time.

All the more reason to do it and thereby drive the spec to be more
complete.  It is in no one's best interest to have a spec written in
such a way that makes high-performance implementations impractical.
This will discourage the use of tag extensions.

Compile time tag extensions are a must.

> Using the taglibrary API as it stands doing so would be a monumental
> task that would include integrating or basically writing a java compiler
> since the blocks can start in one tags and stop in the other.  I'm not
> saying it cannot be done, but it is a whole lot of effort that is best
> spent in other places, such as adding ECMA 262/NetRexx/JPython support
> in the language page directive (isn't that why you came on board sam?)

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.

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.

> 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">.

> +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.


> 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 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.

View raw message