| RE: [riena-dev] Comments regarding Validation [revisited] |
Hi Alexander,
>> In the above example, I think the ridget should not stop the user from
>> writing, but just warn the user that the input was incorrect (with a border,
>> an icon, or something). It could block "writing through" to the model, as soon
>> as the input was not correct anymore, but it should not block the user from
>> writing on.
>> With direct writing, which would be the only troublesome case here, the ridget
>> should for example write values only as long as they were correct, so the last
>> correct input would be in the model, while the input in the textfield was
>> still dirty (and warned about). I'm not pretty sure if "direct writing" is so
>> desireable anyway, but this is how I would handle it, if it was up to me.
>> It would be up to the view then to decide, whether the user was allowed to
>> leave the form with some ridgets still having dirty input or not.
>
> I agree that the ridget should write values only as along as they are
> correct. To keep the last correct input in the model as long as the ridget
> input is incorrect could cause trouble. In some UC could be necessary to
> indicate that the value of the model was modified by the UI. In this case it
> could be necessary to set a user specific undefined-value into the model so
> that the business logic knows that the model was modified (from UI) but the
> input/value is incorrect.
>
> E.g. After deleting ABC then the view displays [ ] but in the model is
> 'A' (the last correct value). The user stores the model and closes the
> module or application. The UC allows to store models without any checks.
> Then the user opens the application and module again. What happens is that
> the view displays [A ] because this was the last correct state. But 'A' is
> logical not correct. Remember the user deleted all chars. That means that
> the user gets no hint from the application that some value is still
> incorrect.
First up: thanks for your feedback.
If the input was wrong according to the rule, the textfield would indicate
something's wrong anyway, which means in the example, deleting the
last character of a TextField with MinLength(1) would result in a marker showing up.
The vaue in the model would be [A], the textfield would show <!>[ ]<!> (warning marker).
No need for a specific undefined value there I guess.
You're right about the problem which arises from a use case which allows to store values
without checks, this is indeed be a problem. The marker would need to be able
to communicate the model's value,like:
<!>[ ]<!>(saving last correct value: "A")
What we're discussing is a corner case though: A UC which allows to store unchecked values
is an accident waiting to happen anyway, I'm not too sure if we should really care too much
about that. I mean: if the developer is deliberately seeking danger, he has to know what he's doing.
All we could do is maybe give him the option to force storing the value to the model, regardless
of what a rule says.
>> the ridget could
>> for example decide on the type of marker, not on the type of rule, whether
>> blocking of input was desired.
>>
>> For a better "closer to a real world usecase" example, imagine this:
>>
>> textRidget.addRule(new MinLength(1), new WarningMarker()); //don't block
>> input, just warn
>> textRidget.addRule(new MaxLength(10), new ErrorMarker()); //block input and
>> indicate error
>> textRidget.addRule(new LowerCaseText(), new BlockingMarker()); //invisibly
>> block input
>
>> In the above case, I'd use a WarningMarker, so the user could still delete the
>> last remaining "A", when trying to input more than 10 letters, he would be
>> stopped from typing any more and an error would flash on every attempt to do
>> so (like in the cirrect state of the demo application). Uppercase letters
>> would not be accepted at all, the user would type but nothing would happen.
>>
>> Note that I would personally dislike both of the blocking options, and
>> especially the last one (silently blocking), as I know users who would hammer
>> their keyboards and ask the hardware-support what's wrong with it or at least
>> get annoyed at the application.
>
>> Warning is a friendly thing: you get told you're wrong, you may temporarily be
>> wrong and as long as you fix it before leaving the form or application,
>> everything is fine. It even leaves the nice option to "misuse" a warning
>> marker as bookmark: Input something wrong, browse through some PDFs, return
>> and see where you've left off.
> I'm not sure whether it makes sense to differing in blocked (Warning) and
> unblocked (Error) markers. Like you explained above it makes sense to handle
> a MinLength 'soft' and MaxLenght 'hard' because this is user friendly. Do
> you see a UC to handle it different?
At the moment not, but I could not tell for every rule in the world a developper could think of.
This is why I think not the rule should decide whether it's "hard" or "soft" or whether
it should block the input or not, but the developer, by chosing an appropriate marker
(hint or whatever) to go along with the rule.
> To call the marker 'Warning' confuse me
> because it is an error whether the input is to short or to long.
"Warning" and "Error" was just the first Idea I came across.
Use any name you think is more appropriate, I'm not too picky about that.
One could call it "BlockingErrorMarker" or "NonBlockingErrorMarker" for example.
There's plenty of possibilities, like a constructor-argument in the marker, like:
new ErrorMarker(IMarker.BLOCK_USER_INPUT);
new ErrorMarker(IMarker.BLOCK_WRITE_TO_MODEL);
new ErrorMarker(IMarker.NON_BLOCKING);
Regards,
Wanja