I do validate property change same way as you described. Form fields have
validators or so, right?

On 30 January 2010 01:16, Eric <[email protected]> wrote:

>
>
> On Jan 29, 1:45 pm, Alexander <[email protected]> wrote:
> > You mean you want to abandon event? Stop handlers to receive it?
> >
>
> A Java bean (in the JDK world) can have a constrained property; the
> bean would have a set of VetoableChangeListeners and a set of
> PropertyChangeListeners.When something wants to change the property
> value, the bean should fire a PropertyChangeEvent to all the
> VetoableChangeListeners, and if any one of them throws an exception
> the change should be abandoned.
>
> Here's slightly old-fashioned code from
> http://www.exampledepot.com/egs/java.beans/Constrain.html:
> int myProperty;
> public int getMyProperty() {
>    return myProperty;
> }
> public void setMyProperty(int newValue) throws PropertyVetoException {
>    try {
>        vceListeners.fireVetoableChange(
>            "myProperty", new Integer(myProperty), new Integer
> (newValue));
>        myProperty = newValue;
>    } catch (PropertyVetoException e) {
>        throw e;
>    }
> }
>
> // Create the listener list.
> VetoableChangeSupport vceListeners = new VetoableChangeSupport(this);
>
> // The listener list wrapper methods.
> public synchronized void addVetoableChangeListener
> (VetoableChangeListener listener) {
>    vceListeners.addVetoableChangeListener(listener);
> }
> public synchronized void removeVetoableChangeListener
> (VetoableChangeListener listener) {
>    vceListeners.removeVetoableChangeListener(listener);
> }
>
> So, the use case here is that the user wishes to make a change to a
> GUI widget, but he may enter an out-of-range value, or may violate a
> uniqueness constraint, or may violate any sort of business rule.  Each
> rule should be governed by one ValueChangeHandler.  Suppose there are
> four handlers, the first two assents to the change, but the third
> reports a rule violation. Then, the fourth handler need not be
> invoked, the system should revert the user's change, and the system
> should notify the user of the problem.  If the event handlers could
> throw an exception, it would fit the JavaBean paradigm I'm used to.
>
> Is that paradigm counterproductive here? I keep wishing that I had
> available to me the list models and table cell renderers JDK Swing
> gives us. Yes, I know about the incubator project.
>
> Respectfully,
> Eric Jablow
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-web-toolkit%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>


-- 
Regards,
Alexander

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to