I need to deal with a model element and Fig that I'm more familiar with. I'll have a go at tidying up FigAssociations event handling and listener management.
On 8/10/06, Michiel van der Wulp <[EMAIL PROTECTED]> wrote:
Hi Bob, et al., Some other advantages and disadvantages of both methods, i.e. the FigTransition versus the FigState: - Adding and removing listeners is a cheap operation AFAIK. Isn't it? (1) - Traversing the model is to determine the complete set of listeners consumes some processor time, but since it is only a query, it is not that bad. (2) - The FigTransition code is currently incomplete, since it lacks the code to set the correct listeners when a project is loaded. Yes, we need code to set a particular listener at least twice, i.e. once for loading a complete modelelement, and once for when some detail in the model changes. - The FigTransition code needs, for every possible different modelchange that influences the drawing of the Fig, a complete scan of the possibly altered part of the model. - The FigState only has one function, that removes all listeners, and re-creates the ones needed. Yes, i agree with this in principle: >> Certainly FigState is not a good design. >> >> We should only be adding removing the specific listeners we need to at >> any one time. ...but it leads to highly complex code. Hence we (I?) decided to go for the FigState solution ever since. PS: (1) Is it really cheap? Can we improve? (2) Can we maybe buffer part of the model to reduce querying the model? Regards, Michiel ----- Original Message ----- From: "Bob Tarling" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, August 10, 2006 8:34 PM Subject: Re: [argouml-dev] How do Figs listen to model changes >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] > > > > -- > 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.8/415 - Release Date: 9/08/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]
