James,
Thanks for the quick response...
I actually just tried to change the ElementStack class
to public (locally on my machine) and tried to build, but
I ran into a couple issues. The first is that the Antlr
grammar files in org.dom4j.xpath.parser aren't included in
the distribution. I was able to get around this, by just
getting them from the CVS repository. No big deal.
The second problem has me stuck at the moment...
I got the following build error:
compile:
[javac] Compiling 243 source files to D:\temp\dom4j\build\classes
[javac]
D:\temp\dom4j\build\src\org\dom4j\xpath\util\DocumentOrderComparator
.java:55: No variable EMPTY_MAP defined in class java.util.Collections.
[javac] _orderings = Collections.EMPTY_MAP;
[javac] ^
[javac]
D:\temp\dom4j\build\src\org\dom4j\xpath\util\ReverseDocumentOrderCom
parator.java:55: No variable EMPTY_MAP defined in class
java.util.Collections.
[javac] _orderings = Collections.EMPTY_MAP;
[javac] ^
[javac] 2 errors
BUILD FAILED
This seems to be based on the java.util.Collections class changing from
jdk1.2.2 to jdk1.3. I'm trying to compile with jdk1.2.2. I didn't see
anywhere previous to this that dom4j was dependent on jdk1.3.
Maybe dependent is a bad choice of words, as it's not run-time dependent,
but anyway it's a bit inconvenient. I'm not a Java expert or anything,
so I'm not sure the best way for me to get around this?
As far as the ElementStack and ElementHandler issues, my thoughts
are below...
> > The one thing that I really liked was the so-called
> "pruning mode", which
> > allows processing only elements that I'm interested in. I do have a
> > question about this though...
> >
> > It appears that for any single parse, you can only specify
> a single path
> > for which you'd like to prune elements. What would be
> nice, is if you
> > could specify a set of paths to prune and associate each path with a
> > different ElementHandler implementation. I've been able to
> do this, but
> > with more hacking than I really wanted to. Let me explain...
>
> You could do all this inside a single ElementHandler. i.e. do your own
> pruning and event dispatching scheme via the ElementHandler.
>
> SAXReader reader = new SAXReader();
> reader.setElementHandler( new MyCompositeElementHandler() );
>
What do you think of the following interface for ElementHandler
public class ElementHandler()
{
/** Called by SAXContentHandler's startElement after
it has created the element and set all its attributes
*/
public void onStart(Element element);
/** Called by SAXContentHandler's endElement after it
has popped it off the ElementStack
*/
public void onEnd(Element element);
}
This would allow you to define an ElementHandler implementation
which would be called at the start and end of each element
encountered. A sort of "universal" handler.
>
> > In looking at the org.dom4j.io.SAXReader and
> org.dom4j.io.SAXContentHandler
> > classes it seemed that all I may need to do was extend the
> SAXReader class
> > and override the createContentHandler method to create a
> SAXContentHandler
> > which used my own custom ElementStack subclass.
>
> Yes - I left that hook in as a possible extension mechanism.
> My hope was one
> day to have some flexible, more powerful ElementStacks...
>
> > I couldn't do this though,
> > as
> > the ElementStack class isn't public, so I can't extend it's
> functionality.
> > Would it
> > be possible to make this class public, to allow application level
> > derivations?
>
> I'm sold - sounds a great idea. So you're going to do a kind of
> CompositeElementStack thing to fire multiple ElementHandlers?
Yep...
What I was planning on doing was have my own ElementStack subclass,
which had a member Hashtable which mapped XPath like locations
(i.e. /foo/bar/baz) to different ElementHandler implementations.
The stack would also have a member String which maintained the
current location to provide quick lookup of the ElementHandlers.
Then, the pushElement and popElement would keep track of the
current path location and call the appropriate ElementHandler
for the current location (if any...). My ElementHandler's would
implement the interface I proposed above.
> It might be
> nice to add something like this into the dom4j API when we've
> experimented a
> bit more. I've always wanted a path based listener support too...
>
> I've made ElementStack and PruningElementStack public and
> made ElementStack
> a property of SAXContentHandler. I'll have a think about
> adding some API
> hook to SAXReader such that you can specify the ElementStack
> to use via a
> property to save you deriving your own SAXReader / SAXContentHandler.
>
That would be great! The less code (for me) to write the better
(for me :^)
I've looked at doing this with JDOM as well, but it looked like I would
need to do a whole bunch of code duplication in creating my own builder/
content handler, etc. With dom4j, just about all the hooks in place to
make this a fairly painless exercise!
> I've just changed the CVS repository, so if you take the
> latest CVS image
> you'll be fine. I'll do the 0.3 release real soon now too.
>
Once again, great job and thanks!
Dave White
--
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
