You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Pierre Delisle <pi...@sun.com> on 2000/09/01 23:44:05 UTC
[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/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
Re: [proposal jasper] JSP pages as XML documents (long)
Posted by Pierre Delisle <pi...@sun.com>.
Danno Ferrin wrote:
...
> Right now though we need to keep in mind that some sort of a
> representation of an XJsp page from the JspParser will be needed by the
> TagLibraryValidator class in the form of an input stream for the
> equivalent XJsp document. Perhaps we should be going straight for
> Craig's proposal rather than do a first pass on the XML support, because
> I don't want to implement a solution that architecturally we would need
> to throw away.
>
> What do you think of re-factoring Japser in place into the
> Parser/Validator-Transformer/Generator/Compiler/Deployer sequence with
> the appropriate pass off objects first?
Personally, I'd like to play it safe. As I mentioned in my proposal,
while the end-goal is to re-architect jasper according to the
architecture proposal put forward by Craig, the short term goal is to
have JSP1.2 compliance as soon as possible, while minimizing changes
to ensure stability.
Craig has mentioned a beta release of approx 10/20. We
need to be feature complete by then. I would not want
to delay the beta release because of architectural issues.
My current proposal plugs as much as possible into
what already exists and the work is quite straightforward.
I suggest we get it done quickly (along with the new changes
in the spec), learn from it, and then (or even in parallel)
move to a new architecture where the cleanup of the code
base can be more exhaustive, and where all appropriate
discussions can take place without time pressure.
-- Pierre
Re: [proposal jasper] JSP pages as XML documents (long)
Posted by Danno Ferrin <sh...@earthlink.net>.
I am negotiable on the ParserController. That would reduce the clutter
inside the parser class since what I described dose seem very special
case oriented. This file will allow for other migration oriented
parsers to be plugged in as well.
Separating out the parse data also is good, since it can provide another
place to evolve the code generators without having to mess with the
other code (such as if we made code generators to interface with a
high-performance default JspPage that has hooks to register dependent
included pages for updating, which seems to be a popular feature
request). +1 on that.
The ParserXJsp sounds exactly along the lines of how I would have done
it, SAX is lighter weight than DOM, but the final draft of JSP1.2 may
make it more palatable to pass out a DOM tree of the first stage parse
before we start attacking it to create the ParseData (which is currently
done in the JspParseEventListener implementation).
Right now though we need to keep in mind that some sort of a
representation of an XJsp page from the JspParser will be needed by the
TagLibraryValidator class in the form of an input stream for the
equivalent XJsp document. Perhaps we should be going straight for
Craig's proposal rather than do a first pass on the XML support, because
I don't want to implement a solution that architecturally we would need
to throw away.
What do you think of re-factoring Japser in place into the
Parser/Validator-Transformer/Generator/Compiler/Deployer sequence with
the appropriate pass off objects first?
--Danno
Pierre Delisle wrote:
>
> Danno,
>
> Thanks for your comments on the proposal. More info inserted
> below.
>
> > 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.
>
> I think we're pretty much in sync here, except for some ambiguities on my
> part (see below) and that I suggest creating a few additional classes to
> avoid overloading too much the existing classes;
> mainly Parser and JspParseEventListener.
>
> With the introduction of a new syntax (XJsp), and maybe the will to
> support even more in the future (as you hinted in the past),
> my thinking was to encapsulate some key elements in their own class.
>
> Namely:
> - ParserController which handles pre-parsing tasks:
> - get the input stream for the document
> - select the proper parser
> - ParseData
> - holds all parsed information (instead of being in
> JspParseEventListener)
> - ParserXml
> - Counterpart to ParserJsp, for the XJsp syntax. My description
> was ambiguous there.
> I mentioned both ParserXJsp and XJspParseEventListener. The two
> are in fact bundled together within ParserXJsp (and I should
> have used the name XJspSaxListener instead of XJspParseEventListener).
> And definitely, ParserXJsp uses JspParserEventListener for proper
> handling of the tags.
>
> > 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.
>
> Agree. There is room for experimentation and we'll probably end up with
> a few 'quick' implementations to test these ideas.
>
> I should have a JAXP-DTD based implementation ready shortly.
> I think code organizations issues can easily be solved once we have
> a concrete implementation available (won't be an issue to move chunks
> of code around to make sure the code is as clean and maintainable as
> possible).
>
> >
> > Well, I gotta go sleep, so if it is incoherent that is why.
> >
> > --Danno
>
> -- Pierre
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proposal jasper] JSP pages as XML documents (long)
Posted by Pierre Delisle <pi...@sun.com>.
Danno,
Thanks for your comments on the proposal. More info inserted
below.
> 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.
I think we're pretty much in sync here, except for some ambiguities on my
part (see below) and that I suggest creating a few additional classes to
avoid overloading too much the existing classes;
mainly Parser and JspParseEventListener.
With the introduction of a new syntax (XJsp), and maybe the will to
support even more in the future (as you hinted in the past),
my thinking was to encapsulate some key elements in their own class.
Namely:
- ParserController which handles pre-parsing tasks:
- get the input stream for the document
- select the proper parser
- ParseData
- holds all parsed information (instead of being in
JspParseEventListener)
- ParserXml
- Counterpart to ParserJsp, for the XJsp syntax. My description
was ambiguous there.
I mentioned both ParserXJsp and XJspParseEventListener. The two
are in fact bundled together within ParserXJsp (and I should
have used the name XJspSaxListener instead of XJspParseEventListener).
And definitely, ParserXJsp uses JspParserEventListener for proper
handling of the tags.
> 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.
Agree. There is room for experimentation and we'll probably end up with
a few 'quick' implementations to test these ideas.
I should have a JAXP-DTD based implementation ready shortly.
I think code organizations issues can easily be solved once we have
a concrete implementation available (won't be an issue to move chunks
of code around to make sure the code is as clean and maintainable as
possible).
>
> Well, I gotta go sleep, so if it is incoherent that is why.
>
> --Danno
-- Pierre
Re: [proposal jasper] JSP pages as XML documents (long)
Posted by Danno Ferrin <sh...@earthlink.net>.
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" <pi...@sun.com>
To: <to...@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
>
>