[jdom-interest] Proposal: JDOM event based processing

[James Strachan]

Hi Randall

----- Original Message ----- 
From: Randall  <mailto:RParr at TemporalArts.COM> J. Parr 
 
[snip]
 
Whoa there. There is a big difference. In SAX processing the ContentHandler
defines ONE startElement and ONE endElement that handle the start/end events
for ALL elements encountered and you must keep track of which element you're
in, etc. 

Agreed. I was thinking before more about the interface you'd use - .
ContentHandler versus ElementHandler. I think you've totally convinced me
that in the proposed SAXProcessor we should treat ContentHandler and
ElementHandler equally.e.g.
 
 
import org.jdom.ElementHandler;
import org.sax.ContentHandler;
 
public class SAXProcessor {
 
    /** Handle sub element events at the SAX level - start/end elements */
    public void addContentHandler( String xpathExpression, ContentHandler
handler ) { 
        ...
    }
 
    /** Handle sub document events - one or more Elements in a branch */
    public void addElementHandler( String xpathExpression, ElementHandler
elementHandler ) {
        // we could probably implement the Element tree building and
        // calling of an ElementHandler object as a ContentHandler
        JDOMContentHandler contentHandler = new JDOMContentHandler(
xpathExpression, elementHandler );
        addContentHandler( xpathExpression, contentHandler );
        ...
    }
 
 
}

Alternatively, you can use something like Robert Hustead's SaxMapper package
(described in "Mapping XML to Java, Part1/2", www.javaworld.com). 

I'll take a look, thanks. 
 
I think much of what we're talking about here is a filtering / layering on
top of SAX to allow XPath expressions to be routed to a ContentHandler which
may then build a JDOM Element tree which then calls an ElementHandler when
the tree is buit. There shoudl be 2 levels of interaction, the SAX
ContentHandler or the JDOM ElementHandler.
In fact the JDOM ElementHandler functionality will probably be implemented
as a SAX ContentHandler anyway ;-)
 
In fact the JDOM ElementHandler part of the SAXProcessor code can probably
we written as a SAX ContentHandler implementation - so the implementation of
this entire proprosal will be mostly SAX. 
 

What I see you proposing (ala Saxon) is a BIG improvement because you define
a handler for a given element (or path/element expression) somewhat
equivalent to an XSLT template. 

Yes, though I initially was only considering it from the JDOM level - i.e.
having complete Element trees. You've now convinced me we should consider
SAX and JDOM levels together. 


[snip]
 
I would also like to point out that attaching processing to a high-level tag
like <TABLE> does NOT generally require storing the entire tree in memory. 

[snip]

I totally agree!
 
J.
 
James Strachan
=============
email: james at metastuff.com <mailto:james at metastuff.com> 
web: http://www.metastuff.com <http://www.metastuff.com> 



If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.