[Top][All Lists]
[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.