JavaBeanPropertyAdapter Reloaded
Michael Heinrichs
michael.heinrichs at oracle.com
Wed Jan 4 01:12:29 PST 2012
Hi Richard,
comments are inlined.
- Michael
On 03.01.2012, at 16:42, Richard Bair wrote:
> Hi Michael,
>
> I like the approach.
>
>> There are two new interfaces that define the common functionality of all JavaBeanProperty / ReadOnlyJavaBeanProperty instances:
>>
>> public interface ReadOnlyJavaBeanProperty<T> extends ReadOnlyProperty<T> {
>> void fireValueChangedEvent();
>> void dispose();
>> }
>>
>> public interface JavaBeanProperty<T> extends ReadOnlyJavaBeanProperty<T>, Property<T> {}
>>
>> The method fireValueChangedEvent() can be called to notify the adapter that the Java Bean property changed in case it does not support change listeners. The implementation uses WeakReferences and some automatic cleanup, if there are no references to the property left. But if you want more control, you can call dispose() on an adapter to remove all hooks to the bean.
>
> Under what circumstance would I want to manually call dispose?
>
Right now I know about two cases, the first rather theoretic for now. If JavaFX will be ported to a platform that does not support WeakReferences, you have to clean up everything yourself. All of the classes in the Property and Binding API use WeakReferences and usually one does not have to remove listeners, unbind things etc. But all of them also allow to manually clean thing up, in case the default solution is not supported on a platform.
The second more real case for now is testing. If you have some functionality that needs to be executed on clean up, you can enforce it manually.
>> And finally the really interesting part, the builders. There are two possibilities to use them. If you need to create an adapter for the same property of a collection of beans, you should first create the builder and then call createXYZProperty() for each bean. If you need to create just one adapter, there are static methods to do everything with a single call.
>
> Ok, so his is the mechanism that Jonathan's cell value factory implementation would use.
Right, assuming all rows/cells are based on the same bean class, you should create only one Builder.
>
>> public final class ReadOnlyJavaBeanPropertyBuilder {
>> public static ReadOnlyJavaBeanBooleanProperty createBooleanProperty(Object bean, String propertyName) throws NoSuchMethodException {...}
>> public static <T> ReadOnlyJavaBeanObjectProperty<T> createObjectProperty(Object bean, String propertyName) throws NoSuchMethodException {...}
>> // same for all other types
>>
>> public ReadOnlyJavaBeanPropertyBuilder(String propertyName, Class<?> beanClass) throws NoSuchMethodException {...}
>> public ReadOnlyJavaBeanPropertyBuilder(String propertyName, Class<?> beanClass, String getterName) throws NoSuchMethodException {...}
>> public ReadOnlyJavaBeanPropertyBuilder(String propertyName, Class<?> beanClass, Method getter) {...}
>>
>> public ReadOnlyJavaBeanBooleanProperty createBooleanProperty(Object bean) {...}
>> public <T> ReadOnlyJavaBeanObjectProperty<T> createObjectProperty(Object bean) {...}
>> // same for all other types
>> }
>>
>> public final class JavaBeanPropertyBuilder {
>> public static JavaBeanBooleanProperty createBooleanProperty(Object bean, String propertyName) throws NoSuchMethodException {...}
>> public static <T> JavaBeanObjectProperty<T> createObjectProperty(Object bean, String propertyName) throws NoSuchMethodException {...}
>> // same for all other types
>>
>> public JavaBeanPropertyBuilder(String propertyName, Class<?> beanClass) throws NoSuchMethodException {...}
>> public JavaBeanPropertyBuilder(String propertyName, Class<?> beanClass, String getterName, String setterName) throws NoSuchMethodException {...}
>> public JavaBeanPropertyBuilder(String propertyName, Class<?> beanClass, Method getter, Method setter) {...}
>>
>> public JavaBeanBooleanProperty createBooleanProperty(Object bean) {...}
>> public <T> JavaBeanObjectProperty<T> createObjectProperty(Object bean) {...}
>> // same for all other types
>> }
>
> How do these fit with the existing builders that are generated? Do these use the same semantics / naming pattern / implement the same interface?
>
No, right now they use a different pattern. I am undecided, if we should enforce the same pattern. A Java Bean adapter requires some mandatory parameters for which there are no default values. AFAIK there is no special treatment for such parameters in the builders, which means we cannot check during compile time, if all mandatory parameters were set. With the approach above on the other hand, you are forced to specify the mandatory parameters in the constructor / create()-method.
JavaBeanBooleanPropertyBuilder.create().propertyName("x").bean(obj).build();
If we would use the same pattern, we would only be able to check during runtime, if the propertyName was set for example. (Note that we would also need a builder for each type, which is probably not a bad idea anyway.)
Do you think, we we should drop the compile time check to gain the more familiar pattern?
> Thanks
> Richard
>>
>> What do you think?
>>
>> Thanks,
>> Michael
More information about the openjfx-dev
mailing list