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]
