[jdom-interest] Re: JDOM events

[Markus Bernhardt]

philip.nelson at omniresources.com wrote:

> I just want to say that I hope you don't think I'm discouraging you from
> trying this.

Didn't thought that.
Had you time to look at my implementation ?

> There's only a few left that may remember that when I first
> appeared on this list, adding listeners was one of my primary motivations.
> This was based on less than optimal experiences with other api's that tried
> it and didn't get it quite right,

Could you please point out the kind of problems you encountered
trying to build a event system ?

At the moment I have 'only' two problems:
1. FilterList
    FilterList is final so I can't subclass it, and the Filter interface
    is to narrow to fire events.
2. Design decision: Do bubbling ???
    The decision is: Having a hierarchic or a delegation type event system.
    Have both ? There are pros and cons on both types.
    At the moment I have implemeneted delegation type events.
    A listener has to register itself at each element, attribute, etc. to
    get notified of changes of THIS object. The listener will NOT be
    notified of any changes in child or parent objects.
    But there are some use cases where a hierarchic type would rock.
    Example:
        You have table style data:
            <data>
                <row .../>
                <row .../>
                <row .../>
            </data>
        Let' say 1000 rows, 50 columns.
        Now I want to show this data in a JTable via a TableModel.
        That means I have to navigate through 50000 objects and
        call addJDOMListener. There are some optimizations possible,
        but it's simply ugly.
    Registring at an element with xpath would be nice.
    Something like: data.addJDOMListener(listener, "./row/*").
    I have also implemented that stuff, but the performance is terrible
    poor, because of one big problem. All to me known xpath implementations
    are of the type: Take a start node and find the result nodes.
    So I get a list of objects and have to scroll through the list, to find
    (perhaps) the object which fired the event.
    What I need is a xpath implementation which can do something like:
    Is this object part of the result of this xpath applied to this object ?
    I tried to integrate this into the werken.xpath package, but it never
    worked stable.

> like ibm's XML Master (at the time) and on
> a note similar to what you seem to be doing, an xml based swing builder,
> Bluestone's XSwing and yet another presented by <I don't remember his name>
> at SDExpo a couple of years ago.

I don't know XML Master very much and XSwing at all. But I think it's not
what we are doing.

>
>
> > > create listeners and add them to the tree at build time
> >
> > why ?
>
> Aren't you approaching this so that a modification to the xml document fires
> an event?  Doesn't something have to be listening to the event even if it is
> the document itself?

ok. Right.

>
>
> >
> > > extract the info needed for models
> >
> > > build and set models
> >
> > no. the tree is used as model.
>
> So you will always have a one to one relationship between each part of your
> xml document and the model?

Yes and no. My document is much larger than one model.
I have TableModels, TreeModels, ListSelectionModels, TableColumnModels,....
represented by different trees in my document. And naturally there is
data not represented in a model.

> In your application that may be perfect, but it
> will almost certainly not be perfect in many cases.

Sure.

>
>
> >
> > > handle events
> >
> > already done
>
> see above
>
> > Question: How do you handle the 'other' direction ?
> > Somebody creates a new Element and adds it to your tree. And then ?
> > In your solution I have to use a reference to the model to do
> > programatic changes.
> > That's no option for me.
>
> I don't know what you are trying to do exactly but it sounds like what you
> basically want is a data bound ui control.

META-data bound ui control is one part of my problem.

> I still have scars on my
> forehead from trying to get that idea to work well :-).

Works quite well at the moment.

> It puts lot's of
> additional requirements on the XML document which by it's nature, already
> has a lot to do.  To me, a swing model should be maintained by an
> application which in turn gets it's information from some data source.

I don't have one application. I am building a software production environment.
A redesign of our 3 year old framework. We produced about 450 applications
for 12 major projects with this environment. There is almost no application specific
code. Everything is stored in metadata.
We have a generic client, which works like you have written.
Swing models created and maintained by the client application based on
meta data (not xml in our old client, but I think that don't matters).
After 3 years this has lead into complete chaos.
That's why we try somthing new (for us).
Write a client with only one central (xml) document.
Everything has to be stored in it. Perhaps it works. We'll see.

>
> These are all separate issues.  In your case it may be fine because the data
> is for the gui but in general, this is not the case.  With this sort of
> binding you have other problems as well: validation, threads come to mind.

Why you dont have this problems with wrappers ?
The problems are not that obvios, but they are still there.

>
>
> with a wrapper, handling an insertion probably would work pretty much like
> it does in your case.  I have a selected node, the user clicks an insert
> button, I call the insert method on my node which updates the model
> intrinsically because it's in the model and adds the element to the
> document.
>
> >
> > I am not writing an application to just show and modify a jdom tree,
> > but a client with trees, buttons, tables, comboboxes and ONE central
> > jdom tree.
> > If a command for example adds the following element
> >     <gui type="frame" size="max;600" location="center;center"
> > visible="true" />
> > to my guimanager element a new JFrame will open immediatly.
> > Remove the element and the frame is history.
> > (That's working already !!)
>
> :-)
>
> > I think its worth to have a set of event enabled subclasses.
>
> I guess at this point I'm more interested in a clear idea about how to
> support swing gui's with jdom documents.  An event enabled subclass is
> certainly on the top ten requests list.  Having to watch every constructor
> and and every possible list implementation for changes looks pretty hard.
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

- markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mbernhardt.vcf
Type: text/x-vcard
Size: 459 bytes
Desc: Card for Markus Bernhardt
Url : http://jdom.org/pipermail/jdom-interest/attachments/20010702/ab36ba57/mbernhardt.vcf