JavaBeanPropertyAdapter

[Daniel Zwolenski]

I would vote for it not being limited if it doesn't cause problems anywhere
else. POJOs are much more common than full beans with ChangeListeners.

I think developers will be able to handle the out-of-synch issue if it is
well documented.

I do see a use for this whole idea in general and like it.


On Wed, Dec 14, 2011 at 11:01 PM, Michael Heinrichs <
michael.heinrichs at oracle.com> wrote:

> Hi Tom,
>
> that is a good question. The JIRA issue specifically asked for an adapter
> for beans with change listeners. I did not think much about this
> requirement. Question is, if this would really be simpler than attaching a
> ChangeListener that sets the property directly (especially ones we have
> lambda expressions). My main concern is, that you cannot be sure, if JavaFX
> property and POJO are in-sync unless you can somehow guarantee that nobody
> manipulates the POJO directly. But it is only a weak concern, I am curious
> to hear more opinions.
>
> - Michael
>
>
> On 14.12.2011, at 12:42, Tom Schindl wrote:
>
> > Would it be possible to also relax the restriction to not require the
> > "Bean" have a property change listener (then it is not a Bean anymore
> > but a simple POJO).
> >
> > This way a sync can only happen from UI to model but when we talk about
> > DTOs and stuff they normally tend to not be beans (they don't fire
> > property change events) and so could be used.
> >
> > Naturally in that case the nameing would be different and maybe this
> > would make a new request.
> >
> > Tom
> >
> > Am 14.12.11 12:24, schrieb Michael Heinrichs:
> >> Hi,
> >>
> >> I would like to add two new classes
> (javafx.beans.property.JavaBeanPropertyAdapter and
> javafx.beans.property.JavaBeanReadOnlyPropertyAdapter) to provide ready to
> use support for Java Bean integration (
> http://javafx-jira.kenai.com/browse/RT-14004). The names are just working
> titles, I am open to any suggestion.
> >>
> >> Both classes allow to create adapters for conventional Java Bean
> properties and map them to JavaFX Properties.
> >>
> >> The read only case is pretty straightforward. The Java Bean property
> has to be a bound, read-only property, i.e. it has to have a getter and
> support PropertyChangeListeners. I propose the following API:
> >>
> >> public class JavaBeanReadOnlyPropertyAdapter<T> {
> >>    public JavaBeanReadOnlyPropertyAdapter(Class<?> clazz, String
> propertyName);
> >>    public JavaBeanReadOnlyPropertyAdapter(Class<?> clazz, String
> propertyName, String getterName);
> >>    public JavaBeanReadOnlyPropertyAdapter(Class<?> clazz, String
> propertyName, Method getter);
> >>
> >>    public ReadOnlyObjectProperty<T> createProperty(Object bean);
> >>
> >>    public static <T> ReadOnlyObjectProperty<T> createProperty(Object
> bean, String propertyName);
> >> }
> >>
> >> To use it, one first has to create a JavaBeanReadOnlyPropertyAdapter,
> passing the class and the propertyName, if the Java Bean follows the Java
> Bean convention. If not, one can also pass in the name of the getter method
> or the getter directly. In a second step, one creates the property by
> calling createProperty(). The static method is for convenience, if only a
> single property is needed.
> >>
> >>
> >>
> >> The writable case is a little more complex, because we are not in full
> control of a Java Bean property. The Java Bean property has to be bound and
> writable. If you want to define a unidirectional binding for a Java Bean
> property, it also has to be constrained (i.e. support
> VetoableChangeListeners).
> >>
> >> Bindings for Java Bean properties will be slightly different than our
> usual bindings: they will be eager and they may become out-of-sync. Let's
> say we have a Java Bean Property p, that is bound to an ObservableValue v.
> Internally we hook a listener to v and propagate all changes to p by
> calling its setter (that is why it will be eager). If now p does not accept
> the value from v, p and v will be out-of-sync. Especially the last point
> bothers my, but I guess there is no way to ensure synchronization.
> >>
> >> The API and usage is similar to the read only case above. Only the
> method isBindable() is new, which returns true, if the Java Bean property
> is constrained and can therefore be bound unidirectionally. (If you try to
> define a unidirectional binding for a Java Bean property, that is not
> constrained, an UnsupportedOperationException is thrown in bind().)
> >>
> >> public class JavaBeanPropertyAdapter<T> {
> >>    public JavaBeanPropertyAdapter(Class<?> clazz, String propertyName);
> >>    public JavaBeanPropertyAdapter(Class<?> clazz, String propertyName,
> String getterName, String setterName);
> >>   public JavaBeanPropertyAdapter(Class<?> clazz, String propertyName,
> Method getter, Method setter);
> >>
> >>    public ObjectProperty<T> createProperty(Object bean);
> >>    public boolean isBindable();
> >>
> >>    public static <T> ObjectProperty<T> createProperty(Object bean,
> String propertyName);
> >> }
> >>
> >>
> >>
> >> What do you think?
> >>
> >> Thanks,
> >> Michael
> >
> >
> > --
> > B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
> > ------------------------------------------------------------------------
> > tom schindl                 geschäftsführer/CEO
> > ------------------------------------------------------------------------
> > eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
> > http://www.BestSolution.at                      phone    ++43 512 935834
>
>