Community
Participate
Working Groups
I have written an observable for objects that fire events to IPropertyChangeListeners. This is useful for those clients that may already have objects that fire those types of events and want to try out the databinding framework. I will attach a patch
Created attachment 119973 [details] Patch to add IProperyChangeListener based observable value
Oops, wrong copyright. I'll resubmit the patch the next chance I get.
Created attachment 120086 [details] Updated patch with proper copyrights and a snippet I've attached another patch for your consideration. I'm happy to incorporate any suggestions and release the fix myself but I don't want to do so without the eyes of a databinding person on this (since I don't play around much in the databinding framework). If you prefer to release the patch yourself, that's great too.
A few comments: * ObservableJFacePropertyValue should be named JFacePropertyObservableValue to align with existing naming conventions. * The above class should register a listener on the model in firstListenerAdded(), not in the constructor. It should remove the listener in lastListenerRemoved(). * In some cases the value type may be known to be more specific than the return type of the getter method. For this reason there should be an option to specify the value type in the observeProperty method. Overloading is an option. * Since the observable is in an internal package, the getFieldName() method will never be seen.
Boris, I can't make an objective evaluation of this patch since I'm not familiar with IPropertyChangeListener or how it is supposed to work with JFace. Please review this patch and, if you +1 the current observable implementation, send it back to me so I can convert it over to a property implementation.
Boris and Matthew, sorry about the lack of activity on my part on this. I haven't had much time to devote to this, I'm currently developing against Eclipse 3.3 and I've moved on to other areas so I haven't had a chance to revisit the patch.
I guess what I'm wondering is if the field name vs property name dichotomy is a common, standardized pattern in the platform. Specifically, can we reliably expect that the source object will have get[Field] / set[Field] methods (i.e. standard property method names) given a field name? Is this an established standard or just a convention? Is it common for the property name in the PropertyChangeEvent to disagree with the getter/setter method names as your patch implies?
There are no "standards" when it comes to objects that notify IPropertyChangeListeners of events. In most of the cases I've seen, most source objects have get[Field] / set[Field] methods but the property name does not correspond to the field name.
Boris, your call. I'm not familiar enough with IPropertyChangeListener to make an informed decision. If you +1, send it back to me and I'll port the patch over to the IProperty API.
Created attachment 127899 [details] updated patch This time using the new properties API. Matthew, could you have a look at this to hopefully catch any stupid mistakes I made?
Example: JFaceProperties.property("text", IAction.TEXT, Action.class)
Two things: * Let's rename JFaceProperties.property() to JFaceProperties.value() * To be consistent with the methods in BeanProperties let's change the order of arguments to (Class clazz, String fieldName, String propertyName)
Other than the above items, +1
done, thanks for the review. Example is now: JFaceProperties.value(Action.class, "text", IAction.TEXT).observe(someAction)
Boris, I was just wondering whether it was intentional to put the class JFaceProperties in the package "org.eclipse.jface.util" which does not include the "databinding" part?
Good catch!
moved into package org.eclipse.jface.databinding.util. Ovidio, I owe you a beer (or something else, if you don't drink alcohol)!
see comment 17
