> You say "a system with say 3000 FigAttributes". I would prefer if we would > say "a Diagram with say 3000 FigAttributes" to start thinking that we don't > really need to have Fig objects, Notation objects, etc. created and > receiving events for not showing Diagrams. They could be created when that > Diagram is selected for display and forgotten about and collected by the > garbage collector, when the Diagram is no longer displayed.
I think this is something that should be solved later and separate from this. Lets get a stable mechanism first before adapting for the above - however do check my comment on http://argouml.tigris.org/issues/show_bug.cgi?id=2407 and that can be discussed further there. The last time somebody tried to do the above we had various bugs introduced. > The Observer, Publisher-Subscriber, or PropertyChangeEvents are the natural > patterns to use for this. To allow the Garbage collector to collect the > Notation objects when dropping diagrams, erasing models, etc., some > special considerations are required. I notice that there is already a lot of > code handling the removal (removeFromDiagramImpl(), and > notationProvide.cleanListener(...)) so this is probably solved in another > way. I think the java event mechansim is fine. Once there are no reference to the Fig and the Fig is the only listener to a notation then they should both be GC'd. But I don't like the use of PropertyChangeEvent as was done in the model interface. Rather I think we should use very specific event classes and listener interfaces. At the moment FigNodeModelElement listens for PropertyChangeEvents and then has to deduce where they came from to call some other method to manage them. Better I think to have called the correct listener method in the first place where that method can also make assumptions on what thread the event came from. Even with the model events I'd have preferred to have different listeners for delete events, add/remove events etc. However, that's a diversion to this topic. > Why would MDR and eUML have different Notations? It would probably rather be > that cpp, csharp, idl, java, had different notations without being aware of > the different model implementations. Yes, you are right, I was thinking there may be some difference in notation between UML1.4 and UML2 but without actually checking. Looking back at a conversation with Michiel it is actually the NotationProvider that could be provided by the model depending on implementation but we should check if there is really a need for this. I hesitate to suggested adding threading with the existing problems we have but we could also consider having notations run in there own thread. I think this idea may originally come also from an old conversation with Michiel that has remained in the back of my head. Take as an example is the user edited an operation on the diagram changing its name and adding 2 operations to it. That would result in the notation subsystem receiving several events and for each would rebuild the notation and fire an event to the Fig (or whatever else is listening). It would be nice if such a complex notation could pause for some fraction of a second to see if another model event comes in before acting on the first. Bob. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
