Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Now I think that every widget should be able to have validators. Some use cases:
- on a form, to perform some inter-field validations, and even application-level validation if the means to access application data is given to the validator.
- on a repeater, to check e.g. uniqueness of some values among rows
- on a group (i.e. "class", "struct", etc) where some validation between the various widgets of the group may be wanted (actually, a form is a group)
+1. I presume that it will be possible to define form-/repeater- level validators in form definition file, as well as set them from Java. Am I right?
By "set them from Java", do you mean setting validators for a particular instance of a form?
Yes, same as what you can currently do in JS by setting form.validator.
What are the use cases behind this?
Same as for JS stuff, but if you use forms in Java.
Is it to allow communication between the form and the application context?
I was thinking more about in terms of providing a way to set some custom validators.
If yes, what do you think of special "value-holder" widgets that would expose the communication contract between the form and the application?
The current ValidationRule interface is not suited for this, as it is really tied to widgets that have a value, which neither form nor repeater have.
So my idea is to introduce a generalized "WidgetValidator" with a single "validate(Widget w, FormContext ctx)" method. The current ValidationRule implementations we have today can then simply become subclasses of a "FieldValidator" abstract class.
No objections. What about suggestion to allow nested validators?
Thinking a bit more about this, I think we must clearly define the semantic of nesting: obviously, if the parent validation succeeds, child validators are checked. But what if the parent validator fails? Does the form fail or do we simply ignore the child validators?
If the widget validator fails - then form validation fails, and form presented to the user again, right? And even right now, if one validator fails, sibling validators on the same widget are not tested. Hmm... May be nesting is not needed....
I think we're actually seeing the birth of a "if" validator that would allow conditional validation...
Anyway, the generalized validator will make this possible. So let's do it one step at a time.
No prob
Vadim
