tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Delisle <pierre.deli...@sun.com>
Subject [proposal jasper] JSP pages as XML documents (long)
Date Fri, 01 Sep 2000 21:44:05 GMT
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/jasper-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

Mime
View raw message