Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <39B57B4A.8BFA2F0B@earthlink.net>
Date: Tue, 05 Sep 2000 17:01:30 -0600
From: Danno Ferrin <shemnon@earthlink.net>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [proposal jasper] JSP pages as XML documents (long)
References: <39B02325.390800FB@sun.com>
 <012c01c016ff$af2dcda0$8cf5b23f@shemnon> <39B5601D.F1BF4EA2@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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