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]
