Re: Binding to a POJO
On Sat, 5 Mar 2011, Jim Janney wrote:
Tom Anderson <twic@urchin.earth.li> writes:
Okay, how about:
public class PropertyChangeUtils {
private static final PropertyChangeSupport support; // initialise this somehow
public static <T> T change(String propertyName, T oldValue, T newValue) {
support.firePropertyChange(propertyName, oldValue, newValue);
return newValue;
}
}
import static PropertyChangeUtils.change;
private String foo;
public void setFoo(Object foo) {
this.foo = change("foo", this.foo, foo);
}
The code in the setter is fractionally (well, ~25%) more complicated
than with your version, but there's no reflection, and you have static
type safety.
It does fire the property change event before actually changing the
property, though; i don't know enough about Swing to know if that
would be a problem.
That breaks what I see as the implicit contract for property change
events: a listener receiving a change event can reasonably expect to
call the object's getter and see the new value.
Do the listeners get notified synchronously inside the firePropertyChange
call, or does that queue up an event to be handled by the EDT once the
current event is over or something like that? If the former, then yes, my
idea is pretty poor.
More importantly, each object has its own set of listeners, and so needs
its own instance of PropertyChangeSupport to keep track of them: you
can't share a PropertyChangeSupport instance between objects.
Whoops. In that case, put the support variable in the bean (via a base
class, perhaps), and pass it to the helper function as a parameter.
tom
--
When the facts change, I change my mind. What do you do, sir? -- John
Maynard Keynes