There are a lot of issues in this.
My important point is that we should, whenever using registration for the
Observer, Publisher-Subscriber patterns, or with PropertyChangeEvents, use
WeakReferences to avoid having old observers, subscribers, and listeners
hanging around forever. This gives a design that handles bugs with forgotten
unregistration gracefully. I assume this change could be done without any
problems and don't understand how the problems seen with issue 2407 are
related to this.
I think the problem in issue 2407 was managing the registering and
unregistering of listeners. Those areas are complicated to get right. This,
in turn, is because the model part of the figure is entangled with the view
part. Your comment in the issue on using temporary pgml files illustrates
this. Instead I would like to see a separation between the model part of the
diagram (data structure for what figures appear, position, size, and how
they are configured, fonts, colors, ...) possibly managed by MDR using the
UML2 diagram profile, and the GUI part (everything that contains references
to GEF (any of them) and awt, swing, swt). The GUI part need only be created
for the currently showing diagram(s). The model part, will have to be
registered and receive events but those events need not affect the GUI
components if that diagram is not showing. Also Critics should work against
the model level of this and never affect the GUI part.
/Linus
2008/5/17, Bob Tarling <[EMAIL PROTECTED]>:
>
> > 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]
>
>
