Community
Participate
Working Groups
The current CollectionBinding is not lazy. Worse yet, the current IUpdatableCollection API does not support lazyness. Would we have to create a new interface like ILazyUpdatableCollection, or could we change IUpdatableCollection?
If we change IUpdatableCollection to have: public Object getElement(int position) I think it can support laziness. Am I wrong?
IUpdatableCollection already supports public Object getElement(int index). If I net net the problem: • Currently the Collection Binder will update *ALL* elements from the domain model to the target, up front. • The TableViewerUpdatable does not deal with a SWT.VIRTUAL based tables, it will always use a IStructuredContentProvider The later one just needs more doing. The “issue” is what is the best approach for the second bullet. For the TreeBinding, we solved this as following, with out the need for special API: /** * Copy model's root elements into the target * It is up to the target to fire a Virtual request event to get * the rest of the children */ public void updateTargetFromModel() { copyRootContents(target, model); } The TreeViewer Updatable today will fire VIRTUAL events, when it needs to drill down to a new level. The TreeBinding listen for these events, and will push a new level (in one shot). For the Collection binding we can use the same VIRTUAL event but for the up front updates we will either have to: Do “nothing” and wait for the Updatable Collection to fire a VIRTUAL event (in this case it will be preferable that a single event is fired for updating a range of visible elements). Updatable Collection has API that the Collection Binding could query (e.g., the getTopIndex() that the Table supports).
(In reply to comment #2) > IUpdatableCollection already supports public Object getElement(int index). > > > If I net net the problem: > <snip/> Sounds good to me. What do you think Boris?
"public Object getElement(int position)" alone is not sufficient for implementing laziness. I haven't looked at the VIRTUAL events yet, but it seems to be the right approach. You also need a method like "void setElementCount(int count)". Furthermore, we would need to be able to distinguish between lazy and eager IUpdatableCollections, otherwise we don't know if all elements should be copied over when binding, or just the element count.
I think you're on the right track here Boris. If nobody objects, I'll make the changes Boris suggests.
(In reply to comment #4) > > Furthermore, we would need to be able to distinguish between lazy and eager > IUpdatableCollections, otherwise we don't know if all elements should be copied > over when binding, or just the element count. > We can always look at the VIRTUAL style for the table (as the JFaceViewer doing today)
Are there any news of the VIRTUAL Table Support?
(In reply to comment #7) > Are there any news of the VIRTUAL Table Support? Not right now. Sorry.
We could really use this in our project. I'm willing to help with this bug, maybe by creating a patch. Or is there something else I can do? Where should I start?
(In reply to comment #9) > We could really use this in our project. I'm willing to help with this bug, > maybe by creating a patch. Or is there something else I can do? Where should I > start? Supporting virtual tables (and trees) requires thought at the architectural level. If you are willing to contribute, how about you write up a short proposal and post it here, on this bug? Basically, if you look at the pattern we have been using, supporting virtual tables would require a new kind of observable indexed collection that can scale to thousands (millions?) of elements but does not have to provide all elements with one call, or even one element at a specific index immediately. It is this callback style of interacting with a virtual indexed collection that makes it hard.
Ok, I will first look into how the non-virtual table binding is done. I can probably start with this next Monday (2006-08-28).
I also suggest that you take a look at CompositeTable (which is a different virtual table implementation, located in the examples plugin) and its associated bindings. It seems like a good idea to use one set of bindings for both SWT's virtual tables and also for CompositeTable if possible. I think that the CompositeTable binding API needs some work in order to properly support SWT's virtual table, but it's probably pretty close. For reference, the main difference between CompositeTable and SWT.VIRTUAL is that when CompositeTable requests data for a set of rows, it expects the results immediately, as a result of the event that requests the data. SWT.VIRTUAL lets clients accept the request and then asynchronously deliver the results back to SWT.
Am I right that the model also needs to implement some kind of interface that allows asking for objects at indices, probably ILazyListElementProvider. Otherwise, how could the lazy observable collection get elements from the model? The model would also need to implement another interface for querying the element count. Also, I have so far used two kinds of virtual table content providers: 1) the first kind will immediately know the element count by asking for it from the model 2) the second kind will "ask for more" elements until null is returned by the model i.e. it will increase it's internally kept element count and call the viewer's setItemCount(int) until the model returns null for an index. So scrolling the table will cause the element count to increase until it reaches the actual number of elements in the model. I think the second case would add even more complexity.
(In reply to comment #13) > Am I right that the model also needs to implement some kind of interface that > allows asking for objects at indices, probably ILazyListElementProvider. They need API that allows for requesting objects at indices, but that API doesn't have to be formalized as an interface. > Otherwise, how could the lazy observable collection get elements from the > model? The model would also need to implement another interface for querying > the element count. CompositeTable's bindings are designed to work with java.util.List implementations. Although this isn't something formally lazy like ILazyListElementProvider, java.util.List does provide size(), get(int), and listIterator() methods, which together provide everything you need to request data lazily. > Also, I have so far used two kinds of virtual table content providers: > 1) the first kind will immediately know the element count by asking for it from > the model > 2) the second kind will "ask for more" elements until null is returned by the > model i.e. it will increase it's internally kept element count and call the > viewer's setItemCount(int) until the model returns null for an index. So > scrolling the table will cause the element count to increase until it reaches > the actual number of elements in the model. > > I think the second case would add even more complexity. Correct. :-) Nice work.
Unfortunately my manager told me to work on something else so I'm not able to devote as much time on this as I would have wanted. But I may still be able to spend some time on it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
