Hi everybody, after thinking some weeks about how to enable Java-style change events within dom4j I got yesterday some free hours to implement some classes. I would like to invite you to have a look at the code and to comment, what you think is good and what's bad.
At the moment only Attributes are working. As code base I used the dom4j-daily.tar.gz from yesterday. Simply unzip the attached zip-file and do a build. Should compile without problems. Some details: - Facades, not inheritance: The event handling is implemented in facade classes. That means, that if you want use event handling at the creation of any node always a second facade object has to be instantiated. The main advantage is, that no existing interface or code has to be changed and every class implementing the org.dom4j interfaces can be event enabled. Simply use the EventDocumentFactory. - VetoChange: There's the possibility for listeners to veto a change. If you use events (and listeners which do veto), be prepared to catch the VetoChangeException. - Coding conventions: I tried to use your coding standards. If someone is not happy with anything please comment. - CVS_ID: I like to have in all of my interfaces and classes a constant CVS_ID with the actual version, etc. from cvs. If you don't like it I can remove this, but personally I would preferr to put this into all existing classes, because its so cheap (only some bytes per class-file), has no impact on performace at all, and is in debugging and logging that useful. - Visit event: At the first stage I only implement change events. Afterwards I like to do visit events. Why that's useful ? An example: You use a dom4j tree as data model for a javax.swing.JTable. Lets say you have 100.000 rows in it and the tree comes serialized via RMI from a remote server over a modem connection. Because of the serialization you have to wait till the whole tree is transmitted before you can read the first row (100.000 rows, 100 byte per row, 10MB, ISDN line 8kB/s, ca. 20 minutes), and the badest thing is that most of the data won't ever be read by the user. There are several solutions, but the most elegant would be the following. You divide the rows into chunks, lets say 50 or 100 rows. With the first request the server sends only the first chunk. Register a visit listener at the right place. This listener checks in the readout of any data, whether it's already loaded, if not it pulls the data from the server. In general: Visit events are useful if it's expensive to compute data and propably most of the data is not needed. Any comments are welcome -markus
dom4j-patched-1.3-event.zip
Description: Zip compressed data
begin:vcard n:Bernhardt;Markus tel;cell:0171-5770462 tel;fax:089-420903-20 tel;home:089-6378949 tel;work:089-420903-14 x-mozilla-html:FALSE url:www.swsgmbh.de org:Software Service Wulf Schupp GmbH;Spieljoch adr:;;Spieljochstr. 34;München;;81825;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Entwicklungsleiter note;quoted-printable:[dF]Quisam=0D=0Awww.discordian-Front.de=0D=0AHail Eris !!!=0D=0AHappy Frag !!! fn:Markus Bernhardt end:vcard
