Opened 14 years ago

Closed 14 years ago

Last modified 11 years ago

#5919 closed defect (wontfix)

ValidationTextBox: subclasses return different getValues on invalid

Reported by: haysmark Owned by: Douglas Hays
Priority: high Milestone: 1.2
Component: Dijit - Form Version: 1.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

If you have a NumberTextBox? and enter some letters, getValue returns NaN as expected. If you give a ValidationTextBox? a regexp of d* (basically making it a NumberTextBox?) and enter some letters, getValue still returns the letters, instead of something like undefined like NumberTextBox?.

We should figure out what these textboxes should be returning when the value is invalid because right now it is inconsistent.

Change History (5)

comment:1 Changed 14 years ago by haysmark

Description: modified (diff)

comment:2 Changed 14 years ago by haysmark

MappedTextBox? seems to suffer the same problem as ValidationTextBox? and also returns the invalid string as-is. You would think MappedTextBox? would return undefined, more so than ValidationTextBox?, because *every* subclass of MappedTextBox? (DateTextBox?, FilteringSelect?, etc.) returns undefined or an equivalent for an invalid value.

comment:3 Changed 14 years ago by bill

Description: modified (diff)
Resolution: wontfix
Status: newclosed
Summary: ValidationTextBox subclasses return different getValues on errorValidationTextBox: subclasses return different getValues on invalid

I'm making an executive decision on this one:

As much as possible, getValue() *should* return an invalid string as-is. It shouldn't change behavior due to a field being required/not-required, invalid/valid. The only exception is when the widget maps the displayed value into another value, and there is no mapping (ex: "foo" for a NumberTextBox or "Japan" for a FilteringSelect of U.S. states), in which case getValue() should return the same thing it returns when the field is blank.

Also, getValue() should always return data of the same type. Either always strings, always numbers, or always Dates, where an empty date is represented as null (see #6827, #6922).

As for MappedTextBox, the reason it returns the string as-is is because the subclass needs to override certain methods. MappedTextBox by itself doesn't do any mapping.

comment:4 Changed 14 years ago by bill

(In [13989]) Support required=true/false parameter for FilteringSelect? so that a blank entry in the dropdown list is not necessary. Patch from Mark Hays (IBM, CCLA on file). Fixes #5974 !strict. Also some cleanup so that onChange() and getValue() return "" for when the input field is blank/invalid. (Before I had thought to return null in those cases but "" seems better.) Refs #5919.

comment:5 Changed 11 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.