Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #9772 > unrolled thread

Alert and Input Control Events

Back to article view | Back to comp.lang.javascript

Contents

  Alert and Input Control Events Gene Wirchenko <genew@ocis.net> - 2011-12-29 15:28 -0800
    Re: Alert and Input Control Events Stefan Weiss <krewecherl@gmail.com> - 2011-12-31 01:27 +0100
      Re: Alert and Input Control Events Gene Wirchenko <genew@ocis.net> - 2011-12-31 23:40 -0800
        Re: Alert and Input Control Events Gregor Kofler <usenet@gregorkofler.com> - 2012-01-01 12:02 +0100
          Re: Alert and Input Control Events "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-01-01 13:21 +0000
            Re: Alert and Input Control Events Gregor Kofler <usenet@gregorkofler.com> - 2012-01-01 16:55 +0100
          Re: Alert and Input Control Events Gene Wirchenko <genew@ocis.net> - 2012-01-02 10:49 -0800
            Re: Alert and Input Control Events Scott Sauyet <scott.sauyet@gmail.com> - 2012-01-03 04:54 -0800
              Re: Alert and Input Control Events Gene Wirchenko <genew@ocis.net> - 2012-01-03 17:13 -0800

#9772 — Alert and Input Control Events

Dear JavaScripters:

     Does using alert() cause input control events to fire?

     I am writing some validation routines where I want the control to
keep the focus if the test fails.  (Yes, I know that this is
desktop-app style.  That is what I want.)

     Actually, if onblur fires, the focus has already moved.  To get
around this, I have a global that is set if validation is already
occurring on another input control.  In that case, I simply bypass the
validation on the second control so that the focus can be set back.

     This works (IE 9 & Windows 7).

     It seems that the order of statements is important.  I have to
set the focus back before generating the error alert.  Otherwise, it
does not work right, and I can get the other input control's
validation routine getting in the way.  I also had the hilarity of my
debugging alert() statements affecting the program flow.

     It seems to me that alert() might cause input control events to
fire.  Is this so?  If so, is it guaranteed to be like this, or is it
just IE 9's implementation?  How tied to implementation is this error
handling making my code?

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#9819

On 2011-12-30 00:28, Gene Wirchenko wrote:
>      I am writing some validation routines where I want the control to
> keep the focus if the test fails.  (Yes, I know that this is
> desktop-app style.  That is what I want.)

Maybe. A word of caution, though: don't try too hard to control the
users' focus:

  1) you can still deny the submission of an incorrectly filled-out
     form later on,
  2) you can't control the focus reliably across different platforms,
     anyway, and most imporantly
  3) there may be a good reason why the user wants the focus somewhere
     else

What you describe is pretty much the way the forms in one of my projects
worked (by customer request) up until a few years ago. Then it turned
out that this behavior was perceived as more of a hindrance than a help.
It's usually better to visually mark the field as invalid and let the
users fill out the other fields in the order they want to.

A trivial (and admittedly construed) example where gluing the focus to
one particular field would be harmful is a 3-field date input:

   [2011] [11] [30]   (pre-filled values)

The user realizes that the correct value should be 2011-12-31, and
starts by changing the "day" field, entering "31". This results in a
temporarily invalid date - but they can't leave the "day" field to
adjust the "month" field. They will swear at the "stupid braindead app",
click away the alert, enter "30", change the month, and finally enter
"31" again.

Now we just let them fill out invalid values as they like, color the
respective field labels red, and wait until they try to submit the form
before we show any alerts or change the focus.

> I also had the hilarity of my debugging alert() statements affecting
> the program flow.

Yup, it can do that :)
Especially when events and/or timeouts are involved. Using console.log()
for debugging gets rid of all that.

>      It seems to me that alert() might cause input control events to
> fire.  Is this so?  If so, is it guaranteed to be like this, or is it
> just IE 9's implementation?  How tied to implementation is this error
> handling making my code?

Sorry, I can't help there (my experience with IE is rather limited).
I realize that what I wrote doesn't have much to do with JS per se, and
I didn't answer your original question, but maybe this helps anyway.


- stefan

[toc] | [prev] | [next] | [standalone]

#9835

On Sat, 31 Dec 2011 01:27:32 +0100, Stefan Weiss
<krewecherl@gmail.com> wrote:

[snip]

>A trivial (and admittedly construed) example where gluing the focus to
>one particular field would be harmful is a 3-field date input:
                                            ^^^^^^^^^^^^^^^^^^
     Yech!

>   [2011] [11] [30]   (pre-filled values)
>
>The user realizes that the correct value should be 2011-12-31, and
>starts by changing the "day" field, entering "31". This results in a
>temporarily invalid date - but they can't leave the "day" field to
>adjust the "month" field. They will swear at the "stupid braindead app",
>click away the alert, enter "30", change the month, and finally enter
>"31" again.

     I am referring to field-level validation, not form-level
validation.  If a field value itself is invalid *without reference to
any other fields*, I will throw an error.  In the above example,
entering a month 13 is such an error.  Entering a day 32 is such an
error.  Entering a day 31 is not such an error.

     If the problem is that two or more field values are incompatible
(say, month 2 and day 30), that is a form-level error and I would
handle that on form submit.

     The principle is to catch the error as soon as possible.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9839

