|
|
| Re: [DataBinding] Duplicate data structures in StructuredViewerObservableCollectionWithLabels [message #447599 is a reply to message #447559] |
Tue, 11 April 2006 15:46   |
 Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
Thanks for the response. Responses to individual comments are below...
On 2006-04-10 22:22:21 -0600, "David J. Orme"
<djo@coconut-palm-software.com> said:
> Brad Reynolds wrote:
>> Why does SVOCWL internally maintain a Set and a List for the same data?
>> It looks like it's trying to support IObservableList and IObservableSet
>> which is confusing in the code and would seem like it would be
>> inefficient as well, especially when we're talking about hundreds and
>> possibly thousands of items being maintained.
>
> Thanks for the question.
>
> Here's the reason:
>
> Because JFace viewers are implemented using Set semantics but Hibernate
> likes to use List semantics. You've got to bridge the gap somewhere.
> Our approach was to make SVOCWL implement both IObservableList and
> IObservableSet interfaces so you can have your cake and eat it too.
>
> I'd challenge the assumption that this is the main scalability
> bottleneck though:
>
> Most tables with thousands of elements are going to have usability
> problems: in most cases people just can't efficiently scroll through
> that many elements. The solution is normally to query for a smaller
> set first, and then to scroll through that.
I agree but I'm not sure we fall in the "most cases". One of our
applications is a database build app and at times this involves viewing
CSVs and very large datasets. I'd love to filter it down but that's
not what people are used to. They want to view it like Excel, navigate
it like Excel, and basically just have Excel. Because we have a custom
Table we're able to provide this at the Widget level. I've had this
argument many times but in the end we have to bow to the need of the
client and for these use cases they like to view all data at once.
>
> Further: SWT Table-based UIs don't scale well into thousands of rows to
> begin with. So if you have thousands of rows, you already need to look
> beyond JFace viewers.
We actually have our own Table implementation to get around these
things. It does pretty good with thousands of rows and is getting
better.
>
> Which is why I wrote the CompositeTable control that's in the Examples
> plugin. It is fully virtual, so there are zero scaling issues. It
> fully supports in-place editing where you don't have to switch between
> edit mode and browse mode. It has a full edit life cycle event model
> including support for two-phase commit.
>
> But we still need to write binding support for it. Would you like to
> help? :-)
You know I'd love to help. :) But I probably can't on bindings for this
widget as we have our own and I don't think I could justify working on
bindings for a component we won't use. Nothing against your widget of
course but I'm legally obligated in this regard.
>
> Thanks again for your great questions!
>
>
> Best regards,
>
> Dave Orme
I guess in the end if this ends up being an issue we could create our
own implementation... hopefully. I'm curious if because of Hibernate
and other dependencies if this should part of the core StructuredViewer
binding support or if a little more separated concerns approach is more
appropriate. What I'm most concerned about is the core framework being
bound too tightly with the assumption that it will always be an
IObservableList and IObservableSet when using a StructuredViewer. I
haven't dug deep enough to see if that assumption exists and is
enforced but if so I'm going to have to rewrite a lot of code and of
course I'd like to avoid that if possible.
Thanks again,
Brad
|
|
|
| Re: [DataBinding] Duplicate data structures in StructuredViewerObservableCollectionWithLabels [message #447615 is a reply to message #447599] |
Wed, 12 April 2006 03:38 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Brad,
Hmmmm... We think you have made your point well. We're not sure right
now what the solution would be and if you have any suggestions, we'd
love to hear them. :-) In the meantime, we're working on what to do
with this.
Best regards,
Dave Orme
Brad Reynolds wrote:
> Thanks for the response. Responses to individual comments are below...
>
> On 2006-04-10 22:22:21 -0600, "David J. Orme"
> <djo@coconut-palm-software.com> said:
>
>> Brad Reynolds wrote:
>>
>>> Why does SVOCWL internally maintain a Set and a List for the same
>>> data? It looks like it's trying to support IObservableList and
>>> IObservableSet which is confusing in the code and would seem like it
>>> would be inefficient as well, especially when we're talking about
>>> hundreds and possibly thousands of items being maintained.
>>
>>
>> Thanks for the question.
>>
>> Here's the reason:
>>
>> Because JFace viewers are implemented using Set semantics but
>> Hibernate likes to use List semantics. You've got to bridge the gap
>> somewhere. Our approach was to make SVOCWL implement both
>> IObservableList and IObservableSet interfaces so you can have your
>> cake and eat it too.
>>
>> I'd challenge the assumption that this is the main scalability
>> bottleneck though:
>>
>> Most tables with thousands of elements are going to have usability
>> problems: in most cases people just can't efficiently scroll through
>> that many elements. The solution is normally to query for a smaller
>> set first, and then to scroll through that.
>
> I agree but I'm not sure we fall in the "most cases". One of our
> applications is a database build app and at times this involves viewing
> CSVs and very large datasets. I'd love to filter it down but that's not
> what people are used to. They want to view it like Excel, navigate it
> like Excel, and basically just have Excel. Because we have a custom
> Table we're able to provide this at the Widget level. I've had this
> argument many times but in the end we have to bow to the need of the
> client and for these use cases they like to view all data at once.
>
>>
>> Further: SWT Table-based UIs don't scale well into thousands of rows
>> to begin with. So if you have thousands of rows, you already need to
>> look beyond JFace viewers.
>
> We actually have our own Table implementation to get around these
> things. It does pretty good with thousands of rows and is getting better.
>
>>
>> Which is why I wrote the CompositeTable control that's in the Examples
>> plugin. It is fully virtual, so there are zero scaling issues. It
>> fully supports in-place editing where you don't have to switch between
>> edit mode and browse mode. It has a full edit life cycle event model
>> including support for two-phase commit.
>>
>> But we still need to write binding support for it. Would you like to
>> help? :-)
>
> You know I'd love to help. :) But I probably can't on bindings for this
> widget as we have our own and I don't think I could justify working on
> bindings for a component we won't use. Nothing against your widget of
> course but I'm legally obligated in this regard.
>
>>
>> Thanks again for your great questions!
>>
>>
>> Best regards,
>>
>> Dave Orme
>
>
> I guess in the end if this ends up being an issue we could create our
> own implementation... hopefully. I'm curious if because of Hibernate
> and other dependencies if this should part of the core StructuredViewer
> binding support or if a little more separated concerns approach is more
> appropriate. What I'm most concerned about is the core framework being
> bound too tightly with the assumption that it will always be an
> IObservableList and IObservableSet when using a StructuredViewer. I
> haven't dug deep enough to see if that assumption exists and is enforced
> but if so I'm going to have to rewrite a lot of code and of course I'd
> like to avoid that if possible.
>
> Thanks again,
> Brad
>
--
Visual Editor Project lead
http://www.coconut-palm-software.com
http://www.db4o.com -- The Open-source Java Object Database
|
|
|
| Re: [DataBinding] Duplicate data structures in StructuredViewerObservableCollectionWithLabels [message #447682 is a reply to message #447615] |
Wed, 12 April 2006 13:22 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
Thanks for the information. I'm kind of getting pulled off the project
so there will be less involvement from me but I'll try to keep looking
at things in my spare time. I don't yet have any suggestions but once
I can get an even better idea as to how viewers are implemented and if
that provides any ideas I'll send them your way.
On 2006-04-11 21:38:21 -0600, "David J. Orme"
<djo@coconut-palm-software.com> said:
> Brad,
>
> Hmmmm... We think you have made your point well. We're not sure right
> now what the solution would be and if you have any suggestions, we'd
> love to hear them. :-) In the meantime, we're working on what to do
> with this.
>
>
> Best regards,
>
> Dave Orme
>
> Brad Reynolds wrote:
>> Thanks for the response. Responses to individual comments are below...
>>
>> On 2006-04-10 22:22:21 -0600, "David J. Orme"
>> <djo@coconut-palm-software.com> said:
>>
>>> Brad Reynolds wrote:
>>>
>>>> Why does SVOCWL internally maintain a Set and a List for the same data?
>>>> It looks like it's trying to support IObservableList and IObservableSet
>>>> which is confusing in the code and would seem like it would be
>>>> inefficient as well, especially when we're talking about hundreds and
>>>> possibly thousands of items being maintained.
>>>
>>>
>>> Thanks for the question.
>>>
>>> Here's the reason:
>>>
>>> Because JFace viewers are implemented using Set semantics but Hibernate
>>> likes to use List semantics. You've got to bridge the gap somewhere.
>>> Our approach was to make SVOCWL implement both IObservableList and
>>> IObservableSet interfaces so you can have your cake and eat it too.
>>>
>>> I'd challenge the assumption that this is the main scalability
>>> bottleneck though:
>>>
>>> Most tables with thousands of elements are going to have usability
>>> problems: in most cases people just can't efficiently scroll through
>>> that many elements. The solution is normally to query for a smaller
>>> set first, and then to scroll through that.
>>
>> I agree but I'm not sure we fall in the "most cases". One of our
>> applications is a database build app and at times this involves viewing
>> CSVs and very large datasets. I'd love to filter it down but that's
>> not what people are used to. They want to view it like Excel, navigate
>> it like Excel, and basically just have Excel. Because we have a custom
>> Table we're able to provide this at the Widget level. I've had this
>> argument many times but in the end we have to bow to the need of the
>> client and for these use cases they like to view all data at once.
>>
>>>
>>> Further: SWT Table-based UIs don't scale well into thousands of rows to
>>> begin with. So if you have thousands of rows, you already need to look
>>> beyond JFace viewers.
>>
>> We actually have our own Table implementation to get around these
>> things. It does pretty good with thousands of rows and is getting
>> better.
>>
>>>
>>> Which is why I wrote the CompositeTable control that's in the Examples
>>> plugin. It is fully virtual, so there are zero scaling issues. It
>>> fully supports in-place editing where you don't have to switch between
>>> edit mode and browse mode. It has a full edit life cycle event model
>>> including support for two-phase commit.
>>>
>>> But we still need to write binding support for it. Would you like to
>>> help? :-)
>>
>> You know I'd love to help. :) But I probably can't on bindings for this
>> widget as we have our own and I don't think I could justify working on
>> bindings for a component we won't use. Nothing against your widget of
>> course but I'm legally obligated in this regard.
>>
>>>
>>> Thanks again for your great questions!
>>>
>>>
>>> Best regards,
>>>
>>> Dave Orme
>>
>>
>> I guess in the end if this ends up being an issue we could create our
>> own implementation... hopefully. I'm curious if because of Hibernate
>> and other dependencies if this should part of the core StructuredViewer
>> binding support or if a little more separated concerns approach is more
>> appropriate. What I'm most concerned about is the core framework being
>> bound too tightly with the assumption that it will always be an
>> IObservableList and IObservableSet when using a StructuredViewer. I
>> haven't dug deep enough to see if that assumption exists and is
>> enforced but if so I'm going to have to rewrite a lot of code and of
>> course I'd like to avoid that if possible.
>>
>> Thanks again,
>> Brad
|
|
|
Powered by
FUDForum. Page generated in 0.04181 seconds
] 
Search
Help
Register
Login
Home
