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

[Alexander Ziegler <alexander.ziegler@xxxxxxxxxxxx>]

Hi Wanya,

Thanks for your answer.


Am 24.06.08 10:42 schrieb "Gayk Wanja" unter <Wanja.Gayk@xxxxxxxxxxxx>:

> 
> 
> 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.
Maybe not care to much but we can't ignore this UC. I think e.g. that a
ridget could provide a API #isValid or #isInputValid. A developer could call
this API during a storing event and handle it by himself.
 
>>> 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);

Ok. This is cool.

Alexander