Home » Modeling » EMF » Propagating events up through containers
| Propagating events up through containers [message #392343] |
Fri, 15 April 2005 02:34  |
Eclipse User |
|
|
|
Hi,
I have recently translated a hand-coded model into EMF and have had
great success generating edit/editor code and started building a
GEF-based editor. The original code generated PropertyChangeEvents,
based on the JavaBean conventions, but in addition to notifying its
own listeners, an object also notified its containers, which again
notified its listeners. Hence, it was possible to listen to the root
of a hierarchy for all changes within the hierarchy, instead of having
to listen to every single object inside. This was very useful and made
interesting things possible, e.g. I implemented a kind of undoable
transaction, by listening to the root and collecting all events within
the transaction.
I think it should be fairly easy to change the templates for generated
EObjects to do this, but I wanted to ask first, if this has been done,
if there are pitfalls and if there perhaps is a generic Command
implementation anywere, that is able to collect events and undo/redo
them.
If not and I manage to do it myself, I will of course contribute the
code if there is interest.
Hallvard
|
|
|
| Re: Propagating events up through containers [message #392345 is a reply to message #392343] |
Fri, 15 April 2005 07:14  |
| Eclipse User |
|
|
|
Hallvard,
An EContentAdapter serves much the same purpose. You attach it at a
root object, e.g., a resource set, resource, or EObject, and it attached
itself to all objects in the containment tree. It also listens to
notifications so that it detaches and attaches itself as the content
tree changes. In this way, the one adapter instance receives
notification from all nodes in the tree.
EMF also has a change model that uses a change recorder based on the
above to record changes made to your model so that they can be rolled
back. One might use this in a wizard to undo the changes should the
user hit cancel...
I don't think it's a good idea, in general, to have objects, dispatch
notifications from other objects. There's a lot of listener code that
will assume the notification it gets from an object will be with respect
to direct changes on the object and will often cast the notifier of the
notification to the expected type...
Hallvard Trætteberg wrote:
>Hi,
>
>I have recently translated a hand-coded model into EMF and have had
>great success generating edit/editor code and started building a
>GEF-based editor. The original code generated PropertyChangeEvents,
>based on the JavaBean conventions, but in addition to notifying its
>own listeners, an object also notified its containers, which again
>notified its listeners. Hence, it was possible to listen to the root
>of a hierarchy for all changes within the hierarchy, instead of having
>to listen to every single object inside. This was very useful and made
>interesting things possible, e.g. I implemented a kind of undoable
>transaction, by listening to the root and collecting all events within
>the transaction.
>
>I think it should be fairly easy to change the templates for generated
>EObjects to do this, but I wanted to ask first, if this has been done,
>if there are pitfalls and if there perhaps is a generic Command
>implementation anywere, that is able to collect events and undo/redo
>them.
>
>If not and I manage to do it myself, I will of course contribute the
>code if there is interest.
>
>Hallvard
>
>
>
|
|
|
| Re: Propagating events up through containers [message #392347 is a reply to message #392345] |
Fri, 15 April 2005 07:40 |
| Eclipse User |
|
|
|
Ed,
I didn't know of EContentAdapter, thanks for the information. The idea
of propagating events up the containment hierarchy and firing from
other objects worked well for me, but I understand that it may violate
assumptions in general. Using EContentAdapter sounds better, although
it may not be as efficient as my specialised solution. In any case, I
expect EContentAdapter to be efficiency enough.
Do you think it's a good idea to use the change recorder to implement
a generic undo mechanism? Could you provide the names of relevant
classes to look at?
Hallvard
On Fri, 15 Apr 2005 07:14:21 -0400, Ed Merks <merks@ca.ibm.com> wrote:
>Hallvard,
>
>An EContentAdapter serves much the same purpose. You attach it at a
>root object, e.g., a resource set, resource, or EObject, and it attached
>itself to all objects in the containment tree. It also listens to
>notifications so that it detaches and attaches itself as the content
>tree changes. In this way, the one adapter instance receives
>notification from all nodes in the tree.
>
>EMF also has a change model that uses a change recorder based on the
>above to record changes made to your model so that they can be rolled
>back. One might use this in a wizard to undo the changes should the
>user hit cancel...
>
>I don't think it's a good idea, in general, to have objects, dispatch
>notifications from other objects. There's a lot of listener code that
>will assume the notification it gets from an object will be with respect
>to direct changes on the object and will often cast the notifier of the
>notification to the expected type...
>
>
>Hallvard Trætteberg wrote:
>
>>Hi,
>>
>>I have recently translated a hand-coded model into EMF and have had
>>great success generating edit/editor code and started building a
>>GEF-based editor. The original code generated PropertyChangeEvents,
>>based on the JavaBean conventions, but in addition to notifying its
>>own listeners, an object also notified its containers, which again
>>notified its listeners. Hence, it was possible to listen to the root
>>of a hierarchy for all changes within the hierarchy, instead of having
>>to listen to every single object inside. This was very useful and made
>>interesting things possible, e.g. I implemented a kind of undoable
>>transaction, by listening to the root and collecting all events within
>>the transaction.
>>
>>I think it should be fairly easy to change the templates for generated
>>EObjects to do this, but I wanted to ask first, if this has been done,
>>if there are pitfalls and if there perhaps is a generic Command
>>implementation anywere, that is able to collect events and undo/redo
>>them.
>>
>>If not and I manage to do it myself, I will of course contribute the
>>code if there is interest.
>>
>>Hallvard
>>
>>
>>
|
|
|
| Re: Propagating events up through containers [message #392348 is a reply to message #392347] |
Fri, 15 April 2005 08:01 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------050100070305080209080205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hallvard,
You can use org.eclipse.emf.ecore.change.util.ChangeRecorder to record
changes and it has summarize and endRecording methods that return a
ChangeDescription, which in turn has apply and applyAndReverse methods
for undoing the changes. There are examples in the
org.eclipse.emf.test.core plugin in the org.eclipse.emf.test.core.change
package.
Hallvard Tr
|
|
|
Goto Forum:
Current Time: Mon Aug 18 01:15:49 EDT 2025
Powered by FUDForum. Page generated in 0.26134 seconds |
Home