tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danno Ferrin" <shem...@earthlink.net>
Subject Re: [proposal jasper] JSP pages as XML documents (long)
Date Tue, 05 Sep 2000 06:06:57 GMT
I don't think we need ot go that extreme.  We can layer a SAX Listener to
feed into the JspParseEventListener (we may need to keep some state and such
in the listener as well, but if we turn on validation most of the error
sources should disappear).

The main change in the parser is to add a case for when we detect a jsp:root
element.  If there have been scripting elements (non character data) before
that we throw a parsing error (since jsp:root is defined as the root element
it cannot occur elsewhere) , otherwise we restart the input stream and feed
it into the XJspSAX listener which feeds into the existing
JspParseEventListener.  (This would eliminate the role of the
ParseController class.)  Since the jsp:root element is defined nowhere else
than in the XML transformation chapter and the jsp: namespace is reserved it
cannot occur only in a XJsp page and it's occurance in a Jsp page is an
error.

I am actually -1 to creating a paralell XJspParseEventListener because I
don't see what special cases need to be handled.  If there is an actual need
for one (and I am skeptical of that) then we should re-factor, create a
parent AbstractJspParseEventListener that would be subclassesd, and add the
methods that would encapsulate the needed changes.  But paralell duplicate
code creates problems for maintenence and evolution.

As for validating, yes namespaces make it impossible to define a static DTD
(unless defined by the page author, which is dangerous) but with the
namespaces in the root element, the parser could pre-parse the jsp:root
element before handing it off to the sax listener and pre-feed the sax
parser (or rig the input stream) a DTD based off of the known JSP syntax and
the taglibs.   Using the pre-release XML Schema and having the tld urls be
treated as well known schemas and providing them to the parser may be
something to be considered as well, since we do not need to fabricate a DTD
in that instance.

Well, I gotta go sleep, so if it is incoherent that is why.

--Danno


----- Original Message -----
From: "Pierre Delisle" <pierre.delisle@sun.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Friday, September 01, 2000 3:44 PM
Subject: [proposal jasper] JSP pages as XML documents (long)


> One of the major new feature in JSP1.2 is the mandated support for JSP
> pages as XML documents (see chapter 5 of the spec).
>
> Below is a proposal for a 'first' implementation of that
> new feature.
>
> [Please note that the work is going to be done on the Tomcat 4.0 tree,
> not the Tomcat 3.x tree.]
>
> The goals of that first implementation are as follows:
>
>    1. Get it done as soon as possible so we can experiment with
>       the new feature and provide feedback to the expert group
>    2. Minimize changes to the current code base so we keep
>       jasper stable.
>
> As our community gets more knowledgeable about what it really takes
> to fully embrace the XML bandwagon, we can then start developing in
> parallel a new code base (isn't it fashionable these days :-))
> that would make some major changes to the way jasper is
> currently architected and which would be more
> in line with the new architecture proposal for jasper.
>
(http://jakarta.apache.org/tomcat-4.0/jakarta-tomcat-4.0/jasper/doc/dev/jasp
er-proposal.html)
>
> -----
> Proposal: support for JSP pages as XML documents
>
> We now need to support two syntax types: JSP syntax proper
> (referred to as simply JSP), and an XML syntax for JSP
> (referred to as XJsp).
>
> With respect to parsing, there are many approaches,
> among which:
>
>   a. make the current parser recognize both syntaxes
>   b. use of a jaxp compliant parser to parse an XJsp document
>   c. translate JSP doc into XJsp, and use b) to parse.
>
> I propose b) for now.
>
> Given that we now have two ways to parse a document, we would have
> the following changes in our parsing classes:
>
> - ParserController
>
>   This is a new class that is the "controller' of the parsing
>   phase. Given a JSP document, it figures out which syntax it is in,
>   and feeds it to the proper parser.
>
> - Parser
>
>   This is a new base class for all parsers. Each input syntax has
>   its own implementation. We'll have ParserJsp and ParserXJsp.
>
>   ParserXJsp would use a JAXP compliant SAX parser, since this gives
>   us the most flexibility (we have to keep track of line and col
>   numbers). A validating parser could be used (by generating
>   the DTD on the fly), but some people have mentioned that
>   the fact that we use namespaces might cause problems with
>   a validating parser. Please expand on this if you have the
>   full story. Validation routines already used by the JSP parser
>   will simply be reused by the XJsp parser.
>
> - ParseData
>
>   We would extract from JspParseEventListener all "parse data" information
>   and encapsulate it into this new class.
>   ParseData is created by ParserController and is shared by all
>   "parse event handlers" invoked during the parsing of
>   a document.
>
>   The "parse data" currently consists of a vector of "Generators"
>   that output the code at the code generation phase. I'd keep this
>   intact, except for adding the capability to also output the
>   XML syntax.
>   A change to a real parse tree should only be tackled
>   once the expert group settles on which one exactly
>   should be exposed.
>
> - XJspParseEventListener
>
>   This is a new class and is the counterpart of JspParseEventListener
>   for the XJsp parser.
>
> - Generators
>
>   The generators continue to exist as is, except that we augment them with
>   the capability of outputting "XML syntax". This is required so that
>   when we get a JSP syntax document, we can create the PageInfo object
>   (which gives access to an XML input stream for the validation phase
>   in tag libraries).
>
> Hope my descriptions are not too confusing... and thanks
> for taking the time to comment/vote on this proposal...
>
> -- Pierre
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


Mime
View raw message