Home » Modeling » EMF » [EMF] Notification.REMOVE_MANY not used.
| |
Re: [EMF] Notification.REMOVE_MANY not used. [message #987592 is a reply to message #987558] |
Tue, 27 November 2012 09:48 |
Christophe Bouhier Messages: 937 Registered: July 2009 |
Senior Member |
|
|
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
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 10:30 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [EMF] Notification.REMOVE_MANY not used. [message #987720 is a reply to message #987611] |
Tue, 27 November 2012 18:01 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
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 19:41 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Re: [EMF] Notification.REMOVE_MANY not used. [message #988412 is a reply to message #987734] |
Thu, 29 November 2012 19:46 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
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 05:51 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:55:57 GMT 2024
Powered by FUDForum. Page generated in 0.03794 seconds
|