issue 475: Glazed Lists and JideTable

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

issue 475: Glazed Lists and JideTable

hbrands
Administrator
Hey guys,

I hope you're still around.
I need your help with regard to issue 475:
https://glazedlists.dev.java.net/issues/show_bug.cgi?id=475

In short:
Using JideTable from www.jidesoft.com there is a problem when you
have a table selection and then apply a filter that matches no table element, e.g.
the table model count drops to zero.
I could reproduce the problem with our app at work with the latest Glazed Lists
and JIDE (2.8.6) versions.

The provided stack trace and some investigation indicates
that JideTable listens to TableModelEvents itself and
sets the anchor index of the selection model to -1 when the element count is 0.
This triggers our ListSelection to deselect all elements, which causes trouble:
It appears that the local cache of the underlying ThreadProxyList has already be updated
(-> element count is 0), but the ListEvents did not propagate to the ListSelection yet.
So the barcode of the ListSelection is not up to date, causing the IndexOutOfBoundException.

The relevant changes to ThreadProxyList that cause this regression are in revision 1.22:
https://glazedlists.dev.java.net/source/browse/glazedlists/source/ca/odell/glazedlists/impl/gui/ThreadProxyEventList.java?rev=1.24&r1=1.21&r2=1.22

The only working solution I found so far is to go back to an older revision of ThreadProxyList when using JideTable.

Do you know a better solution?

If not, what should we do?
Bundle two different versions of ThreadProxyList with Glazed Lists?

Thanks,
Holger

Reply | Threaded
Open this post in threaded view
|

Re: issue 475: Glazed Lists and JideTable

hbrands
Administrator
Any thoughts or suggestions?

Thanks,
Holger

2010/5/10 Holger Brands <[hidden email]>
Hey guys,

I hope you're still around.
I need your help with regard to issue 475:
https://glazedlists.dev.java.net/issues/show_bug.cgi?id=475

In short:
Using JideTable from www.jidesoft.com there is a problem when you
have a table selection and then apply a filter that matches no table element, e.g.
the table model count drops to zero.
I could reproduce the problem with our app at work with the latest Glazed Lists
and JIDE (2.8.6) versions.

The provided stack trace and some investigation indicates
that JideTable listens to TableModelEvents itself and
sets the anchor index of the selection model to -1 when the element count is 0.
This triggers our ListSelection to deselect all elements, which causes trouble:
It appears that the local cache of the underlying ThreadProxyList has already be updated
(-> element count is 0), but the ListEvents did not propagate to the ListSelection yet.
So the barcode of the ListSelection is not up to date, causing the IndexOutOfBoundException.

The relevant changes to ThreadProxyList that cause this regression are in revision 1.22:
https://glazedlists.dev.java.net/source/browse/glazedlists/source/ca/odell/glazedlists/impl/gui/ThreadProxyEventList.java?rev=1.24&r1=1.21&r2=1.22

The only working solution I found so far is to go back to an older revision of ThreadProxyList when using JideTable.

Do you know a better solution?

If not, what should we do?
Bundle two different versions of ThreadProxyList with Glazed Lists?

Thanks,
Holger


Reply | Threaded
Open this post in threaded view
|

Re: issue 475: Glazed Lists and JideTable

James Lemieux
Hmmmm. Maybe you could unregister JideTable's listener and accomplish it with your own? Though that's doubtful... it's probably a single uber-listener that is updating a lot of internal state in JideTable as well as related models (like the selection model).

It's actually a mistake, IMO, that we attempt to fire the TableModelEvent so quickly. It is definitely "more correct" to update both TableModel and it's associated ListSelectionModel before firing any Swing Events from either. Perhaps there is a way to do this by setting setRelatedListener(...) dependencies... but altering the current order of event delivery will probably also break a lot of GL users in the field.

This is a tricky place to be in, ultimately, because the site of the problem is the handoff from GL event firing to Swing event firing.

Maybe ListEventListener should have invented a "postListChanged" method, which is called back after the ENTIRE pipeline has reacted to listChanged(...). This would probably give a very valuable hook to many listeners, rather than relying heavily on the order of event propagation. EventTableModel and EventSelectionModel would fire their Swing events in that method instead of at the end of their listChanged method...

James

On Mon, May 24, 2010 at 6:56 AM, Holger Brands <[hidden email]> wrote:
Any thoughts or suggestions?