Am 2012-01-01 08:40, Gene Wirchenko meinte:
> On Sat, 31 Dec 2011 01:27:32 +0100, Stefan Weiss
> <krewecherl@gmail.com> wrote:

>      I am referring to field-level validation, not form-level
> validation.  If a field value itself is invalid *without reference to
> any other fields*, I will throw an error.  In the above example,
> entering a month 13 is such an error.  Entering a day 32 is such an
> error.  Entering a day 31 is not such an error.
> 
>      If the problem is that two or more field values are incompatible
> (say, month 2 and day 30), that is a form-level error and I would
> handle that on form submit.

Do you *really* want to use alert dialogs for such errors (and fiddling
with element focus)? Usability will be painful, to say the least. Even
more so, when there will be a second validation run upon submission
(with probably a different way to inform the user about errors). I'd opt
for blur listeners giving consistent feedbacks, and *not* fiddling with
element focus.

Gregor


-- 
http://vxweb.net

[toc] | [prev] | [next] | [standalone]

#9841

Gregor Kofler wrote on 01 jan 2012 in comp.lang.javascript:

> Am 2012-01-01 08:40, Gene Wirchenko meinte:
>> On Sat, 31 Dec 2011 01:27:32 +0100, Stefan Weiss
>> <krewecherl@gmail.com> wrote:
> 
>>      I am referring to field-level validation, not form-level
>> validation.  If a field value itself is invalid *without reference to
>> any other fields*, I will throw an error.  In the above example,
>> entering a month 13 is such an error.  Entering a day 32 is such an
>> error.  Entering a day 31 is not such an error.
>> 
>>      If the problem is that two or more field values are incompatible
>> (say, month 2 and day 30), that is a form-level error and I would
>> handle that on form submit.
> 
> Do you *really* want to use alert dialogs for such errors (and fiddling
> with element focus)? Usability will be painful, to say the least. Even
> more so, when there will be a second validation run upon submission
> (with probably a different way to inform the user about errors). I'd opt
> for blur listeners giving consistent feedbacks, and *not* fiddling with
> element focus.

Perhaps it would be nicer to have each form-field giving a green flag if 
correctly filled, not irritating the user with error messages at each 
incorrect or empty field.

I however would usually prefer to do a single pre-submit validation,
clientside for speed and/or serverside for quality,
showing commented red flag warnings at each offending field.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#9842

Am 2012-01-01 14:21, Evertjan. meinte:

> I however would usually prefer to do a single pre-submit validation,
> clientside for speed and/or serverside for quality,
> showing commented red flag warnings at each offending field.

Indeed, that's how I frequently implement my form validation.

Gregor


-- 
http://vxweb.net

[toc] | [prev] | [next] | [standalone]

#9867

On Sun, 01 Jan 2012 12:02:16 +0100, Gregor Kofler
<usenet@gregorkofler.com> wrote:

>Am 2012-01-01 08:40, Gene Wirchenko meinte:
>> On Sat, 31 Dec 2011 01:27:32 +0100, Stefan Weiss
>> <krewecherl@gmail.com> wrote:
>
>>      I am referring to field-level validation, not form-level
>> validation.  If a field value itself is invalid *without reference to
>> any other fields*, I will throw an error.  In the above example,
>> entering a month 13 is such an error.  Entering a day 32 is such an
>> error.  Entering a day 31 is not such an error.
>> 
>>      If the problem is that two or more field values are incompatible
>> (say, month 2 and day 30), that is a form-level error and I would
>> handle that on form submit.
>
>Do you *really* want to use alert dialogs for such errors (and fiddling
>with element focus)? Usability will be painful, to say the least. Even

     Yes.

     In your opinion.  The existing app works that way and has for
years.

>more so, when there will be a second validation run upon submission
>(with probably a different way to inform the user about errors). I'd opt
>for blur listeners giving consistent feedbacks, and *not* fiddling with
>element focus.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9879

Gene Wirchenko wrote:
> Gregor Kofler wrote:
>> Gene Wirchenko meinte:

>>>      If the problem is that two or more field values are incompatible
>>> (say, month 2 and day 30), that is a form-level error and I would
>>> handle that on form submit.
>
>> Do you *really* want to use alert dialogs for such errors (and fiddling
>> with element focus)? Usability will be painful, to say the least. Even
>
>      Yes.
>
>      In your opinion.  The existing app works that way and has for
> years.

Certainly it's Gregor's opinion.  But it also reflects what I believe
to be a fairly widespread consensus in the web development community
that alerts should be reserved for those (likely few) cases where a
less intrusive approach simply won't work.

If the existing app is perfect, then there is no reason to replace
it.  Otherwise, you might want to take the opportunity to rethink the
way it has worked for years.  I'm not saying that you should
necessarily change it, but do consider the possibility.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#9902

On Tue, 3 Jan 2012 04:54:12 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

[snip]

>Certainly it's Gregor's opinion.  But it also reflects what I believe
>to be a fairly widespread consensus in the web development community
>that alerts should be reserved for those (likely few) cases where a
>less intrusive approach simply won't work.

     If worse comes to worse, then I can rewrite to eliminate them.

>If the existing app is perfect, then there is no reason to replace
>it.  Otherwise, you might want to take the opportunity to rethink the
>way it has worked for years.  I'm not saying that you should
>necessarily change it, but do consider the possibility.

     The reason that the app is being redone is not because of the UI.
It is because we need it to be more accessible to other programs.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web