Re: [dom4j-dev] DOM2 Events in DOM4J

[James Strachan]

Hi Mats   I'll study the DOM2 Events spec and see if there's a clean way of adding support for tree mutation events without adversely affecting performance.   The Elements telling the Document that something has changed seems like a good approach, I´ve been thinking about using the ElementHandler at parsetime to look for the XHTML Event elements like "onevent" and based on that instantiate an appropriate listener and add it to some kind of listener stack. When the complete tree is in memory maybe there is a way to attach them to the appropriate element. Agreed. Maybe some way of listening either to all changes to the tree, or all changes which match a specific type of element, might help. So maybe an EventListener API that supports XPath filtering might be useful...   If the document is the responsible party it may be simpler than that. An element could tell the document about a change in it´s status according to some kind of eventinterface and the Document could fire the appropriate eventlistener. Could there be a problem with several events firing and telling the Document that something has changed? I mean performance wise? I guess it could be modeled on the W3C DOM2 Events but it should definitely be optional to have the events turned on or off. Is it possible at parse time to build the tree structure with or without events turned on. Two different implementations of the Node, one which implements some kind of eventhandling? If (say) the Document was the event dispatcher, then it might be possible to have a single tree implementation that could implement events or not without affecting performance too much. If needed we could have a flag on a document to disable event firing.   The only current issue is that to conserve RAM most Element implementations only contains a reference to its owner, which is either its parent Element or the Document. So all Element implementations currently walk up the tree of Elements to get to the Document, which for deeply nested documents would be a performance penalty.   Though if changing this to have 2 instance variables, the parent Element and Document, does not adversely affect performance too much it might make sense to go this route.   James