Thanks,
Holger

2010/5/10 Holger Brands <[hidden email]>

Hey guys,

I hope you're still around.
I need your help with regard to issue 475:
https://glazedlists.dev.java.net/issues/show_bug.cgi?id=475

In short:
Using JideTable from www.jidesoft.com there is a problem when you
have a table selection and then apply a filter that matches no table element, e.g.
the table model count drops to zero.
I could reproduce the problem with our app at work with the latest Glazed Lists
and JIDE (2.8.6) versions.

The provided stack trace and some investigation indicates
that JideTable listens to TableModelEvents itself and
sets the anchor index of the selection model to -1 when the element count is 0.
This triggers our ListSelection to deselect all elements, which causes trouble:
It appears that the local cache of the underlying ThreadProxyList has already be updated
(-> element count is 0), but the ListEvents did not propagate to the ListSelection yet.
So the barcode of the ListSelection is not up to date, causing the IndexOutOfBoundException.

The relevant changes to ThreadProxyList that cause this regression are in revision 1.22:
https://glazedlists.dev.java.net/source/browse/glazedlists/source/ca/odell/glazedlists/impl/gui/ThreadProxyEventList.java?rev=1.24&r1=1.21&r2=1.22

The only working solution I found so far is to go back to an older revision of ThreadProxyList when using JideTable.

Do you know a better solution?

If not, what should we do?
Bundle two different versions of ThreadProxyList with Glazed Lists?

Thanks,
Holger



Reply | Threaded
Open this post in threaded view
|

Re: issue 475: Glazed Lists and JideTable

hbrands
Administrator
James, thanks for sharing your thoughts.
Unfortunately, I didn't have time to come back to this issue, yet.
It will have to wait until after my vacation ...

Thanks,
Holger

2010/5/25 James Lemieux <[hidden email]>
Hmmmm. Maybe you could unregister JideTable's listener and accomplish it with your own? Though that's doubtful... it's probably a single uber-listener that is updating a lot of internal state in JideTable as well as related models (like the selection model).

It's actually a mistake, IMO, that we attempt to fire the TableModelEvent so quickly. It is definitely "more correct" to update both TableModel and it's associated ListSelectionModel before firing any Swing Events from either. Perhaps there is a way to do this by setting setRelatedListener(...) dependencies... but altering the current order of event delivery will probably also break a lot of GL users in the field.

This is a tricky place to be in, ultimately, because the site of the problem is the handoff from GL event firing to Swing event firing.

Maybe ListEventListener should have invented a "postListChanged" method, which is called back after the ENTIRE pipeline has reacted to listChanged(...). This would probably give a very valuable hook to many listeners, rather than relying heavily on the order of event propagation. EventTableModel and EventSelectionModel would fire their Swing events in that method instead of at the end of their listChanged method...

James


On Mon, May 24, 2010 at 6:56 AM, Holger Brands <[hidden email]> wrote:
Any thoughts or suggestions?

Thanks,
Holger

2010/5/10 Holger Brands <[hidden email]>

Hey guys,

I hope you're still around.
I need your help with regard to issue 475:
https://glazedlists.dev.java.net/issues/show_bug.cgi?id=475

In short:
Using JideTable from www.jidesoft.com there is a problem when you
have a table selection and then apply a filter that matches no table element, e.g.
the table model count drops to zero.
I could reproduce the problem with our app at work with the latest Glazed Lists
and JIDE (2.8.6) versions.

The provided stack trace and some investigation indicates
that JideTable listens to TableModelEvents itself and
sets the anchor index of the selection model to -1 when the element count is 0.
This triggers our ListSelection to deselect all elements, which causes trouble:
It appears that the local cache of the underlying ThreadProxyList has already be updated
(-> element count is 0), but the ListEvents did not propagate to the ListSelection yet.
So the barcode of the ListSelection is not up to date, causing the IndexOutOfBoundException.

The relevant changes to ThreadProxyList that cause this regression are in revision 1.22:
https://glazedlists.dev.java.net/source/browse/glazedlists/source/ca/odell/glazedlists/impl/gui/ThreadProxyEventList.java?rev=1.24&r1=1.21&r2=1.22

The only working solution I found so far is to go back to an older revision of ThreadProxyList when using JideTable.

Do you know a better solution?

If not, what should we do?
Bundle two different versions of ThreadProxyList with Glazed Lists?

Thanks,
Holger