Hi Bob,
Finally, I found some time to study the changes you did.
I am still confused about:
1. in FigAssociation, I find a "private FigText srcMult;" and in
FigAssociationEnd, I also find a "private FigText srcMult;", which is now
the correct one?
2. I get warnings when changing the multiplicity/ordering/isNavigable of an
association:
WARN: Got an event with a property we're not registered for
multiplicity (FigAssociation.java:288)
WARN: Got an event with a property we're not registered for ordering
(FigAssociation.java:288)
WARN: Got an event with a property we're not registered for
isNavigable (FigAssociation.java:288)
3. Did you plan on having the FigMultiplicity listen to the "multiplicity"
event?
Regards,
Michiel
----- Original Message -----
From: "Bob Tarling" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 11, 2006 7:55 PM
Subject: Re: [argouml-dev] How do Figs listen to model changes
I've commited a version of FigAssociation that no longer registers and
deregisters itself as a listener.
This uses a technique I previously suggested of having composite parts
of the fig register seperately for events that they're interested in.
I first mentioned this for FigStereotype which I shall tackle soon.
I also split out the event types further in FigEdgeModelElement
(although I'd still prefer seperate listeners).
There's more to do here to tidy up. There is quite some duplicate code
that could possibly be move to FigSingleLinetext.
I think methods such as renderingChanged and updateListeners should be
deprecated. We don't want to leave people the temptation of redrawing
everything just because one thing has changed and we don't want the
constant reregistering of all listeners.
Bob.
On 8/11/06, Tom Morris <[EMAIL PROTECTED]> wrote:
> > More importantly, removing the listeners in an
> > unsynchronized fashion, as is currently done, opens a window for
> > events to be lost during the period in which no listeners are
> > registered.
>
> Yes, that is a potential problem.
> This problem may occur if the model changes when registering
> listeners again, not when removing.
Actually the change may already have occurred and have an event queued to
be
delivered. Model changes and listener registration/deregistration happen
in
a different, unsynchronized time domain from event delivery. (ie
different
threads)
> > For #2,
> > is it more complex than adding a listener when we receive
> an relevant
> > AddAssociation event and removing a listener when we receive a
> > RemoveAssociation event?
>
> Yes, you also have to register the listener in the first
> place, i.e. on load of the project.
> If you add something, then you mayhave to add a lot of other
> listeners, too. And if you remove e.g. the operation of a
> class, then you also have to
> remove the listeners to the operation's parameters & stereotypes.
Doesn't this decompose in a hierarchical fashion? When you first place a
Class on a diagram, you get a list of all the Operations and for each one
do
addOperationListeners() or something similar which knows about adding
listeners for Parameters, Stereotypes, and whatever else is appropriate.
When you get an AddAssociation event for the association 'feature', you
invoke the same method which does all the same stuff. Removing an
association or removing the entire Class from the diagram works similarly
in
reverse.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.8/415 - Release Date: 9/08/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 15/08/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
