Home » Modeling » EMF » temporarily disable notifications
| temporarily disable notifications [message #1145453] |
Sat, 19 October 2013 10:27  |
Eclipse User |
|
|
|
Hi
I need to temporarily disable notifications on a specific EObject while
it is being edited (because the editing must be cancellable). I managed
to achieve that with
EObject.eSetDeliver(true|false);
Then, if the editing is accepted, I'd like to notifiy all the adapters.
At the moment, I'm triggering a ViewerNotification manually, but that
does not work in some cases (because I do not know all the features that
have been edited).
I was thinking about the possible alternative solution
- remove all the adapters and save them
- add a custom adapter that caches all the notifications
- when the editing has finished reinsert all the previous adapters
- if the editing was accepted fire all the cached notifications
would that be feasible? Or is there a better approach?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
|
|
| |
| Re: temporarily disable notifications [message #1148360 is a reply to message #1147003] |
Mon, 21 October 2013 08:53  |
| Eclipse User |
|
|
|
Hi, Ed, Lorenzo,
Indeed, the Transaction component (or is it called a project now?)
provides for rollback of a group of changes (the transaction) either
automatically from live validation or explicitly. However, it doesn't
interfere with the delivery of notifications: adapters on your
EObjects will be notified of both the original changes and the
reversion when rolled back.
However, there is provision for listeners that will receive all of the
notifications produced by a transaction in batch after it commits, and
only if it commits, not if it is rolled back. That is typically the
mechanism by which UI updates are initiated.
cW
On 2013-10-20 15:19:56 +0000, Ed Merks said:
> Lorenzo,
>
> Comments below.
>
> On 19/10/2013 4:27 PM, Lorenzo Bettini wrote:
>> Hi
>>
>> I need to temporarily disable notifications on a specific EObject while
>> it is being edited (because the editing must be cancellable).
> Hmmm....
>> I managed
>> to achieve that with
>>
>> EObject.eSetDeliver(true|false);
>>
>> Then, if the editing is accepted, I'd like to notifiy all the adapters.
>>
>> At the moment, I'm triggering a ViewerNotification manually, but that
>> does not work in some cases (because I do not know all the features that
>> have been edited).
>>
>> I was thinking about the possible alternative solution
>>
>> - remove all the adapters and save them
>> - add a custom adapter that caches all the notifications
>> - when the editing has finished reinsert all the previous adapters
>> - if the editing was accepted fire all the cached notifications
>>
>> would that be feasible? Or is there a better approach?
> The transaction framework has support for this type of thing...
>>
>> thanks in advance
>> Lorenzo
|
|
|
| Re: temporarily disable notifications [message #1232104 is a reply to message #1148360] |
Thu, 16 January 2014 03:47 |
| Eclipse User |
|
|
|
On 21/10/2013 14:53, Christian W. Damus wrote:
> Hi, Ed, Lorenzo,
>
> Indeed, the Transaction component (or is it called a project now?)
> provides for rollback of a group of changes (the transaction) either
> automatically from live validation or explicitly. However, it doesn't
> interfere with the delivery of notifications: adapters on your EObjects
> will be notified of both the original changes and the reversion when
> rolled back.
>
> However, there is provision for listeners that will receive all of the
> notifications produced by a transaction in batch after it commits, and
> only if it commits, not if it is rolled back. That is typically the
> mechanism by which UI updates are initiated.
>
> cW
>
>
> On 2013-10-20 15:19:56 +0000, Ed Merks said:
>
>> Lorenzo,
>>
>> Comments below.
>>
>> On 19/10/2013 4:27 PM, Lorenzo Bettini wrote:
>>> Hi
>>>
>>> I need to temporarily disable notifications on a specific EObject while
>>> it is being edited (because the editing must be cancellable).
>> Hmmm....
>>> I managed
>>> to achieve that with
>>>
>>> EObject.eSetDeliver(true|false);
>>>
>>> Then, if the editing is accepted, I'd like to notifiy all the adapters.
>>>
>>> At the moment, I'm triggering a ViewerNotification manually, but that
>>> does not work in some cases (because I do not know all the features that
>>> have been edited).
>>>
>>> I was thinking about the possible alternative solution
>>>
>>> - remove all the adapters and save them
>>> - add a custom adapter that caches all the notifications
>>> - when the editing has finished reinsert all the previous adapters
>>> - if the editing was accepted fire all the cached notifications
>>>
>>> would that be feasible? Or is there a better approach?
>> The transaction framework has support for this type of thing...
>>>
>>> thanks in advance
>>> Lorenzo
>
>
Hi
sorry for the long delay :)
I then managed to implement the buffering of notifications like this
http://git.eclipse.org/c/emf-parsley/org.eclipse.emf-parsley.git/tree/plugins/org.eclipse.emf.parsley.common/src/org/eclipse/emf/parsley/edit/NotificationBuffer.java?id=fc480682cc041dfe9ce3d34a5edef6db085e9ede
I only had a quick look at the transaction framework but it looked quite
complex for what I had in mind.
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
|
|
|
Goto Forum:
Current Time: Wed Jul 23 13:48:56 EDT 2025
Powered by FUDForum. Page generated in 0.04593 seconds |
Home