tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Delisle <>
Subject Re: [proposal jasper] JSP pages as XML documents (long)
Date Tue, 05 Sep 2000 21:05:33 GMT

Thanks for your comments on the proposal. More info inserted

> 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.

- 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 
- 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

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

    -- Pierre

View raw message