Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [riena-dev] Comments regarding Validation [revisited]

Title: RE: [riena-dev] Comments regarding Validation [revisited]

Hi,
just some more thoughts, as I'm back from a meeting where I could see some of the validation issues in the sample application live.

One thing was for example a "required" field rule (I guess MinLength(1)), which would return "false" on empty inputs.
First the textfield looked like this:
[      ]
now entering something resulted in this:
[ABCD  ]
trying to delete all the letters again resulted in this:
[A     ]
What happened? Well, the ridget stopped the user from doing something which was not correct (according to the rule), since there something was supposed to be in there, the "A" could not be deleted anymore.

Of course this is not desired, since a user should always be able to correct his input, without being withheld by the application.
As a result a ridget must not stop the user from making wrong input, at least temporarily.
What it must do is take care that wrong input won't make it to the model though.

Now it was suggested, that some rules should accept a "partial" input, like "an input was 'on its way to be correct'", and suggested IIRC, that we should split some rules in rules which allow incomplete input and some which don't. To be honest, I don't really subscribe to this concept.
Even the idea of some flags for that purpose leaves a bad taste on my tongue, or is it just me?
In my opinion it's not the rules which have to be "soft", but it's the ridgets which have to decide how to handle the result of a rule check.
In the end a user's input is correct or not and nothing in between.

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.

Like I said in a previous mail, I think the handling of the rules should be in the ridget's hands and the hints how to treat the rules could also be the markers, which we already have.
Just imagine a general behaviour for all ridgets like this:
ridget.addRule(new MinLength(5), new WarningMarker()); //don't block input, just warn
ridget.addRule(new MinLength(5), new ErrorMarker()); //block input and indicate error
ridget.addRule(new MinLength(5), new BlockingMarker()); //invisibly block input

Of course that would make no sense, it should just show that 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.

As I said, just sketches directly from my brain to the keyboard, unfiltered.
Comments are of course welcome.

Regards,
Wanja


Back to the top