tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil V <>
Subject Re: more on XML style scripting elements (was Re: cvs ...
Date Thu, 23 Dec 1999 08:25:10 GMT
"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.


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.


View raw message