Hi Dave

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

Whoops - well spotted David. I'll fix the Ant build to make sure they get
included in the 0.3 release. Thanks for spotting this!

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

I'll try patch the code to remove this dependency. I must admit I've been
using 1.3 for so long I hadn't spotted this dependency. I should be able to
fix the code so its a non issue. Will try get the patch done ASAP.


> 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);
> }

I like this idea. I nearly went with this one initially. My (fairly
arbitrary) thought against it at the time was that if only the 'onEnd()'
semantics were available, as it is right now in ElementHandler's handle()
method, then you'd only ever get a complete, valid document.

On reflection I'm very tempted to go the onStart() and onEnd() route though.
It would make SAX like processing really easy, having a real, simple object
model to use rather than maintain state by hand yourself in SAX. And you get
XPath too... Would make much more complex pruning and event based processing
easier...

I'll ponder this some more over the weekend and report back to the list. I'm
very tempted to go with your suggestion.

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

Yes.

Incidentally, the "pruning mode" takes an ElementHandler - though if you
want to can add an ElementHandler to a SAXReader such that you are called
when every Element is complete - so you could build your own complex pruning
algorithms using this mechanism.

Though it would be more flexible and powerful if we had onStart() and
onEnd(). I think I've just convinced myself already... ;-)

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

Sounds awesome. I'd love to include something like this in the standard
dom4j distribution if you ever fancy donating it ;-)

> That would be great!  The less code (for me) to write the better
> (for me :^)

Cool. Thats the idea anyway - for us to share code rather than reinventing
wheels.


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

That was one of the reasons for me starting dom4j in the first place -
making it easy to extend both from the builder / factory perspective and
from the XML tree implementation.

Now all I need is some more spare time so I can add an XML Schema Data Types
compliant DocumentFactory... ;-)

> Once again, great job and thanks!

Thank you Dave. I'll get back to you as soon as I've committed the
aforementioned changes.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev

Reply via email to