Return-Path: <anilv@pacbell.net>
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 45967 invoked from network); 23 Dec 1999 08:22:43 -0000
Received: from mta3.snfc21.pbi.net (206.13.28.141)
  by 63.211.145.10 with SMTP; 23 Dec 1999 08:22:43 -0000
Received: from pacbell.net ([63.194.80.136])
 by mta3.snfc21.pbi.net (Sun Internet Mail Server
 sims.3.5.1999.09.16.21.57.p8)
 with ESMTP id <0FN600CYWPVJMM@mta3.snfc21.pbi.net> for
 tomcat-dev@jakarta.apache.org; Thu, 23 Dec 1999 00:21:21 -0800 (PST)
Date: Thu, 23 Dec 1999 00:25:10 -0800
From: Anil V <anilv@pacbell.net>
Subject: Re: more on XML style scripting elements (was Re: cvs ...
 JspUtil.javaParser.java)
Sender: akv@mta3.snfc21.pbi.net
To: tomcat-dev@jakarta.apache.org, pelegri@eng.sun.com
Message-id: <3861DC66.E5E11D00@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <19991221213803.29403.qmail@locus.apache.org>
 <005f01bf4c2b$01c42640$6c4ff4d1@DRF26> <386043B4.576A530E@gefionsoftware.com>
 <007901bf4c44$142cf140$6c4ff4d1@DRF26> <3861A42D.9F0F922C@gefionsoftware.com>
 <3861A874.88AA808D@mytownnet.com>

"Craig R. McClanahan" wrote:

> Hans Bergsten wrote:
>
> > Danno Ferrin wrote:
> > >
> > > What would constitute "fully cooked?"
> >
> > My comment about not fully cooked is based on comments made to this list
> > by some of the people who have implemented the JSP parser, plus the
> > description of the XML equivalents in the JSP spec. To use the equivalents
> > it not enough to replace <%= %> with <jsp:expression> </jsp:expression>.
> > The body of the element must also be encoded one way or another to avoid
> > special characters like < to confuse a real XML parser. As far as I know,
> > the parser doesn't deal at all with these types of encodings.
> >
> > > In light of this I think it may be
> > > good to nix the existing XML tags in the current implementation.
> >
> > I tend to agree, but it's a change I feel requires a vote before it's
> > done.
> >
>
> How much effort would it take to make the parser "fully cooked"?  If it's not
> exhorbitant (and we had volunteers willing to do it :-), I'd rather see that
> happen.  Otherwise, I'm +1 on removing the current "half baked"
> implementation.

Actually, I'm inclined to say that the parser is just doing what the spec sez.
The notion of a fully XML-compliant JSP page needs to be refined in the spec. We
need to say how the body of a scriptlets will be encoded by a JSP author (and
thereby how it will be transformed to code by a JSP engine). Chapter 4 of the
spec pretty much says that you need to out.print(...) template data (which BTW
itself could be HTML == not XML compliant) and you need to
out.print(<expression>) etc.

Re: implementability, once the rules of how things are going to be encoded in
scripting elements are laid out, it should be pretty straightforward either
implementing them as builtin actions or as a special custom tag mechanism which
gets to be invoked at compile time and gets to write things into the servlet
.java file.

As I see it this is a very important enhancement we should all work towards for
the next JSP specification.

At some point we have also talked about transforming a JSP page into an
XML-compliant page. If such a transformation is defined then we could just use
the existing JSP parser to do that transformation and then plug the code
generator as a SAX backend. So the data flow would look like:

JSP page --> JSP2XML transform --> XML-parser --> JSP Listener -- generates
--> servlet.

or

XML-compliant JSP page --> XML-parser --> JSP Listener -- generates --> servlet

Anyway, this is a big vacation for me and I need to stay off this stuff. Lots of
time to think about all this in 2K, if the disaster doesn't happen :-)

Happy christmas and new year to y'all.


Anil