FW: [dom4j-dev] RFC Java-style event system for dom4j

Tue, 20 Aug 2002 03:15:58 -0700

Title: Message
oops forgot to copy this to the list
-----Original Message-----
From: Mike Skells (ebizz-consulting) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday 20 August 2002 10:12
To: 'Markus Bernhardt'
Subject: RE: [dom4j-dev] RFC Java-style event system for dom4j

Hi Markus,
The problem is that you are not wraping the return values
x.getParent retuns the parent object that is hidden by the fascade/proxy, similarly for the XPath etc
 
<codeSnippit>
   
    public Document getDocument() {
        return node.getDocument();
    }
   
    public Element getParent() {
        return node.getParent();
    }
</codeSnippit>
from the above node.getParent() returns the hidden parent etc.
 
A weak map- >
Sorry, what I mean is that you need a mapper that can map all of the hidden elements to the fascade elements. This will need to cover the collections, maps and nodes. I have some classes I use in my day job, not open source that do this using Weak References ( java.lang.ref.WeakReference) in a map.
The functionality is similar to that of a java.util.WeakHashMap so that I can recover the the fascaded object from the hidden object, for (most) objects. Clearly you dont need to do this for objects that hav no mechanism to access hidden objects e.g. String etc
Normal Maps gives problems with the memory usage, but a WeakReference implementation gives garbage collector support
 
Old discussions ->
I am trying to ressurect this with James as a general purpose mechanism. I will send you an update when I have pried him with beer and convinced him.
The discussions were about a year ago. I will see if I have some archive copy to sent to you.
 
ContentListFacade ->
Yes you are right! It does fascade the add and remove on the node but really it is just a proxy (
 
----------------
On a more general node (if you can tell me), what are trying to do with dom4j extension.
I ask partly because I am in the process of writing an extension library (commercially, as part of my day job) that has transactional support, events, role based security, and support so that rules may have feedback, so that a property veto listener can modify other parts of a document, and should something get vetoed then all of the changes can be rolled back to the state at the initial action, which does not occur with standard veto support. There are related projects for the storage in JDBC/EJB and UI display in swing / JSP if that is of any interest. The dom4j bit is just entering test now
The project is to support process management, but the underly toolsets is just DOM4j documents that are 'active' in that any access is checked, any read can be formatted/localised, and any change can be vetoed, or have feedback.
 
 
Mike
 
-----Original Message-----
From: Markus Bernhardt [mailto:[EMAIL PROTECTED]]
Sent: Tuesday 20 August 2002 03:22
To: Mike Skells (ebizz-consulting); dom4j-dev
Subject: Re: [dom4j-dev] RFC Java-style event system for dom4j

Hi Mike,

thanks for your response.

"Mike Skells (ebizz-consulting)" wrote:

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.

I think it will be ok, if the Instances have been created by the
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.
 
 

 
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.
If it's not ok, whats a weak map ?
 

There was a discussion thread about varios implementation mechnaisms for
adding facilities such as the above to dom4j

Do you know the month or topic to look for in the archives.
 

(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

Well, I simply don't know. Can't find my E. Gamma at the moment. But there's already the
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
>

Reply via email to