|
Re: EContentAdapter behavior [message #421784 is a reply to message #421783] |
Wed, 13 August 2008 13:46 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Till,
Comments below.
Till Essers wrote:
> Hi
>
> Don't know if this behavior I'm discovering comes from emf or the
> stp.bpmn modeler, so I'm posting in both newsgroups.
>
> I'm using an EContentAdapter to get notified when objects are added or
> removed from the bpmn diagram. It's working fine when adding objects.
> case Notification.ADD:
> Object obj = notification.getNotifier();
> if(obj instanceof NodeImpl)
> if(((NodeImpl)obj).getElement() instanceof Activity)
I don't imagine you should be using Impl classes in your instanceof
tests. Why aren't you using the "Node" API for testing?
>
> As you can see I'm just looking what kind of object has been added to
> the diagram. In this case we have an Activity.
> I'm doing the same on adding SequenceEdge.
> But when it comes to removing objects, I'm pretty curios about those
> objects passed around. When I'm removing a Connection for example, I
> get 2 remove notifications for the objects connected through this
> SequenceEdge, but none for the SequenceEdge itself.
Note that when an object is removed from the tree, the adapter itself is
removed from that object and from all contained children of it. The
REMOVING_ADAPTER notification will occur for those.
> Even though, when deleting a flow object from the diagram, I'm not
> receiving a notification for it.
Note also that notifications about deletion generally happen for the
containment feature of the parent not directly on the deleted object
itself (though the adapter is removed so you can detect that).
> Am I doing anything wrong?
I'm not sure. Hopefully you're calling super in your overrides so that
the normal processing happens as well...
> Or is the removed object not stored in the element?
I'm not sure what happens in this combination of diagram model and
domain model...
> Sorry for asking, but I couldn't find any documentation about the
> notifications passed around.
Generally a notification is fired by an EObject whenever the value of
one of it's features changes...
>
> Thanks in advance
> Till
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Re: EContentAdapter behavior [message #421789 is a reply to message #421788] |
Wed, 13 August 2008 14:50 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Till,
Are you listening to just the diagram resource or also the resource
containing the model? I'm assuming they're in different resources, but
that might be a wrong assumption. It sounds like delete is cleaning up
the node, but I would have imagined you'd have seen a notification that
the node's element was being SET to null...
Till Essers wrote:
> Ed Merks schrieb:
>> Till,
>>
>> Comments below.
>
>> I don't imagine you should be using Impl classes in your instanceof
>> tests. Why aren't you using the "Node" API for testing?
> Sure, changed this one ;)
>
>> Note that when an object is removed from the tree, the adapter itself
>> is removed from that object and from all contained children of it.
>> The REMOVING_ADAPTER notification will occur for those.
> Okay, that may change some things...
>
>> Note also that notifications about deletion generally happen for the
>> containment feature of the parent not directly on the deleted object
>> itself (though the adapter is removed so you can detect that).
> Which would explain why I got a notification telling me to delete the
> task, note the connection.
>
>> I'm not sure. Hopefully you're calling super in your overrides so
>> that the normal processing happens as well...
> Sure, the first call is the super call.
>
>> I'm not sure what happens in this combination of diagram model and
>> domain model...
> I'm absolutly unsure what happens... When the ADD notifier is called,
> I get a Node containing the new object as the element.
> When the REMOVING_ADAPTER notifier is called I get a Node containing
> null as the element.
> I don't know how I should know which object in the diagram is removed.
>
> Is it possible, that the super call sets the element of the node to null?
>
> Thanks so far
> Till
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
Re: EContentAdapter behavior [message #421794 is a reply to message #421792] |
Wed, 13 August 2008 15:33 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Till,
It seems clear you're listening to the diagram and likely not listening
to the underlying domain model at all. Yet probably what you're
interested in are the changes to the actual domain model regardless of
how the diagram might be rendering it or referring to it. I wonder what
kinds of notifications you'll see if you did
editor.getDiagram().getElement().eAdapters().add(adapter) instead...
Till Essers wrote:
> Hi
>
> As I thought... I'm running into trouble again...
> Removing an Activity from the diagram works the way mentioned before.
> Removing a SquenceEdge doesn't work this way. I'm getting pretty mad
> about this, there has to be a way doing it for all those BPMN objects
> the same way.
>
> Thanks
> Till
>
> Till Essers schrieb:
>> Hi
>>
>> Don't know what I am listening to, I just called:
>> editor.getDiagram().eAdapters().add(adapter);
>> to add my EContentAdapter.
>>
>> Ok, I think I've found out what I have to do:
>> I have to listen to the REMOVE notification,
>> then test on the old value, not the notifier. Doing this I can see
>> the element being removed from the node before the adapter is removed
>> from the node.
>> Hopefully it's just called when the element is removed... otherwise I
>> would run into trouble again :D
>>
>> Tricky thing this EContentAdapter...
>>
>> Thanks
>>
>>
>> Ed Merks schrieb:
>>> Till,
>>>
>>> Are you listening to just the diagram resource or also the resource
>>> containing the model? I'm assuming they're in different resources,
>>> but that might be a wrong assumption. It sounds like delete is
>>> cleaning up the node, but I would have imagined you'd have seen a
>>> notification that the node's element was being SET to null...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04159 seconds