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

[Mike Skells (ebizz-consulting)]

Title: Message

Hi Markus,

The problem is that you have not produced the proxy for the element, so at the moment the child of the element is the proxy, whose data is managed by the proxied defaultAttribute

assuming that you are producing a proxy for the dfeaultElement etc

when you implement the ProxyElement, then I presume that the children will be managed by the defaultElement

but proxyAttribute.getParent() will deligate the parent call to the deafultAttribute which will return the default element in the proxied class

 

similarly the child relationship from the element will be deligated to return the child from the proxied element

The test works OK because there is do graph of proxied nodes accessed by a graph of proxy nodes, just leaf node attributes, which only contain the value and parent

 

I hope that makes sence!

 

###

another JDOM convertee! Does it feel better now you have seen the light? :-)

 

###

With your projects, are the views of the document a pure subset or a general transform ( I have a security proxy in the app that I am doing)

 

I will send you the flier, when it is approved. demos should be on the web in a few weeks with the JSP access, and a couple of weeks later with the swing access client. It is all slipping a bit now, as I have to take a couple of weeks off for another project

 

 

Mike

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Markus Bernhardt
Sent: Wednesday 21 August 2002 12:53
To: Mike Skells (ebizz-consulting); dom4j-dev
Subject: Re: [dom4j-dev] RFC Java-style event system for dom4j

Hi Mike,

I have written a little TestCase for this.
Look at my code, to check, if it does what
you think I should test.

Document document = EventDocumentFactory.getInstance().createDocument();
Element  root = document.addElement( "root" );

Element author1 = root.addElement( "author" );
author1.addAttribute( "name", "James" );
 
Attribute attrib  = author1.attribute("name");
Attribute attrib2 = attrib.getParent().attribute("name");
assertTrue( "attrib  is null", attrib  != null );
assertTrue( "attrib2 is null", attrib2 != null );
assertTrue( "attrib and attrib2 are not the same object", attrib == attrib2 );
assertTrue( "attrib is not a EventFacade as not desired", attrib instanceof EventFacade );

if(attrib == attrib2) {
  System.out.println("attrib and attrib2 are the same object");
}

if(attrib instanceof EventFacade) {
  System.out.println("attrib is a EventFacade as desired");
}

Here comes the result.
    [junit] Running org.dom4j.event.TestAttribute
    [junit] attrib and attrib2 are the same object
    [junit] attrib is a EventFacade as desired

Look's quite ok to me.

####################

Found my Design Pattern book yesterday.
You are right, my classes are proxies and no facades.
I will rename everything.

####################

What I am trying to do with that ?

Well, we have developed our first software production environment written in java 4 years ago. (Btw, the first in COBOL 1972) One part of it is a generic, meta-data driven thin AND fat java-client. It's thin, because it has no business-logic, no icon, no texts or anything project specific in it. It's fat, because after the start of the client it loads the meta-data with all th logic etc in it and it need a big amount of ram and cpu. Mainly we are mainframe guys and cpu-seconds there are expensive, so we put as much logic as possible into the client. At the moment we have round about 1.100 dialog-programs installed at the mainframe, all using the same java-client (and java-server).

Over the years we found several shortcomings of our client and it has become more and more complicated to fix things. Our main problem arises from the Swing DataModels. I like MVC, but having thousands of DataModels over your code is not a good thing and writing a central specialized DataModel is an incredible amount of work (and really a pain in the ...).
We started redesigning our client 1 1/2 year ago and I decided to put all data into a central structure, one XML-tree. The DataModels now are views at nodes of the tree, that's why I need events.

At this time I used jdom beta 5/6. I have written all the event stuff and our prototype really, really rocked. And then ... I ran out of time. We had to stop the prototype for doing some projects. At the moment I'm reviving it again. Because I have some problems with the design of jdom and especially with some of the persons there I switched to dom4j (and because they refused to think about a event system until jdom 1.1. ROFL).

What you are doing at your day-work sound really interessting to me, especially the rule and transaction thing. Do you have a flyer or a demo of it ?

Markus

"Mike Skells (ebizz-consulting)" wrote:

 Hi Markus,The problem is that you are not wraping the return valuesx.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 etcNormal Maps gives problems with the memory usage, but a WeakReference implementation gives garbage collector supportOld 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 nowThe 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
>