I forgot to mention here though I mentioned it in private toi Michiel
Take a look at the log.info information whendrawing an association from one class to another and also when editing the name of an assoiation on the prop panel. We really have very excessive adding and removal of listeners. Often just removing in order to add the same ones again. The only time we would want to remove all listeners from a Fig is when that Fig is removed from the diagram. Bob. On 8/10/06, Bob Tarling <[EMAIL PROTECTED]> wrote:
Sorry I didn't comment fully on the implementations of modelChanged in FigTransition vs FigState Certainly FigState is not a good design. We should only be adding removing the specific listeners we need to at any one time. I was never keen on extending PropertyChangeEvent for our model events or the use of PropertyChangeListener to detect them. This has resulted in over complex propertyChange methods all over the place. I'd have preferred to see a specific DeleteInstanceListener, AttributeChangeListener etc, each with their own methods signature, eg modelElementDeleted(DeleteInstanceEvent), attributeChanged(AttributeChangeEvent) We also need simlar for remove/add and possibly even create. In the short term we could add these methods to FigEdgeModelElement and FigNodeModelElement and have propertyChange delegate to each dependant on event type. That would break down your modelChanged method into more managable pieces. I'm suprised to see that you treat AddAssociation and AttributeChange events as the same in FigTransition. Bob. > > On 15/02/06, Michiel van der Wulp <[EMAIL PROTECTED]> wrote: > > > Hi All, > > > > > > Since my last commit, there are now 2 working strategies for the way Figs > > > listen to model changes. > > > > > > See the FigTransition, and the FigState. > > > > > > The FigTransition has only a modelChanged function, that interpretes every > > > event, and adds and removes the minimal number of listeners consequently. > > > > > > The FigState has a simple modelChanged function, that calls updateListeners > > > to simply remove all listeners, and create new ones, for all modelelements > > > that may influence the Fig. > > > > > > If you have any preference for one strategy, let me know. > > > > > > For me, the FigTransition method has the advantage that it is exactly the > > > required minimum of events registration, and the FigState method has the > > > advantage that the code to update the listeners may be moved into the > > > notationProvider, which has the knowledge of what to display. > > > > > > Explanation of this latter point: Why does the state listen to the value of > > > the argument of its entry-action? Because it is generated in the notation of > > > its body, in the StateBodyNotationUml class. For another notation language, > > > we may need to listen to other modelelements... So, it seems logical, that > > > the StateBodyNotationUml determines what to listen to. > > > > > > Regards, > > > Michiel > > > > > > > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.1.375 / Virus Database: 267.15.9/261 - Release Date: 15/02/2006 > > > > > > > > > --------------------------------------------------------------------- > > > 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]
