[From nobody Fri Aug  6 17:06:39 2004
X-Mozilla-Status2: 00000000
Message-ID: <3B442D74.59E867F4@swsgmbh.de>
Date: Thu, 05 Jul 2001 10:03:48 +0100
From: Markus Bernhardt <mbernhardt@swsgmbh.de>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: philip.nelson@omniresources.com
Subject: Re: [jdom-interest] Re: JDOM events
References: <DF5018B3C986D11196FF0060089A903C36E342@omnigbwww.omniresource.com>
Content-Type: multipart/mixed; boundary="------------682B7DE88EBDBFA18E704B30"

This is a multi-part message in MIME format.
--------------682B7DE88EBDBFA18E704B30
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



philip.nelson@omniresources.com wrote:

> > Could you please point out the kind of problems you encountered
> > trying to build a event system ?
>
> hadn't done it yet, that's why this thread is interesting ;-)
>
> >
> > 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.
>
> the perfect argument for a decorator.  In this case it would be more work
> than a wrapper though but the end result is in your subclass:
>
> public List getContent() {
>         return new ListenableList(super.getContent());
> }

That's the way it looks now in my code.

>
>
> > 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.
>
> putting 50000 elements in a table model probably has more problems than just
> adding listeners and so far I have just tried to avoid the situation
> entirely.  Here are some ideas that could help whether wrappers, decorators
> or jdom subclasses are used  as they all have similar issues with this
> problem.
>
> - add the listeners in your customized JDOMFactory.  If you already know the
> elements that will go with particular listeners, you can skip the xpath
> business altogether and select specific listeners to go with specific nodes.

I only thought about using xpath. Never implemented it fully.
Saw to much problems.

>
>
> - only add listeners to elements currently being displayed and refresh the
> model and nodes with listeners as items come into view. This could be hard!
> It is also appropriate in working with large data sets and many ui controls
> work this way with databases, at least in as much the full set of data is
> not retrieved until needed.

Yes, ok.
My actual TableModel works that way.
It adds only listeners to displayed elements.
It also uses sections which will be loaded independently from the datasource.
(Example: ResultSet 50000 rows, section size 200,
displaying rows 4711-4750 means section 24 has to be loaded)

>
>
> - add a methods that will allow you to walk up the tree until you finds an
> element with a listener and call that.  You may be able to further qualify
> the walk up with specific attributes on certain nodes in your case because
> the document is specific to your app.  So each node by default has a
> "DelegatedListener" instance which can be replaced by a real "Delegatable"
> listener.  The real listener would have to have a way to be called from
> outside the node.  The delegated listener is called whenever the node is
> changed.

Think I have implement this, but thrown away again because its very costly
to walk up the whole tree, throw an event at each node which has a listener,
and calculate in the listener where the event comes from.

>
>
> These are ideas are for discussion only and your mileage may vary :-)
>
> >     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, <snip>
>
> >     I tried to integrate this into the werken.xpath package,
> > but it never
> >     worked stable.
>
> Behind the scenes it would still have to do the first part.  And it will
> never be fast on large documents unless it has some way to index the search.
> String comparisons are costly.

Yes.

> The Werken xpath library is undergoing a
> complete rewrite, by the way.

What are they doing ?

>
>
> >> 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.
> >
> You can put validation code in the wrappers, call it from a wrapper in a
> application specific class and then update the actual element.  With
> threads, *if* you can share the reference to the wrapper, you can simply
> syncronize your own customized methods.  If not, then the wrappers can
> syncronize on the element/attribute instance so long as *all* your code does
> it that way.  In the element/attribute you can't arbitrarily syncronize the
> existing methods in a subclass and would have to add new ones anyway.

Played around with threads and yes, Houston we have a problem.
Havent searched for a solution now.
BTW, Swing isnt thread safe too.

>
>
> Really, I just think the architecture is cleaner this way as both of these
> things could be solved in subclasses.

- markus

--------------682B7DE88EBDBFA18E704B30
Content-Type: text/x-vcard; charset=us-ascii;
 name="mbernhardt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Markus Bernhardt
Content-Disposition: attachment;
 filename="mbernhardt.vcf"

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:mbernhardt@swsgmbh.de
title:Entwicklungsleiter
note;quoted-printable:[dF]Quisam=0D=0Awww.discordian-Front.de=0D=0AHail Eris !!!=0D=0AHappy Frag !!!
fn:Markus Bernhardt
end:vcard

--------------682B7DE88EBDBFA18E704B30--

]