Issue http://argouml.tigris.org/issues/show_bug.cgi?id=6289 explains
the problem and the effect in ArgoUML.
There are 3 ways I see of resolving this.
A) Change Figs so that they not only listen for delete events of their
model element owner but they also listen for delete events of their
namespace and their namespaces namespace etc.
So if anything up from the element to the root is delete the Fig will delete.
B) At the point in the EUML event pump where the DeleteInstanceEvent
event is generated (within fireEvent of ModelEventPumlEUMLImpl) we
should iterate through all child elements (and children of children
repeatedly) creating and firing a delete event for each of those.
C) For this I'll try and explain how delete/remove is managed in our
EUML event pump.
There appears to be no such thing in EMF as a delete event. There is
only a remove event (Notification.remove) fired when a model element
is removed from its parent.
For some instances it is enough for us to assume that when an element
is removed it is being deleted. For example when an attribute is
removed from its class we can assume it is actually being deleted and
fire a delete event.
We have a problem though when trying to drag a class from one package
to another. This will fire a remove event when it is removed from the
first package, resulting in a delete event and so the FigClass being
removed from the diagram.
In order to work around this problem there are certain activiities
that can tell the event pump to not fire a delete event temporarily
for a certain model element. When a class is having its namespace
changed it adds itself to the list of items in the event pump that
should be ignored for delete events. The event pump then checks this
list before firing an event (as shown below)
if (isDeleteEventRequired(oldValue)) {
// Changing of a property can result in the property
// being removed and added again (eclipse behaviour)
// we don't want to mistake this for deletion of the
// property. See issue 5853
events.add(new EventAndListeners(
new DeleteInstanceEvent(
oldValue,
"remove", //$NON-NLS-1$
null, null, null),
getListeners(
oldValue)));
} else {
LOG.info("Not sending delete event - assume
remove"); //$NON-NLS-1$
}
As I'm testing I'm adding more places where we need to add items to
this list and to me it has rather a nasty smell about it. This started
as a small hack for a single case but is now used more and more.
The alternative is to remove this code in the pump that generates
delete events from remove events. Instead the delete method of
UmlFactoryEUMLImpl should make the event pump generate delete events
for the model element being deleted. It should also cascade through
any child model elements asking the pump to generate delete events for
those.
My sense of code smell suggests that (C) is the best approach but I'd
be interested in opinions and alternative suggestions.
Cheers
Bob
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2745916
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
