Hi Markus,
General point.
Just a small questions. Does the system that you propose cope with th
stardard dom4j API
Typically the problem with use of the fascade is that
<root x="1" y="2"/>
Attribute x = ... fascade to attribute x
Attribute x2 = x.getParent.attribute("x");
does x == y, I don't think so from looking at the code.
This means that the fascade does not cover access as the hidden elements
can become visible
The above is fixable by using a weak map.
There was a discussion thread about varios implementation mechnaisms for
adding facilities such as the above to dom4j
(The one that I favored, and still am progressing is by the use of a
Proxy and InvocationHandler)
BTW. It this not a proxy? A Fascade should cover as number of
interfaces, typically as subsystem, whereas a proxy covers one only
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> Markus Bernhardt
> Sent: Friday 16 August 2002 10:48
> To: dom4j-dev
> Subject: [dom4j-dev] RFC Java-style event system for dom4j
>
>
> 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
>
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dom4j-dev
