lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Direct drill-down census editor testing


From: Boutin, Wendy
Subject: Re: [lmi] Direct drill-down census editor testing
Date: Wed, 23 Nov 2011 11:09:55 -0500

On 2011-11-23 08:37, Václav Slavík wrote:
[share examples]
> On 20 Oct 2011, at 14:36, Wendy Boutin wrote:
>> Input validation:
>>
>> 6. There isn't any input validation in the census view. It really
>> needs to have the same level of input validation that's currently
>> in the individual cell input screens. For example, 'IssueAge' can

First off, I really meant "can't" instead, in case that matters.

>> be 99 for a product that doesn't allow it,

After carefully crafting an example for you, I'm realizing the
product-level behavior I seek is observable only at runtime rather
than after committing the input change. The latter is an enhancement
we've desired for years, so it isn't something we would probably
focus on now unless Greg thinks otherwise.

>> or changing 'DateOfBirth'
>> doesn't update 'IssueAge' until the cell is edited with the individual
>> input dialogs.

I think this is something entirely different. I'd like to 
see the census view inputs change the same way as in the 
input dialog. To observe the desired behavior:

File | New | Census | Edit cell
- change year in DateOfBirth to some other year
- move focus to another control

The issue age updates to the age based on the new DateOfBirth 
and regardless of its enablement. It also happens vice versa.

> On 20 Oct 2011, at 19:11, Václav Slavík wrote:
>> Unfortunately, I don't know how to fix it. I couldn't find any validation 
>> code in the
>> editor files when I looked, my impression was that it's handled by
>> any_member<Input>::operator=(). Apparently, it isn't, what else do I need to 
>> do?
>
> Returning to my earlier message, I still don't understand how to validate the 
> data any
> better. All I could find eventually was MvcController::Validate(), but that 
> only deals
> with ranges as far as I can tell and those should already be constrained to 
> disallow
> entering invalid data [*].

Agreed. I think they disallow a certain level of invalid data, but the
validation doesn't penetrate to the product-level constraints until
runtime, AFAICT. If I have a correct full understanding, then I think 
our long term solution is to use a schema for that level of validation.



This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]