Home » Eclipse Projects » Nebula » [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable?
| [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #23653] |
Fri, 19 January 2007 19:30  |
Eclipse User |
|
|
|
Originally posted by: mbayly.nospam.telus.net
Hi
Are there examples of doing 3.2 databinding with CompositeTable - I was looking
at the 3.2 databinding examples and tests that contain an early version of
CompositeTable before it was moved to Nebula and although there are examples
of using CompositeTable it doesn't seem to include references to using it
with databinding.
Sorry if this is a simple question - trying to get my head around so much
at the moment that I'm just not seeing it.
Thanks
Martin
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #23740 is a reply to message #23653] |
Sat, 20 January 2007 00:35  |
 Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
I don't think there are any public examples of data binding with
CompositeTable. We use it internally here at my client.
Do you really need to use the old API? If you're writing new code, I'd
pretty strongly recommend writing it against the new API.
Here's the gist of how it works:
public void createControl(Composite parent) {
// Create and bind other stuff here if needed...
// Now to bind the CompositeTable, we first define a strategy to bind
// rows inside the table:
IRowBinder rowBinder = new IRowBinder() {
public void bindRow(DataBindingContext dbc, Control row, Object o) {
//- dbc is a data binding context to use
//- row is an instance of your row object. Down-cast it to your
// row's type and then use it to bind.
//- o is the domain object to bind to the row.
//
// Something like:
MyRow myRow = (MyRow) row;
MyPerson person = (MyPerson) o;
dbc.bind(myRow.getNameText(), new Property(person, "name"), null);
}
}
// Now that we have an IRowBinder, we can bind the table.
//
// Similar to the new data binding API, we create a CompositeTable
// observable directly, and then bind it.
CompositeTableObservableLazyDataRequestor ctObservable =
new CompositeTableObservableLazyDataRequestor(
bindingContext, compositeTable, rowBinder);
bindingContext.bind(
ctObservable,
new Property(anObjectWithPersons, "personsProperty",
MyPerson.class, true), null);
}
If you can use the new API, please let me know and I'll bump the
priority level of getting data binding working with it.
Regards,
Dave Orme
martin wrote:
> Hi
>
> Are there examples of doing 3.2 databinding with CompositeTable - I was
> looking at the 3.2 databinding examples and tests that contain an early
> version of CompositeTable before it was moved to Nebula and although
> there are examples of using CompositeTable it doesn't seem to include
> references to using it with databinding.
>
> Sorry if this is a simple question - trying to get my head around so
> much at the moment that I'm just not seeing it.
>
> Thanks
> Martin
>
>
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #24412 is a reply to message #23740] |
Wed, 24 January 2007 23:03 |
| Eclipse User |
|
|
|
Originally posted by: mbayly.nospam.telus.net
Hi Dave
By new API, did you mean the new CompositeTable API or the new databinding
API? I'm assuming you meant the new CompositeTable API.
Yes, if we tried using CompositeTable we'd definitely be using a later version
from Nebula. I assume you also meant you'll bump up the priority of getting
the new 3.3 databinding API working with the Nebula CompositeTable?
As an aside, can you just clarify - is it possible for us to use the 3.3
M4 databinding API against 3.2.1 Eclipse for RCP development? I think I
read that was the case. If so, I think I'll probably download and migrate
our app to start using that instead of the 3.2.1 databinding API before we
get too far down the development road.
As I mentioned before, probably the biggest issues stopping us from using
the CompositeTable at the moment are it's lack of ability to resize columns
and the non-native looking table header. (I noticed in the latest version
you already have some hooks for resize, so I guess you're already working
on that :). Row selection is also a little non-standard - i.e. I'm guessing
we have to use a RowFocusListener for now?
Currently, I've just modified our tables to use a plain SWT virtual table,
but that has meant I've had to skip using databinding and handle the binding
manually.
Incidentally (as another aside), I was looking at how the 3.2 binding API
handles binding list modifications. e.g. additions, updates, and removals.
It seems like additions and removals are handled by firing a property change
on the whole list. The databinding impl then does a 'diff' on the list which
currently just marks all the original list entries for removal and all the
current list entries for addition - there is a comment saying it's a naive
implementation :) . Remove ultimately uses the TableViewer.remove which
I think is probably quite efficient but addition does a refresh. This means
that refresh is being called once for every item in your list whenever you
add/remove a single entry in the list. My assumption is that would be very
inefficient - unless refresh uses lots of tricks? Is this something that
has been looked at in the newer databinding api?
I'm not sure I understand why TableViewer has API to update/remove a single
element but no API to add an element? Maybe there is a good reason for that?
But I realize that's outside the scope of what you're working on.
Cheers
Martin
> I don't think there are any public examples of data binding with
> CompositeTable. We use it internally here at my client.
>
> Do you really need to use the old API? If you're writing new code,
> I'd pretty strongly recommend writing it against the new API.
>
> Here's the gist of how it works:
>
> public void createControl(Composite parent) {
> // Create and bind other stuff here if needed...
> // Now to bind the CompositeTable, we first define a strategy to
> bind
> // rows inside the table:
> IRowBinder rowBinder = new IRowBinder() {
> public void bindRow(DataBindingContext dbc, Control row, Object
> o) {
> //- dbc is a data binding context to use
> //- row is an instance of your row object. Down-cast it to
> your
> // row's type and then use it to bind.
> //- o is the domain object to bind to the row.
> //
> // Something like:
> MyRow myRow = (MyRow) row;
> MyPerson person = (MyPerson) o;
> dbc.bind(myRow.getNameText(), new Property(person, "name"),
> null);
> }
> }
> // Now that we have an IRowBinder, we can bind the table.
> //
> // Similar to the new data binding API, we create a CompositeTable
> // observable directly, and then bind it.
> CompositeTableObservableLazyDataRequestor ctObservable =
> new CompositeTableObservableLazyDataRequestor(
> bindingContext, compositeTable, rowBinder);
> bindingContext.bind(
> ctObservable,
> new Property(anObjectWithPersons, "personsProperty",
> MyPerson.class, true), null);
> }
> If you can use the new API, please let me know and I'll bump the
> priority level of getting data binding working with it.
>
> Regards,
>
> Dave Orme
>
> martin wrote:
>
>> Hi
>>
>> Are there examples of doing 3.2 databinding with CompositeTable - I
>> was looking at the 3.2 databinding examples and tests that contain an
>> early version of CompositeTable before it was moved to Nebula and
>> although there are examples of using CompositeTable it doesn't seem
>> to include references to using it with databinding.
>>
>> Sorry if this is a simple question - trying to get my head around so
>> much at the moment that I'm just not seeing it.
>>
>> Thanks
>> Martin
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #24575 is a reply to message #24412] |
Fri, 26 January 2007 03:29 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
martin wrote:
> By new API, did you mean the new CompositeTable API or the new
> databinding API? I'm assuming you meant the new CompositeTable API.
Actually, I meant both but mainly the data binding API. CompositeTable
has not changed nearly as drastically as data binding has.
> Yes, if we tried using CompositeTable we'd definitely be using a later
> version from Nebula. I assume you also meant you'll bump up the
> priority of getting the new 3.3 databinding API working with the Nebula
> CompositeTable?
Yes. Right now I'm working on a native header control, plus support for
moving and resizing columns. Data binding will be next.
> As an aside, can you just clarify - is it possible for us to use the 3.3
> M4 databinding API against 3.2.1 Eclipse for RCP development? I think I
> read that was the case. If so, I think I'll probably download and
> migrate our app to start using that instead of the 3.2.1 databinding API
> before we get too far down the development road.
Yes. This course is strongly recommended.
> As I mentioned before, probably the biggest issues stopping us from
> using the CompositeTable at the moment are it's lack of ability to
> resize columns and the non-native looking table header. (I noticed in
> the latest version you already have some hooks for resize, so I guess
> you're already working on that :).
Yes.
> Row selection is also a little
> non-standard - i.e. I'm guessing we have to use a RowFocusListener for now?
That depends on what you're looking for. You can use a RowFocusListener
or take a look at Snippet 5 which implements functionality equivalent to
SWT.FULL_SELECTION.
> Currently, I've just modified our tables to use a plain SWT virtual
> table, but that has meant I've had to skip using databinding and handle
> the binding manually.
Makes sense.
> Incidentally (as another aside), I was looking at how the 3.2 binding
> API handles binding list modifications. e.g. additions, updates, and
> removals. It seems like additions and removals are handled by firing a
> property change on the whole list. The databinding impl then does a
> 'diff' on the list which currently just marks all the original list
> entries for removal and all the current list entries for addition -
> there is a comment saying it's a naive implementation :) . Remove
> ultimately uses the TableViewer.remove which I think is probably quite
> efficient but addition does a refresh. This means that refresh is being
> called once for every item in your list whenever you add/remove a single
> entry in the list. My assumption is that would be very inefficient -
> unless refresh uses lots of tricks?
You're right. This is the #1 reason why my current client moved to data
binding.
> Is this something that has been looked at in the newer databinding api?
I'm not sure. My guess is the answer is "no" since we've really been
focusing on getting the API finalized before M5.
> I'm not sure I understand why TableViewer has API to update/remove a
> single element but no API to add an element? Maybe there is a good
> reason for that? But I realize that's outside the scope of what you're
> working on.
:-)
Best regards,
Dave Orme
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #24695 is a reply to message #24412] |
Fri, 26 January 2007 08:09 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
martin schrieb:
> Hi Dave
>
> By new API, did you mean the new CompositeTable API or the new
> databinding API? I'm assuming you meant the new CompositeTable API.
>
> Yes, if we tried using CompositeTable we'd definitely be using a later
> version from Nebula. I assume you also meant you'll bump up the
> priority of getting the new 3.3 databinding API working with the Nebula
> CompositeTable?
>
> As an aside, can you just clarify - is it possible for us to use the 3.3
> M4 databinding API against 3.2.1 Eclipse for RCP development? I think I
> read that was the case. If so, I think I'll probably download and
> migrate our app to start using that instead of the 3.2.1 databinding API
> before we get too far down the development road.
>
> As I mentioned before, probably the biggest issues stopping us from
> using the CompositeTable at the moment are it's lack of ability to
> resize columns and the non-native looking table header. (I noticed in
> the latest version you already have some hooks for resize, so I guess
> you're already working on that :). Row selection is also a little
> non-standard - i.e. I'm guessing we have to use a RowFocusListener for now?
>
> Currently, I've just modified our tables to use a plain SWT virtual
> table, but that has meant I've had to skip using databinding and handle
> the binding manually.
>
> Incidentally (as another aside), I was looking at how the 3.2 binding
> API handles binding list modifications. e.g. additions, updates, and
> removals. It seems like additions and removals are handled by firing a
> property change on the whole list. The databinding impl then does a
> 'diff' on the list which currently just marks all the original list
> entries for removal and all the current list entries for addition -
> there is a comment saying it's a naive implementation :) . Remove
> ultimately uses the TableViewer.remove which I think is probably quite
> efficient but addition does a refresh. This means that refresh is being
> called once for every item in your list whenever you add/remove a single
> entry in the list. My assumption is that would be very inefficient -
> unless refresh uses lots of tricks? Is this something that has been
> looked at in the newer databinding api?
> I'm not sure I understand why TableViewer has API to update/remove a
> single element but no API to add an element? Maybe there is a good
> reason for that? But I realize that's outside the scope of what you're
> working on.
>
But it's my scope I'm working on ;-) but i can't follow you my
TableViewer has the following methods:
TableViewer#add(Object[] elements)
TableViewer#add(Object element)
TableViewer#insert(Object element)
Did I miss something?
Tom
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #24734 is a reply to message #24695] |
Fri, 26 January 2007 18:22 |
| Eclipse User |
|
|
|
Originally posted by: mbayly.nospam.telus.net
Hi Tom/Dave
Yes, you are absolutely right Tom. My mistake - TableViewer does have methods
to add/insert.
It's AbstractListViewer that was causing databinding problems I think - AbstractListViewer
has methods to add but not to insert at a specific index.
I was actually looking at the 3.2 databinding ComboScenario tests to understand
how adding and removing from a model list might work with table databinding
because the TableScenarios don't have tests that demonstrate addition/removal.
3.2 Databinding has a class AbstractListViewerObservableCollectionWithLabels
which has a method addToViewer(int index, Object element).
This method is called whenever you add/remove from a list and then fire a
property change on the list
e.g. firePropertyChange("lodgings", null, null);
In the AbstractListViewerObservableCollectionWithLabels implementation of
addToViewer(int index, Object element), it calls StructuredViewer.refresh()
and there is a comment saying it has to call refresh because there is no
AbstractListViewer.insert(index, element).
So I had just mistakenly assumed it would be the same for TableViewer too.
However, unlike AbstractListViewer, TableViewer does have an insert(Object
element, int position) method, so this is used by the equivalent table databinding
class TableViewerObservableCollectionWithLabels.
I updated one of the 3.2 TableScenario tests to include adding and removing
elements and it seems to work and makes use of the TableViewer insert/remove
methods. Even so, it's still using the 'naive' (as described in the code)
list diff implementation that removes and then adds all the list items.
So each time you add or remove an element from your underlying model and
then call firePropertyChange("model", null, null), you end up individually
removing every item from your list and then individually re-adding every
item in your list - again clearly not very optimal. However, I can see that
this would be a relatively difficult problem to solve using basic PropertyChangeSupport.
Ideally there should be a way to indicate in the model change method which
model element has been added or removed rather than just sending a general
'list changed' event. But I'm not sure if its possible to do that kind of
thing with PropertyChangeSupport?
I took a quick look at the 3.3 databinding code and it looks like it is still
using the brute force approach on list diffs (although I didn't try to run
any tests to see if this mechanism is still being used to handle list addition/removal,
so things could have changed). If things have not changed then that's probably
still going to be a problem - I suppose if the table was virtual, you would
only be adding the visible items again but as JFace and virtual tables still
have problems in 3.2 (maybe that will all be fixed for 3.3?) that's not going
to help much? Maybe Dave's fully virtual CompositeTable is the answer?
Cheers
Martin
Hello Tom,
> martin schrieb:
>
>> Hi Dave
>>
>> By new API, did you mean the new CompositeTable API or the new
>> databinding API? I'm assuming you meant the new CompositeTable API.
>>
>> Yes, if we tried using CompositeTable we'd definitely be using a
>> later version from Nebula. I assume you also meant you'll bump up
>> the priority of getting the new 3.3 databinding API working with the
>> Nebula CompositeTable?
>>
>> As an aside, can you just clarify - is it possible for us to use the
>> 3.3 M4 databinding API against 3.2.1 Eclipse for RCP development? I
>> think I read that was the case. If so, I think I'll probably
>> download and migrate our app to start using that instead of the 3.2.1
>> databinding API before we get too far down the development road.
>>
>> As I mentioned before, probably the biggest issues stopping us from
>> using the CompositeTable at the moment are it's lack of ability to
>> resize columns and the non-native looking table header. (I noticed in
>> the latest version you already have some hooks for resize, so I guess
>> you're already working on that :). Row selection is also a little
>> non-standard - i.e. I'm guessing we have to use a RowFocusListener
>> for now?
>>
>> Currently, I've just modified our tables to use a plain SWT virtual
>> table, but that has meant I've had to skip using databinding and
>> handle the binding manually.
>>
>> Incidentally (as another aside), I was looking at how the 3.2 binding
>> API handles binding list modifications. e.g. additions, updates, and
>> removals. It seems like additions and removals are handled by firing
>> a property change on the whole list. The databinding impl then does
>> a 'diff' on the list which currently just marks all the original list
>> entries for removal and all the current list entries for addition -
>> there is a comment saying it's a naive implementation :) . Remove
>> ultimately uses the TableViewer.remove which I think is probably
>> quite efficient but addition does a refresh. This means that refresh
>> is being called once for every item in your list whenever you
>> add/remove a single entry in the list. My assumption is that would
>> be very inefficient - unless refresh uses lots of tricks? Is this
>> something that has been looked at in the newer databinding api? I'm
>> not sure I understand why TableViewer has API to update/remove a
>> single element but no API to add an element? Maybe there is a good
>> reason for that? But I realize that's outside the scope of what
>> you're working on.
>>
> But it's my scope I'm working on ;-) but i can't follow you my
> TableViewer has the following methods:
>
> TableViewer#add(Object[] elements)
> TableViewer#add(Object element)
> TableViewer#insert(Object element)
> Did I miss something?
>
> Tom
>
|
|
| |
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #575197 is a reply to message #23653] |
Sat, 20 January 2007 00:35 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
I don't think there are any public examples of data binding with
CompositeTable. We use it internally here at my client.
Do you really need to use the old API? If you're writing new code, I'd
pretty strongly recommend writing it against the new API.
Here's the gist of how it works:
public void createControl(Composite parent) {
// Create and bind other stuff here if needed...
// Now to bind the CompositeTable, we first define a strategy to bind
// rows inside the table:
IRowBinder rowBinder = new IRowBinder() {
public void bindRow(DataBindingContext dbc, Control row, Object o) {
//- dbc is a data binding context to use
//- row is an instance of your row object. Down-cast it to your
// row's type and then use it to bind.
//- o is the domain object to bind to the row.
//
// Something like:
MyRow myRow = (MyRow) row;
MyPerson person = (MyPerson) o;
dbc.bind(myRow.getNameText(), new Property(person, "name"), null);
}
}
// Now that we have an IRowBinder, we can bind the table.
//
// Similar to the new data binding API, we create a CompositeTable
// observable directly, and then bind it.
CompositeTableObservableLazyDataRequestor ctObservable =
new CompositeTableObservableLazyDataRequestor(
bindingContext, compositeTable, rowBinder);
bindingContext.bind(
ctObservable,
new Property(anObjectWithPersons, "personsProperty",
MyPerson.class, true), null);
}
If you can use the new API, please let me know and I'll bump the
priority level of getting data binding working with it.
Regards,
Dave Orme
martin wrote:
> Hi
>
> Are there examples of doing 3.2 databinding with CompositeTable - I was
> looking at the 3.2 databinding examples and tests that contain an early
> version of CompositeTable before it was moved to Nebula and although
> there are examples of using CompositeTable it doesn't seem to include
> references to using it with databinding.
>
> Sorry if this is a simple question - trying to get my head around so
> much at the moment that I'm just not seeing it.
>
> Thanks
> Martin
>
>
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #575713 is a reply to message #23740] |
Wed, 24 January 2007 23:03 |
martin
Messages: 49
Registered: July 2009 |
Member |
|
|
Hi Dave
By new API, did you mean the new CompositeTable API or the new databinding
API? I'm assuming you meant the new CompositeTable API.
Yes, if we tried using CompositeTable we'd definitely be using a later version
from Nebula. I assume you also meant you'll bump up the priority of getting
the new 3.3 databinding API working with the Nebula CompositeTable?
As an aside, can you just clarify - is it possible for us to use the 3.3
M4 databinding API against 3.2.1 Eclipse for RCP development? I think I
read that was the case. If so, I think I'll probably download and migrate
our app to start using that instead of the 3.2.1 databinding API before we
get too far down the development road.
As I mentioned before, probably the biggest issues stopping us from using
the CompositeTable at the moment are it's lack of ability to resize columns
and the non-native looking table header. (I noticed in the latest version
you already have some hooks for resize, so I guess you're already working
on that :). Row selection is also a little non-standard - i.e. I'm guessing
we have to use a RowFocusListener for now?
Currently, I've just modified our tables to use a plain SWT virtual table,
but that has meant I've had to skip using databinding and handle the binding
manually.
Incidentally (as another aside), I was looking at how the 3.2 binding API
handles binding list modifications. e.g. additions, updates, and removals.
It seems like additions and removals are handled by firing a property change
on the whole list. The databinding impl then does a 'diff' on the list which
currently just marks all the original list entries for removal and all the
current list entries for addition - there is a comment saying it's a naive
implementation :) . Remove ultimately uses the TableViewer.remove which
I think is probably quite efficient but addition does a refresh. This means
that refresh is being called once for every item in your list whenever you
add/remove a single entry in the list. My assumption is that would be very
inefficient - unless refresh uses lots of tricks? Is this something that
has been looked at in the newer databinding api?
I'm not sure I understand why TableViewer has API to update/remove a single
element but no API to add an element? Maybe there is a good reason for that?
But I realize that's outside the scope of what you're working on.
Cheers
Martin
> I don't think there are any public examples of data binding with
> CompositeTable. We use it internally here at my client.
>
> Do you really need to use the old API? If you're writing new code,
> I'd pretty strongly recommend writing it against the new API.
>
> Here's the gist of how it works:
>
> public void createControl(Composite parent) {
> // Create and bind other stuff here if needed...
> // Now to bind the CompositeTable, we first define a strategy to
> bind
> // rows inside the table:
> IRowBinder rowBinder = new IRowBinder() {
> public void bindRow(DataBindingContext dbc, Control row, Object
> o) {
> //- dbc is a data binding context to use
> //- row is an instance of your row object. Down-cast it to
> your
> // row's type and then use it to bind.
> //- o is the domain object to bind to the row.
> //
> // Something like:
> MyRow myRow = (MyRow) row;
> MyPerson person = (MyPerson) o;
> dbc.bind(myRow.getNameText(), new Property(person, "name"),
> null);
> }
> }
> // Now that we have an IRowBinder, we can bind the table.
> //
> // Similar to the new data binding API, we create a CompositeTable
> // observable directly, and then bind it.
> CompositeTableObservableLazyDataRequestor ctObservable =
> new CompositeTableObservableLazyDataRequestor(
> bindingContext, compositeTable, rowBinder);
> bindingContext.bind(
> ctObservable,
> new Property(anObjectWithPersons, "personsProperty",
> MyPerson.class, true), null);
> }
> If you can use the new API, please let me know and I'll bump the
> priority level of getting data binding working with it.
>
> Regards,
>
> Dave Orme
>
> martin wrote:
>
>> Hi
>>
>> Are there examples of doing 3.2 databinding with CompositeTable - I
>> was looking at the 3.2 databinding examples and tests that contain an
>> early version of CompositeTable before it was moved to Nebula and
>> although there are examples of using CompositeTable it doesn't seem
>> to include references to using it with databinding.
>>
>> Sorry if this is a simple question - trying to get my head around so
>> much at the moment that I'm just not seeing it.
>>
>> Thanks
>> Martin
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #575866 is a reply to message #24412] |
Fri, 26 January 2007 03:29 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
martin wrote:
> By new API, did you mean the new CompositeTable API or the new
> databinding API? I'm assuming you meant the new CompositeTable API.
Actually, I meant both but mainly the data binding API. CompositeTable
has not changed nearly as drastically as data binding has.
> Yes, if we tried using CompositeTable we'd definitely be using a later
> version from Nebula. I assume you also meant you'll bump up the
> priority of getting the new 3.3 databinding API working with the Nebula
> CompositeTable?
Yes. Right now I'm working on a native header control, plus support for
moving and resizing columns. Data binding will be next.
> As an aside, can you just clarify - is it possible for us to use the 3.3
> M4 databinding API against 3.2.1 Eclipse for RCP development? I think I
> read that was the case. If so, I think I'll probably download and
> migrate our app to start using that instead of the 3.2.1 databinding API
> before we get too far down the development road.
Yes. This course is strongly recommended.
> As I mentioned before, probably the biggest issues stopping us from
> using the CompositeTable at the moment are it's lack of ability to
> resize columns and the non-native looking table header. (I noticed in
> the latest version you already have some hooks for resize, so I guess
> you're already working on that :).
Yes.
> Row selection is also a little
> non-standard - i.e. I'm guessing we have to use a RowFocusListener for now?
That depends on what you're looking for. You can use a RowFocusListener
or take a look at Snippet 5 which implements functionality equivalent to
SWT.FULL_SELECTION.
> Currently, I've just modified our tables to use a plain SWT virtual
> table, but that has meant I've had to skip using databinding and handle
> the binding manually.
Makes sense.
> Incidentally (as another aside), I was looking at how the 3.2 binding
> API handles binding list modifications. e.g. additions, updates, and
> removals. It seems like additions and removals are handled by firing a
> property change on the whole list. The databinding impl then does a
> 'diff' on the list which currently just marks all the original list
> entries for removal and all the current list entries for addition -
> there is a comment saying it's a naive implementation :) . Remove
> ultimately uses the TableViewer.remove which I think is probably quite
> efficient but addition does a refresh. This means that refresh is being
> called once for every item in your list whenever you add/remove a single
> entry in the list. My assumption is that would be very inefficient -
> unless refresh uses lots of tricks?
You're right. This is the #1 reason why my current client moved to data
binding.
> Is this something that has been looked at in the newer databinding api?
I'm not sure. My guess is the answer is "no" since we've really been
focusing on getting the API finalized before M5.
> I'm not sure I understand why TableViewer has API to update/remove a
> single element but no API to add an element? Maybe there is a good
> reason for that? But I realize that's outside the scope of what you're
> working on.
:-)
Best regards,
Dave Orme
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #575948 is a reply to message #24412] |
Fri, 26 January 2007 08:09 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
martin schrieb:
> Hi Dave
>
> By new API, did you mean the new CompositeTable API or the new
> databinding API? I'm assuming you meant the new CompositeTable API.
>
> Yes, if we tried using CompositeTable we'd definitely be using a later
> version from Nebula. I assume you also meant you'll bump up the
> priority of getting the new 3.3 databinding API working with the Nebula
> CompositeTable?
>
> As an aside, can you just clarify - is it possible for us to use the 3.3
> M4 databinding API against 3.2.1 Eclipse for RCP development? I think I
> read that was the case. If so, I think I'll probably download and
> migrate our app to start using that instead of the 3.2.1 databinding API
> before we get too far down the development road.
>
> As I mentioned before, probably the biggest issues stopping us from
> using the CompositeTable at the moment are it's lack of ability to
> resize columns and the non-native looking table header. (I noticed in
> the latest version you already have some hooks for resize, so I guess
> you're already working on that :). Row selection is also a little
> non-standard - i.e. I'm guessing we have to use a RowFocusListener for now?
>
> Currently, I've just modified our tables to use a plain SWT virtual
> table, but that has meant I've had to skip using databinding and handle
> the binding manually.
>
> Incidentally (as another aside), I was looking at how the 3.2 binding
> API handles binding list modifications. e.g. additions, updates, and
> removals. It seems like additions and removals are handled by firing a
> property change on the whole list. The databinding impl then does a
> 'diff' on the list which currently just marks all the original list
> entries for removal and all the current list entries for addition -
> there is a comment saying it's a naive implementation :) . Remove
> ultimately uses the TableViewer.remove which I think is probably quite
> efficient but addition does a refresh. This means that refresh is being
> called once for every item in your list whenever you add/remove a single
> entry in the list. My assumption is that would be very inefficient -
> unless refresh uses lots of tricks? Is this something that has been
> looked at in the newer databinding api?
> I'm not sure I understand why TableViewer has API to update/remove a
> single element but no API to add an element? Maybe there is a good
> reason for that? But I realize that's outside the scope of what you're
> working on.
>
But it's my scope I'm working on ;-) but i can't follow you my
TableViewer has the following methods:
TableViewer#add(Object[] elements)
TableViewer#add(Object element)
TableViewer#insert(Object element)
Did I miss something?
Tom
|
|
|
| Re: [DataBinding][CompositeTable] Examples of doing databinding with CompositeTable? [message #575979 is a reply to message #24695] |
Fri, 26 January 2007 18:22 |
martin
Messages: 49
Registered: July 2009 |
Member |
|
|
Hi Tom/Dave
Yes, you are absolutely right Tom. My mistake - TableViewer does have methods
to add/insert.
It's AbstractListViewer that was causing databinding problems I think - AbstractListViewer
has methods to add but not to insert at a specific index.
I was actually looking at the 3.2 databinding ComboScenario tests to understand
how adding and removing from a model list might work with table databinding
because the TableScenarios don't have tests that demonstrate addition/removal.
3.2 Databinding has a class AbstractListViewerObservableCollectionWithLabels
which has a method addToViewer(int index, Object element).
This method is called whenever you add/remove from a list and then fire a
property change on the list
e.g. firePropertyChange("lodgings", null, null);
In the AbstractListViewerObservableCollectionWithLabels implementation of
addToViewer(int index, Object element), it calls StructuredViewer.refresh()
and there is a comment saying it has to call refresh because there is no
AbstractListViewer.insert(index, element).
So I had just mistakenly assumed it would be the same for TableViewer too.
However, unlike AbstractListViewer, TableViewer does have an insert(Object
element, int position) method, so this is used by the equivalent table databinding
class TableViewerObservableCollectionWithLabels.
I updated one of the 3.2 TableScenario tests to include adding and removing
elements and it seems to work and makes use of the TableViewer insert/remove
methods. Even so, it's still using the 'naive' (as described in the code)
list diff implementation that removes and then adds all the list items.
So each time you add or remove an element from your underlying model and
then call firePropertyChange("model", null, null), you end up individually
removing every item from your list and then individually re-adding every
item in your list - again clearly not very optimal. However, I can see that
this would be a relatively difficult problem to solve using basic PropertyChangeSupport.
Ideally there should be a way to indicate in the model change method which
model element has been added or removed rather than just sending a general
'list changed' event. But I'm not sure if its possible to do that kind of
thing with PropertyChangeSupport?
I took a quick look at the 3.3 databinding code and it looks like it is still
using the brute force approach on list diffs (although I didn't try to run
any tests to see if this mechanism is still being used to handle list addition/removal,
so things could have changed). If things have not changed then that's probably
still going to be a problem - I suppose if the table was virtual, you would
only be adding the visible items again but as JFace and virtual tables still
have problems in 3.2 (maybe that will all be fixed for 3.3?) that's not going
to help much? Maybe Dave's fully virtual CompositeTable is the answer?
Cheers
Martin
Hello Tom,
> martin schrieb:
>
>> Hi Dave
>>
>> By new API, did you mean the new CompositeTable API or the new
>> databinding API? I'm assuming you meant the new CompositeTable API.
>>
>> Yes, if we tried using CompositeTable we'd definitely be using a
>> later version from Nebula. I assume you also meant you'll bump up
>> the priority of getting the new 3.3 databinding API working with the
>> Nebula CompositeTable?
>>
>> As an aside, can you just clarify - is it possible for us to use the
>> 3.3 M4 databinding API against 3.2.1 Eclipse for RCP development? I
>> think I read that was the case. If so, I think I'll probably
>> download and migrate our app to start using that instead of the 3.2.1
>> databinding API before we get too far down the development road.
>>
>> As I mentioned before, probably the biggest issues stopping us from
>> using the CompositeTable at the moment are it's lack of ability to
>> resize columns and the non-native looking table header. (I noticed in
>> the latest version you already have some hooks for resize, so I guess
>> you're already working on that :). Row selection is also a little
>> non-standard - i.e. I'm guessing we have to use a RowFocusListener
>> for now?
>>
>> Currently, I've just modified our tables to use a plain SWT virtual
>> table, but that has meant I've had to skip using databinding and
>> handle the binding manually.
>>
>> Incidentally (as another aside), I was looking at how the 3.2 binding
>> API handles binding list modifications. e.g. additions, updates, and
>> removals. It seems like additions and removals are handled by firing
>> a property change on the whole list. The databinding impl then does
>> a 'diff' on the list which currently just marks all the original list
>> entries for removal and all the current list entries for addition -
>> there is a comment saying it's a naive implementation :) . Remove
>> ultimately uses the TableViewer.remove which I think is probably
>> quite efficient but addition does a refresh. This means that refresh
>> is being called once for every item in your list whenever you
>> add/remove a single entry in the list. My assumption is that would
>> be very inefficient - unless refresh uses lots of tricks? Is this
>> something that has been looked at in the newer databinding api? I'm
>> not sure I understand why TableViewer has API to update/remove a
>> single element but no API to add an element? Maybe there is a good
>> reason for that? But I realize that's outside the scope of what
>> you're working on.
>>
> But it's my scope I'm working on ;-) but i can't follow you my
> TableViewer has the following methods:
>
> TableViewer#add(Object[] elements)
> TableViewer#add(Object element)
> TableViewer#insert(Object element)
> Did I miss something?
>
> Tom
>
|
|
| |
Goto Forum:
Current Time: Thu Sep 19 23:53:17 GMT 2024
Powered by FUDForum. Page generated in 0.04169 seconds |
] 
Search
Help
Register
Login
Home
