Re: [riena-dev] Comments regarding Validation [revisited]

[Alexander Ziegler <alexander.ziegler@xxxxxxxxxxxx>]

Hi Wanya,

Yust my thoughs...

Am 23.06.08 17:21 schrieb "Gayk Wanja" unter <Wanja.Gayk@xxxxxxxxxxxx>:

> 
> 
> 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.
I agree you that the application hasnt forbid deleting the last char. This
would block the user interaction.

> 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.
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.
 
> 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.
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? To call the marker 'Warning' confuse me
because it is an error whether the input is to short or to long.

What do you think?

Alexander