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

[Greg Chicares]

On 2011-11-23 16:09Z, Boutin, Wendy wrote:
> 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,

The code is there:

    IssueAge.minimum_and_maximum
        (static_cast<int>(database_->Query(DB_MinIssAge))
        ,static_cast<int>(database_->Query(DB_MaxIssAge))
        );

It's just commented out (for reasons that never were very good)...

> so it isn't something we would probably
> focus on now unless Greg thinks otherwise.

...so let's not use that particular example. Instead let's consider this:

>>> 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.

Apparently this has been working the way we want since 20111214T0047Z.

It's important to point out that age and date of birth are two aspects
of the same thing (though the former is precise to the year and the
latter to the day), so one must dominate the other. Sometimes the user
wants age to dominate, and sometimes not--that's why we have a "UseDOB"
switch.

>> 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.

Let me clarify. Some range constraints are enforced in the GUI; others
are enforced downstream when the user attempts to run an illustration.
All constraints belong in the GUI; we just haven't had the resources to
enforce them all there. More precisely, constraints are expressed in the
MVC Model; any constraint that's not expressed there isn't enforced by the
MVC Controller for the tabbed dialogs, and cannot reasonably be enforced
by the census editor either.

Some input comes not through the GUI but from external systems; an xml
schema would be one way to test such external input for gross errors.