[thelist] dHTML Form Elements && tip re: Disabling the <enter> key to submit a form.

[jeff]

tab,

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: From: Tab Alleman
:
: (second, scripting these things makes it much more difficult
:  to debug your applications.  while it may be appealing to be
:  able to post to two different scripts the reality is that both
:  scripts that take the form submission are likely very similar.
:  rather than posting...)
:
: <Tab>While this sounds reasonable, my real world experience
: hasn't shown this to be the case.  I find it much easier to debug
: lots of small scripts rather than a few big ones.  I think it becomes
: of matter of getting used to doing things a certain way and
: developing a set of habits that helps you to do them as efficiently
: as possible in whichever manner you've chosen.  In other words,
: "It works for me.. Your Mileage May Vary"
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i can understand your reasoning that debugging several small scripts is
easier - *if* you know that you've potentially got two scripts involved to
begin with.  the trouble with using non-standard means to handle forms is
that you're likely not the last person to ever work on that system.  what's
to say the next person is going to have a clue how it's supposed to work.

i'm not sure exactly how large your scripts could possibly be if they were
combined.  of course part of that is the fact that i'm trying to figure out
what exactly a form could be used in such distinctly different ways.  the
only thing i can think of is you might want a form that could do
add/edit/delete functionality all in one.  so, using your approach you'd
just change the script the form posted to depending on the button that was
clicked.  but why?

using alittle logic you could check that server side and add maybe 5 or 6
lines to perform the delete on your add/edit page.  one thing is sure and
that's if you're form data must be validated serverside (as it should be in
most cases) then you'd have to have that duplicated to use your method
whereas putting it all on one page means you're only validating it once.

just so you know, i spend my waking hours building administrative tools -
lots of them.  i rarely run into a situation where my process page gets
longer than 100 or so lines.  it's nice to have it all there because all the
business logic for a single form is packaged up in a single small file.  i
can lock down the access to that file from the web really easy and dictate
that the only way you can reach it is through my form.

for example, using cold fusion this is the code that makes up a typical
process page that handles add, edit, and delete functionality all in one:

<!--- act_process --->

<cfparam name="form.submit" default="">
<cfparam name="category_id" default="0">

<cfif FindNoCase('Save',form.submit)>

  <cfif Val(category_id)>

    <cfquery name="updatecategory" datasource="#datasource#">
      UPDATE mag_category
      SET
        name = '#Trim(form.name)#',
        title = '#Trim(form.title)#',
        description = '#Trim(form.description)#'
      WHERE id = #Val(form.category_id)#
    </cfquery>
    <cfset pageresponse = "The category, " & name & ", has been updated.">

  <cfelse>

    <cfquery name="insertcategory" datasource="#datasource#">
      INSERT INTO mag_category (
        name,
        short_name,
        description)
      VALUES (
        '#Trim(form.name)#',
        '#Trim(form.short_name)#',
        '#Trim(form.description)#')
    </cfquery>
    <cfset pageresponse = "The category, " & name & ", has been added.">

  </cfif>

<cfelseif FindNoCase("delete", action) AND Val(category_id)>

  <cfquery name="deletecategory" datasource="#datasource#">
    DELETE FROM mag_category
    WHERE id = #Val(category_id)#
  </cfquery>
  <cfset pageresponse = "The category has been deleted.">

</cfif>

basically what's going on in the code sample above is 3 potential things.
first of all it's checking if a submit button named "submit" was clicked and
has a value of "Save".  if it does then we know that we're either adding or
editing.  then, it checks whether or not #category_id# is 0.  if it's 0 we
know that it's a new one and we need to perform in insert.  otherwise it's
obviously one that already exists and we should be performing an update.
now, if it wasn't a submit button named "Save" that was clicked then it
could have been a link passing an action of "delete".  in this case we check
to make sure that #category_id# is an integer greater than 0 and then
perform the delete.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: (finally, relying on the submit() method makes it more
:  difficult to validate your form data prior to submission.
:  instead of being able to rely on the onSubmit event
:  handler for the form (which will not fire if the form is
:  submitted via the submit() method) you'll have to
:  manually call the validation routine...)
:
: <Tab>How is this MORE difficult than using onsubmit?
: You've already started making a function that gets called
: when any of the "submit" buttons are clicked, so what's
: so hard about putting the validation stuff at the beginning
: of that function, and returning false if one of the tests
: doesn't pass?
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

syntactically speaking, what are you returning a boolean of false to?  since
you're not calling the function in such a way as to expect a value to be
returned from the function there isn't much point to return one.  while
you're absolutely true that using the return statement halts execution of
the function, that's not really what's it's intended purpose is.  however,
that's more of a programming technicality than anything.  if you're curious
i'll explain the two main types of functions (ones that are expected to
return a value and ones that aren't) and how to use them.

i guess part of the reason is that i view the submit() method as being
nearly as evil as the eval() method or the isDefined() function in cold
fusion.  it's one of those things that allows developers to be lazy.  with
the submit() method especially, developers can easily do all sorts of things
that make a form completely unusable to anyone without javascript.  those
same forms, if the submit() method was not used could be made to work for
everyone with relatively little work.  one of the things i'm talking about
is when a developer will choose to use a standard link to call the submit()
method (or far more insane things like the ie-only onClick event handler for
an image).  not only is this a *really* bad user interface mistake, it also
alienates non-js users immediately - and for no reason.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: And secondly, if you're using client-side form validation,
: doesn't that kind of invalidate your first argument about
: castrating the non-js users?  or is onsubmit() something
: that will get seamlessly ignored by non-js browsers?
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

actually yes, as james has already pointed out, event handlers in html tags
are ignored completely by non-js browsers and browsers with javascript
disabled.  so, as i pointed out in my example, the form validation that
works off the onSubmit event handler simply adds functionality to the form
(removing the need for a round-trip to the server to find out a form element
is required) while not reducing it's usability.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: (conclusion:  use of the submit() method is a kludge and
: not recommended.)
:
: <Tab>I would temper this to a modest "Programmer Beware".
: I think there are times when it's at least safe, if not preferred,
: to use submit().. but certainly we should all be mindful of the
: potential "gotchas" that you pointed out.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i personally find it to be much higher than a simple "programmer beware".
in my experience there aren't really any times in a publicly accessible site
where it's either necessary or warranted.