| Proper way to update UI from EContentAdapter [message #1011970] |
Wed, 20 February 2013 11:04  |
Eclipse User |
|
|
|
I have an econtent adapter that is essentially causing the refresh of numerous tables. While it is theoretically possible to filter all notifications down to the exact notifications that should cause a refresh on the tables, it would be extraordinarily difficult and time-consuming as we have a massive model, and many different events and changes that could possibly trigger a refresh. Also, what often happens is a single "user-event" (like clicking state->new in our application), triggers 4 objects being created behind the scenes, all of which look very similar from the notification standpoint and therefore makes it difficult to filter out. I'm wondering if there is a good way to do some sort of "delayed job" so that the 4 notifications only cause a single refresh. For example, something similar to:
public void notifyChanged(final Notification notification)
super.notifyChanged(notification);
@Override
public void run() {
if(matchesFilters(notification)) {
//some sort of check to see if we recently had another event that would have triggered a refresh?
if(!schedulingJob) {
scheduleDelayedJob();
}
}
}
}
Unfortunately I have little experience in jobs and things like that, so it would be very helpful if someone could give assistance in what the proper way of doing this is.
|
|
|
|
| Re: Proper way to update UI from EContentAdapter [message #1011978 is a reply to message #1011970] |
Wed, 20 February 2013 11:11  |
| Eclipse User |
|
|
|
Jonathan,
Comments below.
On 20/02/2013 5:04 PM, Jonathan Jekeli wrote:
> I have an econtent adapter that is essentially causing the refresh of
> numerous tables. While it is theoretically possible to filter all
> notifications down to the exact notifications that should cause a
> refresh on the tables, it would be extraordinarily difficult and
> time-consuming as we have a massive model, and many different events
> and changes that could possibly trigger a refresh. Also, what often
> happens is a single "user-event" (like clicking state->new in our
> application), triggers 4 objects being created behind the scenes, all
> of which look very similar from the notification standpoint and
> therefore makes it difficult to filter out. I'm wondering if there is
> a good way to do some sort of "delayed job" so that the 4
> notifications only cause a single refresh. For example, something
> similar to:
>
> public void notifyChanged(final Notification notification)
> super.notifyChanged(notification);
> @Override
> public void run() {
> if(matchesFilters(notification)) { //some sort of
> check to see if we recently had another event that would have
> triggered a refresh?
> if(!schedulingJob) {
> scheduleDelayedJob();
> }
> } }
> }
In
org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.notifyChanged(Notification)
you can see it uses a
org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.ViewerRefresh
to do something like that.
> Unfortunately I have little experience in jobs and things like that,
> so it would be very helpful if someone could give assistance in what
> the proper way of doing this is.
Are you using an EditingDomain to support undo? In that case, listening
to the command stack would be much easier. That's how the generated
editor updates the properties view...
|
|
|
Powered by
FUDForum. Page generated in 0.07350 seconds
Home