thanks for your response.
"Mike Skells (ebizz-consulting)" wrote:
Hi Markus,I think it will be ok, if the Instances have been created by theGeneral point.
Just a small questions. Does the system that you propose cope with th
stardard dom4j APITypically 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.
EventDocumentFactory or any other UserDocumentFactory, which
encapsulates the instances inside the facades.
If you do the following:
Element root = document.addElement( "root" );
Attribute x = root.addAttribute( "x", "4711" );
Then you have:
ElementEventFacade(hides Element)
|---> AttributeEventFacade(hides Attribute)
If you do:
Attribute x2 = x.getParent.attribute("x");
Then x2 == x
Yes, I think so.
It's 4 o'clock in the morning here, so I'm not completely sure.
I will write a Testcase tomorrow.
If it's not ok, whats a weak map ?
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.
Do you know the month or topic to look for in the archives.There was a discussion thread about varios implementation mechnaisms for
adding facilities such as the above to dom4j
Well, I simply don't know. Can't find my E. Gamma at the moment. But there's already the(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
org.dom4j.tree.ContentListFacade which is then a proxy too, or ?
- markus
> -----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
>
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
