Introduction of capfirst filter generates problem

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enter a vehicle with the make "honda" (all lower case) and some value
for all other required fields.
2. Save the vehicle record
3. Click on the "Find Customer" button in side panel.

What is the expected output? What do you see instead?

Expect it to simply go to the Search form.  Instead it thinks the field
content has changed and puts up a dialog asking if changes should be saved.

The problem occurs because the capfirst filter in the vehicle template
changes the text that is displayed to show "Honda".  In the data store it
is "honda".  When the comparison is made between what is on the screen and
what is in the data store, the comparison is case sensitive, so it
indicates there is a difference and activates the save dialog.

We need to come to a consensus as to how we want to clean this up.
1. We can eliminate the capfirst filter and what the person enters is what
they see.
2. We can canonicalize the values in the database to match the capfirst
filter (which would eliminate the need for the filter anyway).
3. We can change the overloaded comparison operators for Customer, Vehicle,
& Workorder to be case insensitive.

Original issue reported on code.google.com by bd.gai...@gmail.com on 14 Jun 2009 at 8:38

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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