Community
Participate
Working Groups
The current implementation of Data Binding assumes that all validation is fail fast and only one status can be reported. There's a proposal on the table for returning multiple statuses in forms and dialogs (see bug 168769). We need to make a decision on if we want to stick to the fail fast implementation for 1.0 or move to something to support the coming enhancements in forms and dialogs. Another thing to consider is validation policies. I was looking at implementing the explicit policy in ValueBinding and ran into an issue with the validation policy. The idea for this policy was to support validation in dialogs where we don't want to update the model automatically but we still want to perform validation as the user is entering the data. There's another use case of wanting to defer expensive validation until the user selects OK/Apply. The dialog validation and multiple statuses might be 2 separate issues but it might help to evaluate both when discussing this enhancement. Also this is a high priority as it effects API and 3.3M5 is the API freeze. I'm willing to start work on this this weekend (as long as no one else claims it) if necessary and as long as we can come to an agreement on what to do.
Boris, please call me at your convenience so we can discuss this.
Has anything come of this?(In reply to comment #1) > Boris, please call me at your convenience so we can discuss this. > Has anything come of this?
(In reply to comment #2) > Has anything come of this? No, not yet - thanks for the reminder.
I'd like to propose that we move forward with this before 1.0. The main reason is that I'd like to make the pipeline aware of IStatus.WARNING and IStatus.INFO and to define the pipeline behavior for these statuses. When either are returned from a validator I'd like for the pipeline to continue processing but to maintain them as the status for the binding. Further down the line if an IStatus.ERROR is encountered the process will terminate. The use case that I'm thinking about is duplicate checking. The end user is entering a phone number and the system should check for duplicates before proceeding. If a duplicate is found it doesn't necessarily mean that the current entry is invalid. It could just mean that further investigation is needed but the user can't be forced to perform that checking at this point in time. So we need to flag the data with a warning but still propagate the value to the model. What I'd like to propose is that if a status other than ERROR or CANCEL is returned from validation we proceed and maintain any status other than OK in a MultiStatus as the validation status for the binding.
(In reply to comment #0) > The dialog validation and multiple statuses might be 2 separate issues but it > might help to evaluate both when discussing this enhancement. The validation policy issues have been resolved in 3.3M6. > Also this is a > high priority as it effects API and 3.3M5 is the API freeze. I think this can be implemented without any new API and it would be the correct thing to do. The validation status would need to be a MultiStatus rather than just a Status.
(In reply to comment #5) > I think this can be implemented without any new API and it would be the correct > thing to do. The validation status would need to be a MultiStatus rather than > just a Status. +1 (make sure the severity of the multistatus reflects the most severe child status)
This has been approved by the PMC[1] to implement in 3.3M7. http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg00156.html
My patch from bug 147489 might be useful here.
(In reply to comment #6) > +1 (make sure the severity of the multistatus reflects the most severe child > status) > I'm assuming this means to reflect the other attributes as well (e.g. code, message, severity, and plug-in).
FIXED > 20070404.
*** Bug 136280 has been marked as a duplicate of this bug. ***
*** Bug 169979 has been marked as a duplicate of this bug. ***
VERIFIED in I20070502-1336.
