| RE: [riena-dev] Comments regarding Validation |
Hi Elias,
> 1. I'm not sure what exactly you mean with 'highlight'. Is that an error or warning marker shown
> next to the widget? Is that some characters in the text widget being highlighted? The first should
> be possible; the second is currently not possible, because we do not have a way to know which
> characters in the input are invalid (this is information that each rule would have to provide).
Oh, I guess was not clear there. With "highlight" I meant markers and things alike. I thought of validating the complete input, not parts of it, but you bring up a very nice point there:
Do we need to highlight parts of the input? If we want that, I think the information ("failure at character x to y") would be something we could put into the result of the rule, and in my opinion that should default to the whole input. One thing one must care about there - and maybe we could enforce that by design, is that that should not result in rules having some inner state which harms their thread safety. Also as some input may be wrong at, for example, character 1 to 3 and character 9 to 11, the result would need to contain some (unmodifiable) set of ranges.
Alas I guess it means a lot of work to support that type of highlight in every ridget and it would surely boost the complexity of some rules.
The idea is great though and I do think it's worth the effort.
> 2. I believe the original motivation for having different validation times (on_edit vs on_update) > was that some validations can be too expensive to be performed on every keystroke. Nevertheless
> implementation would be simpler if we only supported one validation time (for example on edit).
> Currently the rules seem pretty straightforward in terms of "expensiveness" but I'm sure there are
> more complex examples in the wild.
True. I could imagine a validation rule that queries a database, for example some "known customer"-rule. The good thing is: if we gave the rules some individual parameter which tells when the rules is supposed to be checked, that would be no problem. It would not make the rules very complex, in the end it's just a setter or a constructor parameter. Do we evaluate the validation time at the moment? I'm not quite sure at the moment.
> 3. Assuming that we want different validation times: Maybe the validation time should be passed as
> a constructor argument instead of being set via inheritance (as currently). Having to subclass a
> rule to change validation time seems a bit awkward. The constructor argument also forces the
> developer to make a choice WHEN to validate.
I'd vote for a constructor parameter. First because I don't think the rule's class should decide when it's evaluated (speaking against inheritance), second (speaking against a setter) because I don't think that the value would or even should change during the rule object's lifetime, so it can be a final immutable value, which is one thing less to consider regarding thread safety.
> 4. Regarding the rule's constructor: one idea would be to use the '|' operator to be more swt-
> like: new MinLength(3, IRidget.Hints.TRIGGER_DIALOG | IRidget.Hints.TRIGGER_ERROR_HIGHLIGHT);
> However I'm open to either style and the '|' operator places some constraints on the values used
> for the constants.
I wouldn't vote against it, since Riena is in the Eclipse world an SWT style is not too far fetched.
To add one more choice, there's would also be a fluent approach:
new MinLength(3, IRidget.Hints.TRIGGER_DIALOG.and().TRIGGER_ERROR_HIGHLIGHT);
But since that's a rather unusual style, I guess that's not the best idea.
I'd like to add that I was only thinking out loud at the moment. Or current concept of markers maps rules to markers, that's very different. Thinking of that, I guess a "dialog" could be a special marker then and if input was rejected would be probably better decided from the type of marker mapped to the rule. So I'm afraid discussing which style to chose there is a waste of time anyway. I should have thought about that before sending the mail, sorry.
Regards,
Wanja