Hi Megan or whoever else might know,

Now that we have implemented a numeric field, I wanted to add it to a
testplan, and got some questions in relation to that:

1) Is (or should be) the user be able to enter data other than numbers
into a numeric field (and perhaps a dot)
2) If yes on (1), will user be able to save or not (and if not - what
indication of faulty data entry is given)
3) If no on (1), what numbers/symbols are allowed to be entered (only
numbers and ".")? And does the logic include making sure only 1 "." is
entered, isn't in the start of the string, etc..
4) Do we differ between Integers and float fields

Some examples of data entries:

12345.12345
1.1234.123
12345
.12345
123e10
1234.

I realize the answers to some of these questions might yet be undecided..

~Kasper

_______________________________________________
Work mailing list
Work@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/work_lists.collections...

 

Expected behavior for wrong data entered

Yura coded the validation logic, so he can speak to what the code does now.

IMHO, an integer number field should just ignore any keystrokes other than
numbers (and it should let backspace, tab, etc. through to the normal
mechanism). A float number field would just add the period to the list of
allowed keystrokes. I would have a configurable variant to allow the minus
operator or not, and it should only be at the beginning of the string. This
approach would preclude a lot of the cases of illegal strings causing errors
and requiring user attention. I often see this behavior in web forms, and it
seems nice to me.

Patrick

Expected behavior for wrong data entered

Thanks Patrick,

if we indeed want to be able to specify whether a field is float or
integer and whether it is only positive or can be positive/negative, I
think this both requires some guidance (eg. CSPACE-4233 only specifies
that fields should be numeric, this would have to be further specified)
as well as some coordination between UI and APP - currently I think a
field can be numeric, text, controlled-vocab, etc.. This list would
either have to be extended to include eg "integer, "float",
"numeric-positive", etc.. Or have some extra properties specifying type
of numeric field..

Also, this is probably something we want to figure out before changing
all the fields of CSPACE-4233 to "numeric" :)

Other than that, the behavior you describe below seems very nice! It's
still unclear to me whether we are able to prevent the user from
entering any invalid data (eg. "123.1234.12333") or we have to do some
validation on submit too - and how an erroneous formatted field will be
marked in the UI.. But I guess Yura would know what is possible and
what's not..

In any case, this is probably not relevant until we decide what types of
numeric fields we want to support.

Thanks,
~Kasper

On 09/08/2011 09:21 PM, Patrick Schmitz wrote:
> Yura coded the validation logic, so he can speak to what the code does now.
>
> IMHO, an integer number field should just ignore any keystrokes other than
> numbers (and it should let backspace, tab, etc. through to the normal
> mechanism). A float number field would just add the period to the list of
> allowed keystrokes. I would have a configurable variant to allow the minus
> operator or not, and it should only be at the beginning of the string. This
> approach would preclude a lot of the cases of illegal strings causing errors
> and requiring user attention. I often see this behavior in web forms, and it
> seems nice to me.
>
> Patrick
>