5.7 *report

[Bruce Easton]

On 12/20/13 9:50 PM, Bruce Easton wrote:
> On 12/20/13 1:50 PM, Mike Schwartz wrote:
>>> While I'm on the topic of web pages, am I the only one who resents having
>> to
>>> scroll through a column with a mouse instead of just typing the two
>>> characters of my state?
>>>
>>> --
>>> JP
>>        That urks me, too.  In many web sites that have a state field, you can
>> at least type the first letter of your state, but you still have to use the
>> mouse, unless your state is the first one that starts with any given letter.
>> When I type "W", "WA" pops up, so I still have to use the mouse to select
>> "WI".  If I try to type "W" then "I", the popup box jumps to "IA".
>>
>>         For example, jump to the state field on this website:
>>
>> https://www.tigerdirect.com/secure/subscribe2.asp?cm_sp=Masthead-_-NewCustom
>> er-_-NA
>>
>>         "W" takes me to "Washington", but if I then type "I" it takes me down
>> to "International".   I can avoid using my mouse if I type "W" and then down
>> arrow twice, to get past West Virginia.
>>
>> Mike Schwartz
>>
>>
> Yes.  I code for web apps for this issue in different ways depending on
> the circumstances.  Some clients want to track a limited set of states
> within which they do business.  So I have found it to be more user
> friendly to maybe build a limited state file, but rather than supply a
> select list, I will allow entry of the two-letter code, usually though
> with accompanying Ajax/JSON to apply either a custom edit or a lookup to
> said limited state file upon leaving the field. The client in this case
> usually knows all the codes for the states that they do business in.  On
> the other hand, if it's a completely generic state database that
> includes territories and APO? zones, where the client or their customers
> are all over the place, then they tend to like the pull-down. (It seems
> odd because it's a bigger list - it's just that they are not likely to
> know the states codes they may need to enter).
>
> One thing to consider is if the client is, as a regular practice,
> importing data from elsewhere that includes state field(s).  If the data
> is regularly not trustworthy and preserving existing data is of ultimate
> importance, then obviously you want to bring it in and display it as-is
> in some way without the chance that an edit will blank the field or that
> a simple select list will just show a bad value as blank.  In this case,
> I almost always just show the data value as-is in a text type form field.
>
> Bruce
>
>
I mentioned using Ajax/JSON for immediate validation of a limited set of 
states. If you are using filepro to build your output document along 
with Javascript, then you can also just build the limited array of 
states at the same time (reading a state file if desired), and then the 
validation can all be just in a Javascript function on the same document 
- no need to do additional http requests to validate.  (I mentioned the 
Ajax/JSON because for the tool that I use - for the form field, I just 
check a field that says I want to apply a filepro/custom edit and in 
another field just give the edit name, and the then when the program 
renders the page, it assumes that form field will validate the field 
onBlur using the given edit and length.)

Bruce