Community
Participate
Working Groups
I think the WizardPageSupport class should be extended to track the staleness state of the target/model observables and the validation status observable of all the ValidationStatusProviders of the given DataBindingContext. When any of those observables is stale, the given WizardPage should be set to be not complete. This is required to correctly handle things like DelayedObservableValues or eventual asynchronous validations which can otherwise not to be reliably used in conjunction with the WizardPageSupport class.
Tracking the staleness of the status observables makes sense. I am not so sure about the model and target observables - under which circumstances would these be stale, and shouldn't we think about what this means for a binding, first?
Actually, my original intent was also to propose tracking the staleness of the validation status observable only. However, while writing the bug report, I have thought about the DelayedObservableValue which I think cannot be used reliably in conjunction with the WizardPageSupport class right now unless you wait for the delayed updates to have completed before allowing to eventually proceed in the wizard. That's why I thought that it might be beneficial to also track the staleness of the target observables. On the model side, I cannot think of a particularly relevant use case in practice. However, you're totally right that it might not be so good to (artificially) check for the staleness of the target/model observables in the WizardPageSupport class since, if at all, the problem should indeed be handled more fundamentally by the binding. As an example, if the target of a binding becomes stale, one could argue that the binding's validation observable (I'm not sure about the model observable) should also be marked to be stale. Indeed, I think this would make sense. So, I agree that the WizardPageSupport class should limit itself to tracking the staleness of the validation status observables only.
Makes sense. By the way, the delayed observable value also hooks a focus listener and will update itself eagerly when the focus is no longer on the target control - but I haven't tried what happens when you try to click Next or Finish in a wizard containing a delayed value. So ValueBinding would track the staleness of model and target (to make it symmetric) and make its status observable stale in response to that. Then WizardPageSupport would then track staleness of the status observable and mark the page as not complete. Would you like to contribute a patch?
(In reply to comment #3) > Makes sense. By the way, the delayed observable value also hooks a focus > listener and will update itself eagerly when the focus is no longer on the > target control - but I haven't tried what happens when you try to click Next or > Finish in a wizard containing a delayed value. I have also not tried it myself so I am not sure but I guess that at least as soon as you start using the key shortcuts to navigate in the wizard, it would not work reliably anymore. > So ValueBinding would track the staleness of model and target (to make it > symmetric) and make its status observable stale in response to that. Then > WizardPageSupport would then track staleness of the status observable and mark > the page as not complete. What about the (List|Set)Bingings? There's no real validation there but maybe it still makes sense to implement it analogously for those. > Would you like to contribute a patch? I will look at it. Shall I create a separate bug report for the binding part?
By the way, I guess that in that case the MultiValidator should also be adapted to track the staleness state of the observables accessed during the execution of the validate() method and propagate that staleness state to its status observable.
Created attachment 105654 [details] proposed patch for the WizardPageSupport part As agreed upon, only the staleness of the validation status observables is tracked.
I have created a separate bug report for the staleness of the validation status observable of a Binding/MultiValidator: bug #238909
Matthew, I had a brief look at bug #239900 where you seem to already track the staleness of the validation for the new DialogPageSupport class and its subclasses so this bug here may be obsolete by now.
(In reply to comment #8) > Matthew, I had a brief look at bug #239900 where you seem to already track the > staleness of the validation for the new DialogPageSupport class and its > subclasses so this bug here may be obsolete by now. True, but your patch contains tests so we should at least keep those.
Created attachment 115962 [details] Ovidio's patch merged with HEAD
Good thing we kept your patch--the new test caught a bug in DialogPageSupport. Released to HEAD > 20081023
Verified in I20081209-0100 by code inspection and by running test suite
