Open GoogleCodeExporter opened 9 years ago
I was experimenting with those filters and run into usability issue with with
filed State because isState validation
requires a strict upper-case input; so if a user enter 'ca' the filter, the
validation reject it, but the filter re-
display 'CA' wich is confusing.
I agree that if data are cannonicalized (is that a word?) during validation
filters are not necessary. Most of the
forms in commercial website try to do that, most of then via JavaScript code on
the client side.
So 1+2 or 3 are the choices.
Original comment by jerome.c...@gmail.com
on 14 Jun 2009 at 9:24
A comment first to help establish where I come from on this...
I have worked with several small businesses (<5 people in the front office) and
have
found that for various reasons they like to 'screw around' with capitilization.
As a
consequence, I tend to try to find a solution that doesn't impose a convention
and
let them do whatever they like. I also think that there are some hidden
difficulties. E.g., Mary jane as a first name; STE or PO as address
abbreviations.
Also, what happens when users input items in all caps: "JOSEPH".
Given that, I would propose the following as a comprehensive solution to this
issue
and issue #1:
First, I would provide a getStates() method in Utilities that returns a list of
states. The validation routine would use this to get the list and the View
would use
it to construct a drop down box. As a consequence, for the states there is no
longer
a need to change the canonical form (and for that matter, we could eliminate the
state validation routine.)
Second, even though the filters are cool, I would eliminate the ones that
change the
case of what the user inputs. This eliminates the issue of mis-identifying
edits
when none have occurred.
Third, I would provide two special search fields in the database to use when
searching for duplicate records. These would be lower case versions of the
first_name and the last_name fields. I thought about the possibility of
combining
this into a single field, but realized that Find Customer provides the option of
trying to look up all customers with just a given first name or just a given
last
name, so these really need to be separated. In theory, we would provide this
'hack'
for the address, phone, and email fields as well, but I think we can stop with
the
first and last name fields and document the rest.
Original comment by bd.gai...@gmail.com
on 14 Jun 2009 at 10:40
I'm going to start implementing the drop down menu for the list of states in
CustomerSubview and customerSubview.htmland removes filters elsewhere. ~j
Original comment by jerome.c...@gmail.com
on 15 Jun 2009 at 12:05
Original issue reported on code.google.com by
bd.gai...@gmail.com
on 14 Jun 2009 at 8:38