Home » Eclipse Projects » Eclipse Platform » [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList?
| | | |
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #327045 is a reply to message #327040] |
Mon, 07 April 2008 15:36   |
 Tim Hollosy
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
Answering my own question here, looking at the source for PojoObservables,
I see that the JavaBeanObservableMap that is returned has the
attachListeners attribute set to false.
It appears I was confused as to what exactly PojoObservables are, I was
thinking I could have my cake and eat it too. Apparantly if I want to be
able to listen to changes I need to use BeanObservables and implement
Property Change Support.
If that's the case, what exactly is the point of PojoObservables? Is it
just to be able to bind, without listening so you don't have to see the
annoying log messages?
If someone could confirm that there is absolutely no way I can listen to
changes on a bean without adding PropertyChangeSupport to all my pojo's
then I'll go ahead and go down that road. But I'm still curious to what
the actual point of PojoObservables are.
Thanks,
Tim
Tim H wrote:
> Thanks Tom,
> So even though I'm calling PojoObservables.observeMaps to make an
> IObservableMap[] that will not listen to changes the same way one created
> with BeanObservables will?
> Tom Schindl wrote:
>> Well ObservableMapLabelProvider listens for property changes and calls
>> update(Object,String[]) for the viewer but because you are using
>> POJOObsevables there are no change events generated by your obervables.
>> You should consider using BeanObservables.
>> Tom
>> Tim H schrieb:
>>> I've been playing around building a simple CRUD with JFace Databinding.
>>> I've hit one snag.
>>>
>>> I'm using the latest from CVS-Head with PojoObservables, I want my
>>> TableViewer to automatically refresh changes when the contents of my
>>> WritableList change. I have no problem when I add/delete from the list.
>>> However when I make changes (updates to elements in the wrapped list) I
>>> have to use an expensive tableViewer.refresh() call to reflect the
>>> changes in the UI.
>>>
>>> I've looked through all the table/list snippets and I haven't seen an
>>> example doing this.
>>>
>>> What's the recommended way to accomplish it automatically?
>>>
|
|
|
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #327047 is a reply to message #327045] |
Mon, 07 April 2008 15:46 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Well you could use AspectJ and define a pointcut (if this is the right
term).
I also once filed a bug asking if Databinding could support an Adapter
approach this way one would not have to change all it's Beans.
Or instead of adding the listener code to your existing Beans converting
it to Ecore and let EMF generate the code for you. EMF provides a
Databinding-Implementation (in their CVS).
Tom
Tim H schrieb:
> Answering my own question here, looking at the source for
> PojoObservables, I see that the JavaBeanObservableMap that is returned
> has the attachListeners attribute set to false.
>
> It appears I was confused as to what exactly PojoObservables are, I was
> thinking I could have my cake and eat it too. Apparantly if I want to be
> able to listen to changes I need to use BeanObservables and implement
> Property Change Support.
>
> If that's the case, what exactly is the point of PojoObservables? Is it
> just to be able to bind, without listening so you don't have to see the
> annoying log messages?
>
> If someone could confirm that there is absolutely no way I can listen to
> changes on a bean without adding PropertyChangeSupport to all my pojo's
> then I'll go ahead and go down that road. But I'm still curious to what
> the actual point of PojoObservables are.
>
> Thanks,
> Tim
>
> Tim H wrote:
>
>> Thanks Tom,
>> So even though I'm calling PojoObservables.observeMaps to make an
>> IObservableMap[] that will not listen to changes the same way one
>> created with BeanObservables will?
>
>> Tom Schindl wrote:
>
>>> Well ObservableMapLabelProvider listens for property changes and
>>> calls update(Object,String[]) for the viewer but because you are
>>> using POJOObsevables there are no change events generated by your
>>> obervables. You should consider using BeanObservables.
>
>>> Tom
>
>>> Tim H schrieb:
>>>> I've been playing around building a simple CRUD with JFace
>>>> Databinding. I've hit one snag.
>>>>
>>>> I'm using the latest from CVS-Head with PojoObservables, I want my
>>>> TableViewer to automatically refresh changes when the contents of my
>>>> WritableList change. I have no problem when I add/delete from the
>>>> list. However when I make changes (updates to elements in the
>>>> wrapped list) I have to use an expensive tableViewer.refresh() call
>>>> to reflect the changes in the UI.
>>>>
>>>> I've looked through all the table/list snippets and I haven't seen
>>>> an example doing this.
>>>>
>>>> What's the recommended way to accomplish it automatically?
>>>>
>
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #327048 is a reply to message #327045] |
Mon, 07 April 2008 16:50 |
Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
Tim H wrote:
> Answering my own question here, looking at the source for
> PojoObservables, I see that the JavaBeanObservableMap that is returned
> has the attachListeners attribute set to false.
>
> It appears I was confused as to what exactly PojoObservables are, I was
> thinking I could have my cake and eat it too. Apparantly if I want to be
> able to listen to changes I need to use BeanObservables and implement
> Property Change Support.
>
> If that's the case, what exactly is the point of PojoObservables? Is it
> just to be able to bind, without listening so you don't have to see the
> annoying log messages?
Correct.
> If someone could confirm that there is absolutely no way I can listen to
> changes on a bean without adding PropertyChangeSupport to all my pojo's
> then I'll go ahead and go down that road. But I'm still curious to what
> the actual point of PojoObservables are.
That is correct. BeansObservables looks for the following methods to
see whether your bean has property change support:
void addPropertyChangeListener(String propertyName,
PropertyChangeListener listener)
void removePropertyChangeListener(String propertyName,
PropertyChangeListener listener)
void addPropertyChangeListener(PropertyChangeListener listener)
void removePropertyChangeListener(PropertyChangeListener listener)
Here is the usual pattern I have in value properties:
public void setName(String name) {
firePropertyChange("name", this.name, this.name = name);
}
With collections properties it takes a little more work, since the old
and new property values must be full copies of the collection in the
before and after state, so that DataBinding can compute a diff:
public void setItems(List items) {
// standard sanity checks here..
Object oldValue = new ArrayList(this.items);
this.items = items;
Object newValue = new ArrayList(this.items);
firePropertyChange("items", oldValue, newValue);
}
Matthew
>
> Thanks,
> Tim
|
|
|
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #327049 is a reply to message #327048] |
Mon, 07 April 2008 15:59 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Matthew Hall schrieb:
> Tim H wrote:
>> Answering my own question here, looking at the source for
>> PojoObservables, I see that the JavaBeanObservableMap that is returned
>> has the attachListeners attribute set to false.
>>
>> It appears I was confused as to what exactly PojoObservables are, I
>> was thinking I could have my cake and eat it too. Apparantly if I want
>> to be able to listen to changes I need to use BeanObservables and
>> implement Property Change Support.
>>
>> If that's the case, what exactly is the point of PojoObservables? Is
>> it just to be able to bind, without listening so you don't have to
>> see the annoying log messages?
>
> Correct.
>
>> If someone could confirm that there is absolutely no way I can listen
>> to changes on a bean without adding PropertyChangeSupport to all my
>> pojo's then I'll go ahead and go down that road. But I'm still curious
>> to what the actual point of PojoObservables are.
>
> That is correct. BeansObservables looks for the following methods to
> see whether your bean has property change support:
>
> void addPropertyChangeListener(String propertyName,
> PropertyChangeListener listener)
> void removePropertyChangeListener(String propertyName,
> PropertyChangeListener listener)
> void addPropertyChangeListener(PropertyChangeListener listener)
> void removePropertyChangeListener(PropertyChangeListener listener)
>
> Here is the usual pattern I have in value properties:
>
> public void setName(String name) {
> firePropertyChange("name", this.name, this.name = name);
> }
>
> With collections properties it takes a little more work, since the old
> and new property values must be full copies of the collection in the
> before and after state, so that DataBinding can compute a diff:
>
> public void setItems(List items) {
> // standard sanity checks here..
> Object oldValue = new ArrayList(this.items);
> this.items = items;
> Object newValue = new ArrayList(this.items);
> firePropertyChange("items", oldValue, newValue);
> }
>
Why do you allow list values to be set? I never let the user from the
out-side directly set or modify list values. I only allow users to
add/remove items. One of the reasons is that my models are normally
bidirectional and keeping them up-to-date this way is easier.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #327051 is a reply to message #327049] |
Mon, 07 April 2008 18:02 |
Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
Tom Schindl wrote:
> Matthew Hall schrieb:
>> Tim H wrote:
>>> Answering my own question here, looking at the source for
>>> PojoObservables, I see that the JavaBeanObservableMap that is
>>> returned has the attachListeners attribute set to false.
>>>
>>> It appears I was confused as to what exactly PojoObservables are, I
>>> was thinking I could have my cake and eat it too. Apparantly if I
>>> want to be able to listen to changes I need to use BeanObservables
>>> and implement Property Change Support.
>>>
>>> If that's the case, what exactly is the point of PojoObservables? Is
>>> it just to be able to bind, without listening so you don't have to
>>> see the annoying log messages?
>>
>> Correct.
>>
>>> If someone could confirm that there is absolutely no way I can listen
>>> to changes on a bean without adding PropertyChangeSupport to all my
>>> pojo's then I'll go ahead and go down that road. But I'm still
>>> curious to what the actual point of PojoObservables are.
>>
>> That is correct. BeansObservables looks for the following methods to
>> see whether your bean has property change support:
>>
>> void addPropertyChangeListener(String propertyName,
>> PropertyChangeListener listener)
>> void removePropertyChangeListener(String propertyName,
>> PropertyChangeListener listener)
>> void addPropertyChangeListener(PropertyChangeListener listener)
>> void removePropertyChangeListener(PropertyChangeListener listener)
>>
>> Here is the usual pattern I have in value properties:
>>
>> public void setName(String name) {
>> firePropertyChange("name", this.name, this.name = name);
>> }
>>
>> With collections properties it takes a little more work, since the old
>> and new property values must be full copies of the collection in the
>> before and after state, so that DataBinding can compute a diff:
>>
>> public void setItems(List items) {
>> // standard sanity checks here..
>> Object oldValue = new ArrayList(this.items);
>> this.items = items;
>> Object newValue = new ArrayList(this.items);
>> firePropertyChange("items", oldValue, newValue);
>> }
>>
>
> Why do you allow list values to be set? I never let the user from the
> out-side directly set or modify list values. I only allow users to
> add/remove items. One of the reasons is that my models are normally
> bidirectional and keeping them up-to-date this way is easier.
>
> Tom
>
I was just trying to keep the example simple. When I don't want to
expose the list directly I do as follows:
public void addItem(Item item) {
Object oldValue = new ArrayList(items);
items.add(item);
Object newValue = new ArrayList(items);
firePropertyChange("items", oldValue, newValue);
}
Also, DataBinding requires the setItems() method to be present so that
changes to the JavaBeanObservablesList can be forwarded back to the bean
property.
Matthew
|
|
| | | |
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #329960 is a reply to message #327049] |
Fri, 11 July 2008 13:20 |
No real name
Messages: 113
Registered: July 2009 |
Senior Member |
|
|
Tom Schindl wrote:
> Matthew Hall schrieb:
>> Tim H wrote:
>>> Answering my own question here, looking at the source for
>>> PojoObservables, I see that the JavaBeanObservableMap that is
>>> returned has the attachListeners attribute set to false.
>>>
>>> It appears I was confused as to what exactly PojoObservables are, I
>>> was thinking I could have my cake and eat it too. Apparantly if I
>>> want to be able to listen to changes I need to use BeanObservables
>>> and implement Property Change Support.
>>>
>>> If that's the case, what exactly is the point of PojoObservables? Is
>>> it just to be able to bind, without listening so you don't have to
>>> see the annoying log messages?
>>
>> Correct.
Is it worth consolidating this mechanism into a reflection based check?
There are 3 scenarios now: a) no property change support, b) java bean
property support, c) eclipse property change support (uses different
event and listener signatures than j2se but are very similar). I know
that jgoodies does a reflection check for convenience reasons and
attaches or does not attach based on it. It makes the number of
interfaces a bit smaller.
>>
>>> If someone could confirm that there is absolutely no way I can listen
>>> to changes on a bean without adding PropertyChangeSupport to all my
>>> pojo's then I'll go ahead and go down that road. But I'm still
>>> curious to what the actual point of PojoObservables are.
>>
>> That is correct. BeansObservables looks for the following methods to
>> see whether your bean has property change support:
>>
>> void addPropertyChangeListener(String propertyName,
>> PropertyChangeListener listener)
>> void removePropertyChangeListener(String propertyName,
>> PropertyChangeListener listener)
>> void addPropertyChangeListener(PropertyChangeListener listener)
>> void removePropertyChangeListener(PropertyChangeListener listener)
>>
>> Here is the usual pattern I have in value properties:
>>
>> public void setName(String name) {
>> firePropertyChange("name", this.name, this.name = name);
>> }
>>
>> With collections properties it takes a little more work, since the old
>> and new property values must be full copies of the collection in the
>> before and after state, so that DataBinding can compute a diff:
>>
>> public void setItems(List items) {
>> // standard sanity checks here..
>> Object oldValue = new ArrayList(this.items);
>> this.items = items;
>> Object newValue = new ArrayList(this.items);
>> firePropertyChange("items", oldValue, newValue);
>> }
>>
>
> Why do you allow list values to be set? I never let the user from the
> out-side directly set or modify list values. I only allow users to
> add/remove items. One of the reasons is that my models are normally
> bidirectional and keeping them up-to-date this way is easier.
>
> Tom
>
|
|
|
| Re: [DataBinding] Getting TableViewer to auto-refresh on changes to WritableList [message #329973 is a reply to message #329960] |
Fri, 11 July 2008 16:39 |
Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
aappddeevv wrote:
> Is it worth consolidating this mechanism into a reflection based check?
> There are 3 scenarios now: a) no property change support, b) java bean
> property support, c) eclipse property change support (uses different
> event and listener signatures than j2se but are very similar). I know
> that jgoodies does a reflection check for convenience reasons and
> attaches or does not attach based on it. It makes the number of
> interfaces a bit smaller.
The reflection-based check for listener registration is already present.
The difference between BeansObservables and PojoObservables is that
BeansObservables expects the methods to be there, and if they are not it
logs or emits an error message to the console. By contrast,
PojoObservables does not expect those methods to be present and so
doesn't attempt to register listeners. Thus PojoObservables will fire
change events when those changes are made through the observable's API,
but not when those changes are made directly on the POJO.
As for your scenarios listed above:
a) This will be implicitly supported in the IProperty APIs that we are
working on as part of bug 194734. In the case of objects with no change
listener support, the property implementer can simply implement the
addListenerTo(source) and removeListenerFrom(source) methods as no-ops.
b) and c) Java bean (and POJO) properties are just one kind of property
that we support. We also support properties of SWT widgets and JFace
viewers. In addition, the EMF framework has its own set of observables
for observing EStructuralFeatures of EObjects. I believe there's also a
project called UFace which supports GWT widgets. All of these objects
use different patterns for property access and mutation and for
registering listeners on those properties. This is the reason we are
working on bug 194734: to extract the property access / mutation /
listening concerns into a strategy object, while providing compliant
observables that work with these properties strategies.
If this is important to you, I would invite you to help us put together
a solid property abstraction API. I see you already commented on bug
194734; please take the time to review the attached patches and make
suggestions on how to evolve the API.
Matthew
|
|
|
Goto Forum:
Current Time: Mon Jan 13 21:38:58 GMT 2025
Powered by FUDForum. Page generated in 0.03617 seconds |
] 
Search
Help
Register
Login
Home
