Re: [argouml-dev] Managing delete events from EUML

Hello!

Why do we have Delete events instead of Remove events? When I consider this,
I think there is a difference in how we think about the use of events.

For things that shows a small part of the model (a diagram, a property
panel) it is the Remove event that is interesting. It doesn't care if they
get a Remove or Delete event if something is deleted. I think it is
preferable to get a Remove followed by an Add event to a much more complex
Move/Change event when something is moved.

For things that monitor the entire model for changes (target manager,
critics?) the Delete event is the interesting one.

If I understand correctly your alternative C means that the Remove events
will not be sent in the Move/Change case so it will rely on a Namespace
change event instead. This feels like a good solution but I would put your
judgement ahead of my own in this.

        /Linus


2011/5/23 Bob Tarling <[email protected]>

> 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]]
>

------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2795030

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]]