Eclipse Community Forums: EMF » [EMF] Notification.REMOVE

Home » Modeling » EMF » [EMF] Notification.REMOVE_MANY not used.

[EMF] Notification.REMOVE_MANY not used. [message #987437]

Mon, 26 November 2012 10:48

Eclipse User

Hello,

I noticed the RemoveCommand, when notifying is removing items one by one from a collection. The notification is a Notification.REMOVE for each of the items in the collection of the Remove Command, and this n times matching the size of the collection. I expected a REMOVE_MANY. I also noticed REMOVE_MANY is actually not used the whole EMF framework, besides the validation framework.
Is it wrong to expect a REMOVE_MANY? Why is there, if not used?

thanks Christophe

Re: [EMF] Notification.REMOVE_MANY not used. [message #987558 is a reply to message #987437]

Tue, 27 November 2012 02:25

Eclipse User

Christophe,

If you do a removeAll (see
org.eclipse.emf.common.notify.impl.NotifyingListImpl.removeAll(Collection<?>))
or a clear you'll see a REMOVE_MANY. If you look closely at what
org.eclipse.emf.edit.command.RemoveCommand.doExecute() does, you'll see
it's not so easy to call removeAll in the general case because we need
to be very sure to record the index of each object and delete exactly
the object at that index so we can put it back at that index for an undo.

On 26/11/2012 4:48 PM, Christophe Bouhier wrote:
> Hello,
> I noticed the RemoveCommand, when notifying is removing items one by
> one from a collection. The notification is a Notification.REMOVE for
> each of the items in the collection of the Remove Command, and this n
> times matching the size of the collection. I expected a REMOVE_MANY. I
> also noticed REMOVE_MANY is actually not used the whole EMF framework,
> besides the validation framework. Is it wrong to expect a REMOVE_MANY?
> Why is there, if not used?
> thanks Christophe

Re: [EMF] Notification.REMOVE_MANY not used. [message #987592 is a reply to message #987558]

Tue, 27 November 2012 04:48

Eclipse User

Thanks Ed, I think my IDE setup is broken. Ctrl-Shift-G on REMOVE_MANY, didn't return that reference. Anyway, so looking at the code, "Not easy" seems to be "Not at all"?

 // Remove objects from the owner list by index, starting from the end.
    //
    for (i = indices.length - 1; i >= 0; i--)
    {
      ownerList.remove(indices[i]);
    }

BTW For my usecase, I found a workaround for the "bombardment" of notifications when removing many entries at once, by simply scheduling the following action in a Job with a delay, and re-scheduling when a new notification arrives, but it's not very pretty Confused

I just wonder if it's even possible to get one single notification, and conditions would need to be met. Oh this list is an eContents() list from a CDOResource, not sure that makes any difference.

rgds Christophe

Re: [EMF] Notification.REMOVE_MANY not used. [message #987611 is a reply to message #987592]

Tue, 27 November 2012 05:30

Eclipse User

Christophe,

Comments below.

On 27/11/2012 10:48 AM, Christophe Bouhier wrote:
> Thanks Ed, I think my IDE setup is broken. Ctrl-Shift-G on
> REMOVE_MANY, didn't return that reference.
Constants are generally in-lined and you'll only find uses if you have
the source in your workspace.

I already pointed you to exactly the method where it's used.
> Anyway, so looking at the code, "Not easy" seems to be "Not at all"?
Yes, I pointed this out because the logic for determining exactly which
things to remove is rather complex and involves using == and .equals to
find the indices first (to deal with removing things from a list that
allows duplicates and that uses .equals to compare elements).
> // Remove objects from the owner list by index, starting from the end.
> //
> for (i = indices.length - 1; i >= 0; i--)
> {
> ownerList.remove(indices[i]);
> }
>
>
> BTW For my usecase, I found a workaround for the "bombardment" of
> notifications when removing many entries at once, by simply scheduling
> the following action in a Job with a delay, and re-scheduling when a
> new notification arrives, but it's not very pretty :?
The notifications are generally batched already by
org.eclipse.emf.edit.ui.provider.NotifyChangedToViewerRefresh
> I just wonder if it's even possible to get one single notification,
> and conditions would need to be met. Oh this list is an eContents()
> list from a CDOResource, not sure that makes any difference.
You shouldn't rely on there being just one notification. After all,
many command are composites that do multiple things, e.g., Delete.
> rgds Christophe

Re: [EMF] Notification.REMOVE_MANY not used. [message #987720 is a reply to message #987611]

Tue, 27 November 2012 13:01

Eclipse User

On 27.11.12 02.30, Ed Merks wrote:
> Christophe,
>
>> I just wonder if it's even possible to get one single notification,
>> and conditions would need to be met. Oh this list is an eContents()
>> list from a CDOResource, not sure that makes any difference.
> You shouldn't rely on there being just one notification. After all,
> many command are composites that do multiple things, e.g., Delete.

Finding at what point to update a view (dependent objects, not
necessarily a user interface) based on a sequence of notifications is
something a lot of applications may find problematic. I've several times
wanted to have a flag to set in a Notification to indicate it's the last
one. Another approach is to generate a synthetic notification that does
no harm, but can be identified as the final in a logical sequence. Is
there a practical way of doing something like this?

Hallvard

Re: [EMF] Notification.REMOVE_MANY not used. [message #987734 is a reply to message #987720]

Tue, 27 November 2012 14:41

Eclipse User

Hallvard,

A command stack listener knows when a sequence of related changes are
done. Nothing else knows about "logical sequences".

On 27/11/2012 7:04 PM, Hallvard Trætteberg wrote:
> On 27.11.12 02.30, Ed Merks wrote:
>> Christophe,
>>
>>> I just wonder if it's even possible to get one single notification,
>>> and conditions would need to be met. Oh this list is an eContents()
>>> list from a CDOResource, not sure that makes any difference.
>> You shouldn't rely on there being just one notification. After all,
>> many command are composites that do multiple things, e.g., Delete.
>
> Finding at what point to update a view (dependent objects, not
> necessarily a user interface) based on a sequence of notifications is
> something a lot of applications may find problematic. I've several
> times wanted to have a flag to set in a Notification to indicate it's
> the last one. Another approach is to generate a synthetic notification
> that does no harm, but can be identified as the final in a logical
> sequence. Is there a practical way of doing something like this?
>
> Hallvard
>

Re: [EMF] Notification.REMOVE_MANY not used. [message #987809 is a reply to message #987611]

Wed, 28 November 2012 04:09

Eclipse User

Thanks for pointing out the NotifyChangedToViewerRefresh class.
Just looking at the code, I am not sure this is really treating the notifications as a batch?
There is a viewer.refresh for every eventType Notification.REMOVE...
As I said, I found a solution for my case. BTW, I think it could be of value to others, so I blogged about it:

http://modelmoo.blogspot.nl/2012/11/lazy-loading-cdo-backed-jface-viewer.html

Re: [EMF] Notification.REMOVE_MANY not used. [message #987813 is a reply to message #987809]

Wed, 28 November 2012 04:17

Eclipse User

Christophe,

In this logic

public void notifyChanged(Notification notification)
{
if (viewer != null && viewer.getControl() != null &&
!viewer.getControl().isDisposed())
{
// If the notification is an IViewerNotification, it specifies
how ViewerRefresh should behave. Otherwise fall
// back to NotifyChangedToViewerRefresh, which determines how to
refresh the viewer directly from the model
// notification.
//
if (notification instanceof IViewerNotification)
{
if (viewerRefresh == null)
{
viewerRefresh = new ViewerRefresh(viewer);
}

if
(viewerRefresh.addNotification((IViewerNotification)notification))
{
viewer.getControl().getDisplay().asyncExec(viewerRefresh);
}
}

it's creating a ViewerRefresh that's asynExeced later so any
notifications that come in after that's scheduled and before it's
executed will be merged in the viewerRefresh...

On 28/11/2012 10:09 AM, Christophe Bouhier wrote:
> Thanks for pointing out the NotifyChangedToViewerRefresh class.
> Just looking at the code, I am not sure this is really treating the
> notifications as a batch? There is a viewer.refresh for every
> eventType Notification.REMOVE... As I said, I found a solution for my
> case. BTW, I think it could be of value to others, so I blogged about it:
> http://modelmoo.blogspot.nl/2012/11/lazy-loading-cdo-backed-jface-viewer.html
>
>
>

Re: [EMF] Notification.REMOVE_MANY not used. [message #987826 is a reply to message #987813]

Wed, 28 November 2012 05:14

Eclipse User

ah, that's in the AdapterFactoryContentProvider.
I never looked into this before, but what I realize now is, that if an ItemProvider generates the notification, it will be an IViewerNotification which is decorated with additional info, like label update etc.. So my content provider, would need to adapt an object, to get similar behavior as the AdapterFactoryContentProvider... and also handle the caching. sweet.... EMF is a pattern heaven Smile

Re: [EMF] Notification.REMOVE_MANY not used. [message #988412 is a reply to message #987734]

Thu, 29 November 2012 14:46

Eclipse User

On 27.11.12 11.41, Ed Merks wrote:
> Hallvard,
>
> A command stack listener knows when a sequence of related changes are
> done. Nothing else knows about "logical sequences".

Yes, a solution with commands executed by the command stack of an
editing domain can be used, since the commands encapsulate the "logical
sequences" aka transactions and the command stack event will indicate
the boundary.

I've always used this technique with UIs, since it provides undo/redo
etc. However, I haven't considered it appropriate for transactions in
general, like when updating a model based on data from sensors, where a
set of updates are considered one sample. In such a case you don't need
support for undo/redo, and creating and storing the command objects with
all the undo-data may be resource consuming. But you still need
something similar... Hm, perhaps custom commands (that can be reused)
and some flushing of the stack is all that is needed.

Hallvard

Re: [EMF] Notification.REMOVE_MANY not used. [message #988471 is a reply to message #988412]

Fri, 30 November 2012 00:51

Eclipse User

Hallvard,

Comments below.

On 29/11/2012 8:49 PM, Hallvard Trætteberg wrote:
> On 27.11.12 11.41, Ed Merks wrote:
>> Hallvard,
>>
>> A command stack listener knows when a sequence of related changes are
>> done. Nothing else knows about "logical sequences".
>
> Yes, a solution with commands executed by the command stack of an
> editing domain can be used, since the commands encapsulate the
> "logical sequences" aka transactions and the command stack event will
> indicate the boundary.
>
> I've always used this technique with UIs, since it provides undo/redo
> etc. However, I haven't considered it appropriate for transactions in
> general, like when updating a model based on data from sensors, where
> a set of updates are considered one sample.
Yes, there's no concept of transactions in the EMF core runtime.
> In such a case you don't need support for undo/redo, and creating and
> storing the command objects with all the undo-data may be resource
> consuming.
Yes, it seems pointless to use full blown command when undo isn't needed.
> But you still need something similar... Hm, perhaps custom commands
> (that can be reused) and some flushing of the stack is all that is
> needed.
Commands have useful information, like the affected objects and the
result that might be useful even in this context.

But if there is no UI, I wonder who is using the information and more
importantly what information exactly they need. After all, many objects
can be affected by changes so does each object want/need to get its own
notification indicating "all done for now"?

One might use a change recorder for this type of application and either
process the information in the ChangeRecorder or process the
ChangeDescription it can produce...
>
> Hallvard
>

Previous Topic:	[CDO] Problem with concurrent read and write threads
Next Topic:	[CDO] Install CDO Server in linux

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 19:33:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter