[jdom-interest] Re: JDOM events

[philip.nelson at omniresources.com]

I just want to say that I hope you don't think I'm discouraging you from
trying this.  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, 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.

> > 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?

> 
> > 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?  In your application that may be perfect, but it
will almost certainly not be perfect in many cases.

> 
> > 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.  I still have scars on my
forehead from trying to get that idea to work well :-). 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.
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.

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.