Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Subject: multiple languages...
To: tomcat-dev@jakarta.apache.org
Cc: 
Bcc: 
Date: Wed, 20 Oct 1999 02:56:39 GMT
Message-ID: <OF88AD5DE8.44180F22-ONCA256810.000E44BA@multitask.com.au>
From: dion@multitask.com.au
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

"We did not pursue other languages initially due to several reasons,
including that they complicate the portability story, but if there is
real interest, I'll be very happy to help with the effort.  I personally
find that I am writing more and more tag libraries and not using as many
scripting elements (also using more nesting for action communication,
rather than scripting variables).  Note that a tag library essentially
defines a specialized language."

The only problem I see is that writing a tag lib is a much higher entry
learning curve for a newbie.


"I am not convinced that we can easily mix-and-match multiple scripting
languages within a page.  The problem is that each language has its own
syntax and semantics, and the scriptlets in JSP are not even fully
formed statements, they can be anything (as long as... see the spec for
details), so defining what is a well-formed page in the presence of
multiple program fragments of multiple languages is going to be
"interesting".  Specially without imposing unwanted constraints on the
implementation.  One can probably do better by restricting what can be
used in the scriptlets, but note that some people really like to say
things like:

     <% for (int i=0; i<34; i++) { %>
     stuff....
     <% } %>

or even more convoluted things...  But lets' see...."


I'm with you on this one....for example doing something like:

<% if (cond) {  %>
<p>Blah
<% } else { %>
<p>Blah blah
<% $perlcode = $cond; %>
<% } %>

is theoretically possible, but not a good option IMHO.

I'm also interested academically in making the DOM available to javascript
*during* JSP processing, along with the implicit document object, sans
window....


"Going through an XML rep seems reasonable, although we will need to
coordinate it with the JSP.next effort when that gets moving (see
above).  I would not worry too much about things like the att="<%=
...%>" stuff in the current syntax; we have a lot of freedom in the XML
mapping - the JSP 1.1 and JSP 1.0 specs explicitly (and for this very
reason) indicate that the mapping indicated there may change.

And yes, we want to use XSL and to feed to XSL (and other
transformations).  Some of the latter can already be done in JSP 1.1
although nowhere as nicely and/or efficiently as I want."

Currently the code does most of the code generation work at end of document
processing, so it theoretically isn't too hard to change the existing
implementation to build an XML document on the fly during the handle*
methods and then process at the end...is this what you'd envisioned??

"Hope this helps,  It is great to see all this interest and energy.  I
think we are headed for a few very "fun" months."

Other things in this context on my 'hot list' are command line compiles for
example....is that currently done?

I couldn't find a main() in org.apache.jasper.compiler.JspCompiler...

--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Play:        http://www.softwaresummit.com
I'm presenting at the Java Programming Conference
"Colorado Software Summit" this year, see you there!