questions about form action= and onsubmit() handling

[William Gill]

I dusted off an old JS reference (it's been years) to work on a HTML
database edit app, and have a couple of questions. I have noticed that
form action="javascript:myscript(this)" and onSubmit="myscript(this)"
send different objects to the script. I think IE and Firefox get
different objects (Maybe the document object and window object ?) from
the action=, but both seem to get the form object from onSubmit. Can
anyone expound on what I'm seeing? Is there a good way to see exactly
what object myscript(this) gets? I have cobbled a "dump to popup window
routine", but it's pretty crude.

Also, I'm not actually submitting the form. I plan to use Ajax to
communicate with the server. I change the style of input objects via
onChange, to let users know an item has been edited, but not updated in
the db. The user can update a single changed field in the db via
onDblClick(), or update all changed fields in a table (each table's
fields are in a form on the page) by clicking a button. Here again I'm
having problems. A reset button works exactly as advertised, but I'm
having a couple of problems with the other buttons like "Update All" and
"Delete Record." The first problem is determining which button was
clicked. I could use each button's onClick=myscript(this) property then
in myscript(caller) use caller.name to see which button then caller.form
to get the form's elements collection, loop through them checking for
className == "changed", and process the data, but this seems a long way
around. Lastly, if I "submit" the form by either making the button type
submit (or by hitting return from within the form) it results in the
displayed forms being reset to original hard coded (by PHP))value=
values. The only way I seem to avoid this is setting form
action="javascript:noop(), where noop() is an empty function like:

function noop(){}

Any thoughts or input are appreciated.

 

[JR]

form action="javascript:myscript(this)" and onSubmit="myscript(this)"
send different objects to the script.

Hi William Gill,
The action attribute of a form is supposed to receive an URL or "",
not a function. According to the excellent book Javascript - the
definitive guide 4th edition: "if you specify a javascript: URL as the
value of the action attribute of a <form> tag, the JavaScript code in
the URL is executed when the user submits the form. In these contexts,
the javascript: URL is essentially a substitute for an event handler.
"

Joao Rodrigues

 

[William Gill]

send different objects to the script.

Hi William Gill,
The action attribute of a form is supposed to receive an URL or "",
not a function. According to the excellent book Javascript - the
definitive guide 4th edition: "if you specify a javascript: URL as the
value of the action attribute of a <form> tag, the JavaScript code in
the URL is executed when the user submits the form. In these contexts,
the javascript: URL is essentially a substitute for an event handler.
"

Joao Rodrigues

It is an excellent book, unfortunately mine is 2nd edition (I did say
it's been years). I used it as I would an event handler, but as
mentioned it passes a different object (window) than the onSubmit (form)
event handler does.

 

[William Gill]

The most convenient way I can think of is the Firebug add-on for
Firefox. With Firebug, you can just write console.log(myMysteryObject)
and you will see the object's type, properties and methods. Firebug is
also available for other browsers as "Firebug Lite".

I have firebug installed but must confess I haven't figured everything
out yet. I don't seem to get how to write out the object as you
suggest. I wrote a function:

function showObj(caller){
if((_console==null) || (_console.closed)){

_console=window.open("","console","scrollbars,width=600,height=300,resizable");
_console.document.open("text/plain");
}
msg="";
for (field in caller){
msg+= field+" : "+ caller[field]+"\n";
}
_console.document.writeln(msg);
}

but I haven't gotten what you suggest from FB. Among other things I tried :

form action ="showThis(this)"
....
function showThis(caller){
console.log(caller);
}

but it didn't seem to work.

In your case, this will show you that |this| refers to the global object
(window) for javascript:myscript(this), and to the form element for
onsubmit="myscript(this)". In the latter case the debug message will
quickly disappear because the form gets submitted (see below).

I'd very much recommend against using the "javascript:" pseudo-protocol.
The only use I've ever found for it is in bookmarklets, for everything
else there's always a better solution.

It seems to be the only way to prevent a submit action. I can use
generic (as opposed to submit) buttons, but that doesn't prevent a
submit action when a user hits "enter" from within the form. The
action="javascript:..." does.

If I use action="javascript:..." and don't return anything, the form
doesn't submit. If I return anything including false, it submits. I
can get the same result if I change to onSubmit="return myscript(this)"
and have myscript() return false, as you suggest.

I still need to prevent the back button from confusing the state of the
data.

 

[dhtml]

send different objects to the script.

Hi William Gill,
The action attribute of a form is supposed to receive an URL or "",
not a function. According to the excellent book Javascript - the
definitive guide 4th edition: "if you specify a javascript: URL as the
value of the action attribute of a <form> tag, the JavaScript code in
the URL is executed when the user submits the form. In these contexts,
the javascript: URL is essentially a substitute for an event handler.
"

The javascript: URL is not much of a substitute for any event handler.

Given a FORM with an onsubmit event handler and an action, submitting
that FORM would have the effect of the FORM's onsubmit being called
first. If that event handler did not prevent the default action, the
browser would follow the FORM's action.

In the case that the FORM's action were a javascript: pseudo-protocol,
the portion following javascript: would be evaluated as script in global
context. There would be no event associated with the code.

The submit event handler could prevent default action by one of return
false, event.preventDefault(), or event.returnValue = false, depending
on the browser and method it was attached to the FORM.

The javascript pseudo-protocol is known to be problematic. It creates
A11Y* barriers and causes erratic behavior in some browsers (notably IE6
and below).


Garrett

* Accessibility

 

[William Gill]

I have firebug installed but must confess I haven't figured
everything out yet. I don't seem to get how to write out the object
as you suggest.
[snip]

Among other things I tried :

form action ="showThis(this)"
...
function showThis(caller){
console.log(caller);
}

but it didn't seem to work.

The usage of console.log() is correct, but showThis won't be called if
you just stick it in the action attribute like that. Use the onsubmit
attribute.

My mistake. I meant form action ="javascript:showThis(this)" because,
as mentioned before, the two different methods send different this
references. console.log(caller) doesn't seem to work.

Use the onsubmit attribute. The form action is irrelevant if you're
never submitting the form.

It was relevant in as much as I wanted to prevent submit like when the
user hits "enter".

Where does the back button enter into this? That's an entirely different
problem and requires appropriate checks on the server side. The client
side should never try to mess with the back button.

client side hypothetical:

1) form page displayed w/initial database values.
2) user changes value in input field.
3) input field CSS changes to indicate change on page but not in db
4) user updates db
5) input field CSS changes to indicate page and db in sync
6) 2 & 3 but not 4
7) user hits back button
8) ?

Seems to me to need client side attention.

 

[SAM]

Le 12/31/08 8:31 PM, William Gill a écrit :

client side hypothetical:

1) form page displayed w/initial database values.
2) user changes value in input field.
3) input field CSS changes to indicate change on page but not in db
4) user updates db
5) input field CSS changes to indicate page and db in sync
6) 2 & 3 but not 4
7) user hits back button
8) ?

8) it is his problem if he doesn't want to validate, no ?

9) user hits next button and gets back the forms as he had left them

Seems to me to need client side attention.

Why not

<body onunload="if(!validate)alert('not saved');">

 

[William Gill]

Le 12/31/08 8:31 PM, William Gill a écrit :

8) it is his problem if he doesn't want to validate, no ?

9) user hits next button and gets back the forms as he had left them


Why not

<body onunload="if(!validate)alert('not saved');">

OK, I've dusted off more than my old JS books, and cleared up many
artifacts of partial and mixed memories (syntax confusion with PHP,
ActionScript, Basic, C, C+, Fortran, DPL, Cobal, Python, and numerous
other languages and scripts. Fortunately most of my assembly is either
forgotten or the syntax different enough not to contribute to the
problem). Sorry, I'm not a programmer, I just picked up this stuff
after I was disabled in a 55 MPH head-on car accident some years back.
In a previous life I did help design and implement some of what you
folks now call the internet. I have or will fix misuse of onSubmit (
onSubmit ="return myScript(this)" vise onSubmit ="myScript(this)" which
allowed the submit to continue regardless of what myScript() returned),
and eliminated (or reduced) cache induced error, but you both seem to
miss a basic point, communicating with the U in UI. That's a client
side issue. If the screen displays input fields containing data that is
out of sync w/the database I apply a style to keep the U informed of
that state via CSS (after a change but before an update:
caller.className="dirty"; ) and let the U know data is in sync (after an
actual update: caller.className="". That is not a validation issue.
However before I cleared up cache problems where the browser was
displaying "out of sync" data as if it were in sync (step 7 to 8) the U
had no indication the state displayed was wrong, and BTW the "flag" for
onunload="if(!validate)alert('not saved');" was also be in the wrong state.

The "back button" issue seems to also have been a result of cache
issues, as now back does not produce a previous version (state) of the
page, but rather the actual previous page.

I got onto the tangent of exploring action="javascript:myscript(this)"
because action="" was producing the same misrepresentation of true
state. I believe that was the result of the submit not being
interrupted (because of my onSubmit= mistake). My curiosity about which
object was actually being passed just compounded my misdirection. I may
explore this later, but solely for personal gratification.

When I get a chance I will finish up and post what I find for review and
input.

 

[William Gill]

Given a FORM with an onsubmit event handler and an action, submitting
that FORM would have the effect of the FORM's onsubmit being called
first. If that event handler did not prevent the default action, the
browser would follow the FORM's action.

That's where I got off track. I was misusing onSubmit
(onSubmit="myScript(this)" instead of onSubmit ="return myScript(this)")
which allowed the submit to continue regardless of what myScript()
returned.

Then once I noticed the action= and onSubmit= passed different objects I
got off on a tangent looking for what and why, and thinking I might be
able to access/intercept the encoded "form data set" described in the
spec.

 

[SAM]

Le 1/1/09 5:58 PM, William Gill a écrit :

The "back button" issue seems to also have been a result of cache
issues, as now back does not produce a previous version (state) of the
page, but rather the actual previous page.

Of course, and why ?
Becaue the U dind't submit the form
(the page is still there in same state that the U has left it)
Where and what is the 'back' in this circumstance ?

The button 'back' is not an 'undo' button ... !
It's to go to the previous visited page (the previous downloaded file)
It uses the browser's historic

history.go(-1); // = button back
history.back(); // = button back
history.go(1); // = button next

I got onto the tangent of exploring action="javascript:myscript(this)"
because action="" was producing the same misrepresentation of true
state. I believe that was the result of the submit not being
interrupted (because of my onSubmit= mistake).

No, that's not the (only) reason.

My curiosity about which
object was actually being passed just compounded my misdirection. I may
explore this later, but solely for personal gratification.

Clicking the submit button will not do the same as the JS function
document.myForm.submit();

One looks at the onsubmit (if present in tag form) the other not and
sends the form directly.

So, normally, you can't use the same function in the action and in the
onsubmit.
Without speaking of 'this' which will not represent the same object.
- this in form's action -> WindowObject (I don't know which one)
- this in form's onsubmit -> HtmlFormElement

When I get a chance I will finish up and post what I find for review and
input.

As example is always more explicit, try the following :

<html>
<script type="text/javascript">
function verif() {
return confirm('I am the onsubmit verificator\n'+
'hit [OK] to continue\nor [Cancel] to abort the submit');
}
</script>
<form action="javascript:alert('I am the action')"
onsubmit="return verif();">
<p><input type="submit" value="form's normal submit">
</form>
<p><a href="javascript:document.forms[0].submit();">
submit the form via JS</a> without confirmation</p>
<p><a href="javascript:if(verif())document.forms[0].submit();">
submit the form via JS</a> with confirmation</p>
</html>


Using the JS to submit the form you'll have to launch the onsubmit's
function in first.

The onsubmit would has to be of this form :

onsubmit="return myFunction(this)"
^^^^^^
Where 'myFunction' must return true or false
true : the form is sent
false : the sent is aborted

Where 'this' represents that form there

 

[William Gill]

Le 1/1/09 5:58 PM, William Gill a écrit :

Of course, and why ?
Becaue the U dind't submit the form
(the page is still there in same state that the U has left it)
Where and what is the 'back' in this circumstance ?

SAM,

I think we may be talking past each other. The problem I was
experiencing was:

1) page loaded all fields displaying data from db className="" (state ==
display and db in sync)
2) user edits a field
3) onchange modifies changed element to className="dirty" (state ==
display and db not in sync)
4) user updates db (onDblclk=) changed back to className="" (state ==
display and db in sync)

This is what I wanted. A visual indication of (local) data and true
state of local data vs db data, but I was experiencing a condition where
a field was not in sync with the db, but had className="" (i.e. in
sync). This would incorrectly indicate to the user what he/she was
viewing was the current state of db data, it wasn't. I think it was
caused by multiple changes and updates followed by "back button" click,
and my previously unresolved cache problem.

The button 'back' is not an 'undo' button ... !
It's to go to the previous visited page (the previous downloaded file)
It uses the browser's historic

The problem WAS it was LOOKING like an undo button (by displaying a
cached previous state of the current page). That has been corrected,
and NOW it does go back to the previously visited page. I.E. that part
seems to be fixed now.

One thing that still confuses me is that even though the browser was
(incorrectly) retrieving a cache copy, my server log showed a normal
request.

No, that's not the (only) reason.

Actually form action="" was producing a new request of the page from the
server. Which caused the user to lose unsaved changes. (see below
about my incorrect invocation of onSubmit) So the symptom of losing
unsaved changes, was the result of the browser operating as it should
for a submit where action="". Once I stopped submit from happening the
symptom went away (i.e. my error was elsewhere).

Clicking the submit button will not do the same as the JS function
document.myForm.submit();

??? I never said anything about invoking the submit method via JS?

One looks at the onsubmit (if present in tag form) the other not and
sends the form directly.

So, normally, you can't use the same function in the action and in the
onsubmit.
Without speaking of 'this' which will not represent the same object.
- this in form's action -> WindowObject (I don't know which one)
- this in form's onsubmit -> HtmlFormElement

Yes, as I previously stated,I figured that out which provoked my
curiosity.

The onsubmit would has to be of this form :

onsubmit="return myFunction(this)"
^^^^^^
Where 'myFunction' must return true or false
true : the form is sent
false : the sent is aborted

Where 'this' represents that form there

Again, I figured that out. I remembered correctly that my function had
to return false to prevent form.submit(). I remembered incorrectly the
proper way to invoke onSubmit (by leaving out "return"), and because I
wasn't interrupting submit(), even form action="" was producing an
incorrect result.

 

[SAM]

Le 1/1/09 10:11 PM, William Gill a écrit :

SAM wrote: The problem I was experiencing was:

1) page loaded all fields displaying data from db className=""
(state == display and db in sync)
2) user edits a field
3) onchange modifies changed element to className="dirty"
(state == display and db not in sync)
4) user updates db (onDblclk=) changed back to className=""
(state == display and db in sync)

if ondblclick submits the form then the new value sent back by the
server becomes the default value
and simultaneously the class would has to be deleted

The simplest would be to "re-write" all the form's elements
document.myForm.innerHTML = responseText;

The onchange only sets or not the class according to the content of the
field

onchange="this.className = this.value!=this.defaultValue? 'mayday':'';"

The problem WAS it was LOOKING like an undo button (by displaying a
cached previous state of the current page).

Normally, only if a submit has fired on the last display, no ?

That has been corrected, and NOW it does go back to the previously
visited page. I.E. that part seems to be fixed now.

Ha! OK! good news.

The symptom of losing unsaved changes, was the result of the browser
operating as it should for a submit where action="". Once I stopped
submit from happening the symptom went away (i.e. my error was
elsewhere).

Ha? OK, not easy to understand what happens (what is supposed to be
wrong) when tests are based on such youngness error.

??? I never said anything about invoking the submit method via JS?

And what does your dblclick ?
isn't it sending (submitting) the form to update the db ?

Again, I figured that out.

I saw your other post too late, after I've posted mine.

even form action="" was producing an incorrect result.

Not really incorrect, that reloads the page (recalls the form)

 

[William Gill]

Le 1/1/09 10:11 PM, William Gill a écrit :

if ondblclick submits the form then the new value sent back by the
server becomes the default value
and simultaneously the class would has to be deleted

OK that's where I sent you off course. ondblclick does not submit the
form. Single field updates are being done via Ajax, not submit. I
choose asynchronous updates because one "page" represents data from
several related tables. In some cases one master record (i.e. person)
could have 0 or more entries (i.e. 0 or multiple phone numbers), and
updating the entire page was distracting and inefficient.

Normally, only if a submit has fired on the last display, no ?

No, I think (memory problems again) what was happening was say address
was changed from 123 Elm to 123 Oak, then updated, then changed to 123
Maple, updated again, then "back" produced a copy showing 123 Oak but
className"" (indicating in sync).

Ha! OK! good news.


Ha? OK, not easy to understand what happens (what is supposed to be
wrong) when tests are based on such youngness error.
"youngness"?

And what does your dblclick ?
isn't it sending (submitting) the form to update the db ?

Sending yes. Submitting no. Here's where I may have misled you (or was
it YOUR invalid assumption <g>)

I will have one button to allow all changes on the page to be updated at
once, but since they will either be in multiple forms, or no form at all
I will have to make the page and server act like a submit i.e. process
the data then reload the entire page with new database values.

Not really incorrect, that reloads the page (recalls the form)

What I would call in trouble shooting normal/abnormal. In trouble
shooting I track three states:

1: normal/normal - result/output/reading/whatever is correct (no trouble)
2: normal/abnormal - result/etc is correct but not desired (i.e. your
smoke alarm is sounding)
3: abnormal/abnormal - result is neither correct or desired (i.e. your
bed is on fire)

So when smoke detector alarm is sounding ( normal/abnormal ) ; put out
the fire, don't replace the smoke detector.

I.e. I didn't want the page reloading (smoke detector alarm), but my
onsubmit error (burning bed) was allowing it.

 

[SAM]

Le 1/2/09 12:25 AM, William Gill a écrit :

No, I think (memory problems again) what was happening was say address
was changed from 123 Elm to 123 Oak, then updated, then changed to 123
Maple, updated again, then "back" produced a copy showing 123 Oak but
className"" (indicating in sync).

would you have an url where I could try to +/- understand how you make
to achieve your goal.

I understood you have
- several forms (probably each with a submit button)
- more a general submit button

Perhaps it is only :
- separate fieldsets updated indidually by Ajax
- a form with all these fieldsets and its general submit
Like that : <http://cjoint.com/?bewSBRe3LY> ?

In case 2, I don't think it is a hard job to send all the form on each
sub-validation
- via Ajax if JS is enabled with not apparent reloading the page
- via normal HTML is JS is disabled with the page refreshed

"youngness"?

Youth ? for instance ?

Sending yes. Submitting no. Here's where I may have misled you (or was
it YOUR invalid assumption <g>)

I understood somewhere you used several forms.

 

[SAM]

Le 1/4/09 10:01 PM, SAM a écrit :

Like that : <http://cjoint.com/?bewSBRe3LY> ?

Oops ! ... like that :
<http://cjoint.com/data/bfbf3HoKZd_reset_class_by_fieldset.htm>

 

[William Gill]

Le 1/2/09 12:25 AM, William Gill a écrit :

would you have an url where I could try to +/- understand how you make
to achieve your goal.

Sorry no. I'm just in the process of developing it on my development
server (local). (see below for the sequence describing what was happening)

I understood you have
- several forms (probably each with a submit button)
- more a general submit button

Perhaps it is only :
- separate fieldsets updated indidually by Ajax
- a form with all these fieldsets and its general submit
Like that : <http://cjoint.com/?bewSBRe3LY> ?

Very similar but w/o frames. I started out thinking about using frames
then someone pointed me to Ajax instead.

In case 2, I don't think it is a hard job to send all the form on each
sub-validation
- via Ajax if JS is enabled with not apparent reloading the page
- via normal HTML is JS is disabled with the page refreshed

I started out with the intent of never "submitting" anything, all server
communication would be via Ajax. I kept the input fields contained in
forms to take advantage of the built in elements collection for field
grouping. However, with forms, even without submit buttons, if the user
hits <enter> from within an input field it initiates a "submit." I
guarded against this by setting the form action="" and onsubmit=" return
false"

I later discovered I could force the displayed page to be out of sync
with the database, yet not have the appropriate field highlighting, by:

1)editing a field
2)having the onchange highlight it
3)dblclicking the field to submit data and remove highlighting
4)hitting the back button

Following those steps it was possible got the input field to contain
"123 Oak", while the database contained "456 Elm", but the input field
was not be highlighted.

This was a cache problem and it has been resolved. <Back> now goes to
the previous page, not a previous copy of the database edit page. I
will put in an onunload intercept to let the user know that if they
continue unsaved data will be lost.

Youth ? for instance ?

Don't think I've qualified in a long time. Inexperienced, or more
accurately, rusty in my JavaScript. I recently posted that it is better
to not remember at all, than to misremember.
No. an onchange event highlights a field to remind the user of the
unsaved change (just like in your example). dblclick allows the user to
update a single field (the one dblclicked).

However, users don't usually update one field at a time. I needed a
"remote control" to find and process groups of changed fields all at
once. That's why I wanted to use the form.elements collection. The
handler can loop through all the elements, looking for any with
classname "dirty"; collect and send th data; and reset the classnames to
"".

Another mistake was to try to have multiple submit buttons in each form
(one to update all changed fields, one delete the record from the
database, etc). That works in a server script because only one
submit:value pair are is received, but to identify which submit
triggered the onsubmit was a little clumsy. The submit buttons had to
call the onsubmit function which would have to identify the caller and
the form, then pass that information to the looping function.

I used forms and form.elements collection to make it easy to correlate
the input fields with their respective database tables (i.e. formname ==
db table name, input field name == database field name).

Other means of "grouping" using HTML like fieldset, <div>, or <tr>
seemed to be more complicated when the time came to iterate over a group
of input elements, and I suspect changes in the underlying HTML for
aesthetic reasons could easily break looping through the elements.

I understood somewhere you used several forms.

My bad joke. It is natural for you to assume that if one or more forms
are involved, a "submit" will happen at some point. I should have
explicitly said I intended to prevent any "submit."

I hope this clears things up a bit.

I may have to abandon the use of forms and forms.elements if I discover
that data from two different tables needs to be interlaced
(table1.field1, table1.field2, table2.field19, table1.field3,...) to
create a logical display.

 

[SAM]

Le 1/5/09 1:47 AM, William Gill a écrit :

Very similar but w/o frames. I started out thinking about using frames
then someone pointed me to Ajax instead.

cjoint.com is a site to upload freely temporary files.
My own file is in the 2nd frame and it is better to follow the link :

I started out with the intent of never "submitting" anything, all server
communication would be via Ajax.

It is not a good idea in regard to accessibility.
A form would have to "work" without JS.

I kept the input fields contained in
forms to take advantage of the built in elements collection for field
grouping. However, with forms, even without submit buttons, if the user
hits <enter> from within an input field it initiates a "submit." I
guarded against this by setting the form action="" and onsubmit=" return
false"

OK (it's what it is in my little demo)

I later discovered I could force the displayed page to be out of sync
with the database, yet not have the appropriate field highlighting, by:

1)editing a field
2)having the onchange highlight it
3)dblclicking the field to submit data and remove highlighting
4)hitting the back button

It is this 4th point I can't reproduce, hitting the back/next buttons
toggle between the form and another file but certainly not between 2
steps of the form (except perhaps if it has been submitted).

This was a cache problem and it has been resolved. <Back> now goes to
the previous page, not a previous copy of the database edit page. I
will put in an onunload intercept to let the user know that if they
continue unsaved data will be lost.

When a user fills up a form he must know that the datas are not sent if
he didn't submit the form, similar with a basket in a merchant's site
that has not been confirmed until step for payment.
A message to advise the user he has not finished, is not a bad idea

No. an onchange event highlights a field to remind the user of the
unsaved change (just like in your example). dblclick allows the user to
update a single field (the one dblclicked).

I don't like too much this double-click, it's subject to bad/wrong
manipulation.

However, users don't usually update one field at a time. I needed a
"remote control" to find and process groups of changed fields all at
once. That's why I wanted to use the form.elements collection. The
handler can loop through all the elements, looking for any with
classname "dirty"; collect and send th data; and reset the classnames to
"".

I think grouping changed items isn't to do, it is not so a big work to
send the entire form and to analyze it's content on server-side (servers
have numerous caches to accelerate the process).

Another mistake was to try to have multiple submit buttons in each form
(one to update all changed fields, one delete the record from the
database, etc). That works in a server script because only one
submit:value pair are is received, but to identify which submit
triggered the onsubmit was a little clumsy. The submit buttons had to
call the onsubmit function which would have to identify the caller and
the form, then pass that information to the looping function.

Usually with several submit buttons there are 2 ways of doing :
- each input submit has a different name than others and same value
or
- each input submit has same name but different value (better)
Then the server sees which submit was pressed (by its name or its value)
and does the job in regard of this info.

I used forms and form.elements collection to make it easy to correlate
the input fields with their respective database tables (i.e. formname ==
db table name, input field name == database field name).

You have separate tables for names and first-names ?

Other means of "grouping" using HTML like fieldset, <div>, or <tr>
seemed to be more complicated when the time came to iterate over a group
of input elements, and I suspect changes in the underlying HTML for
aesthetic reasons could easily break looping through the elements.

??? elements are elements, independently in which TD or DIV or what you
want, if they stay form's elements (between the 2 form tags).
There is no real importance if they are not "logically" ordered or not
sorted as the database.

I may have to abandon the use of forms and forms.elements if I discover
that data from two different tables needs to be interlaced
(table1.field1, table1.field2, table2.field19, table1.field3,...) to
create a logical display.

It seems your data base is curiously set if it doesn't follow a logical
organization. ;-)
Perhaps main job is to make on this side ?

 

[William Gill]

It is not a good idea in regard to accessibility.
A form would have to "work" without JS.

The page is for a limited audience, and a specific application.
Accessibility isn't an issue.

It is this 4th point I can't reproduce, hitting the back/next buttons
toggle between the form and another file but certainly not between 2
steps of the form (except perhaps if it has been submitted).

Nor can I anymore. (...This was a cache problem and it has been resolved...)

When a user fills up a form he must know that the datas are not sent if
he didn't submit the form, similar with a basket in a merchant's site
that has not been confirmed until step for payment.

Your hypothetical shopper (I'm assuming in a brick and mortar site)
isn't being interrupted by phone calls, and other papers on his/her
desk, but still need only look in the basket to see "incomplete
transactions." What if he/she doesn't look at the basket and walks out
of the merchant's site without paying? My highlight scheme is a visual
"shopping basket" of items the user hasn't paid for yet.

I'm trying to design for how people work. They most likely will store
up several database updates and do them all at once ( "John, here is a
list of customers who need to be updated in our database today." "Yes
boss, I'll do it when I get a chance. Give me the list." )

I don't like too much this double-click, it's subject to bad/wrong
manipulation.

How so? I merely offer the user the option to do incremental updates.
Not everyone will want to update each field as it is edited. Some will
wait until they have finished the entire "record" (HTML document,
probably several database records), and some will not.

I think grouping changed items isn't to do, it is not so a big work to
send the entire form and to analyze it's content on server-side (servers
have numerous caches to accelerate the process).

Either way (server side or client side) the intent is to only process
data that has changed. The client side "grouping" I refer to is simply
a mechanism to make it easier to determine "what fields in which table
need to be examined." The alternative seems to be to check every field
in the document to determine if it has been changed; decide what table
(database not document) it belongs to, organize them and send this
information to the server, or send every changed field and let the
server script determine which table, and how to proceed.

This can all be accomplished via "submit" and server side processing,
but with the undesirable (IMHO) effect of having to refresh the entire
page to reflect the current state of things. This is annoying, and Ajax
makes it unnecessary.

Usually with several submit buttons there are 2 ways of doing :
- each input submit has a different name than others and same value
or
- each input submit has same name but different value (better)
Then the server sees which submit was pressed (by its name or its value)
and does the job in regard of this info.

I use the second method regularly in server side processing. That is
why I pursued doing something similar in client side JavaScript. I
wasn't happy with the convoluted mechanisms I had to employ to identify
which submit button initiated the call. On second (or third, or
forth,...) examination it is a simple matter of passing a reference to
the button ( ondblclick"myFunction(this)" ) then in myFunction;

function myFunction(caller){
whoWantsMeToDoSomething= caller.name;
whatFieldsDoINeedToDoSomethingTo= caller.form.elements;
// etc.
}

You have separate tables for names and first-names ?

In the database there may be a table "address", with a field
"streetNumber" or address.streetNumber. In the HTML document I can
have a form named "address" with an input field named "streetNumber"
then when I collect data to be updated I know which field on the HTML
document corresponds to which database table and field on the server.

??? elements are elements, independently in which TD or DIV or what you
want, if they stay form's elements (between the 2 form tags).
There is no real importance if they are not "logically" ordered or not
sorted as the database.

I was comparing how JavaScript would process input elements outside of
form tags (as some have suggested), and inside of them. I need a way to
know how they are "logically" arranged in the HTML document (not the how
they are arranged in the database) so that one button can tell my
function "update me and all of my friends in this group that have
changed." When placed inside of <form> </form>, input elements are
contained in a form object and "grouped" in the elements collection of

It seems your data base is curiously set if it doesn't follow a logical
organization. ;-)
Perhaps main job is to make on this side ?

This was a hypothetical extension: "What if it is easier for the user to
read and understand the HTML document if the fields appear in an order
different than simply displaying all fields from each database table
together? What if they need to be interlaced? Form tags can not be
overlapped or nested. In this case the inputs would have to be place
outside of forms, necessitating a different "grouping" scheme (no form
== no form.elements collection).

Perhaps the term "grouping" is contributing to the confusion. I don't
mean grouping as in SQL. I mean "grouping" as in associating several
input elements for JavaScript to be able to treat them as part of a
collection. Similar to how the form object does in form.elements.

 

[William Gill]

function myFunction(caller){
whoWantsMeToDoSomething= caller.name;
whatFieldsDoINeedToDoSomethingTo= caller.form.elements;
// etc.
}

I left out WhatDataBaseTablsIsInvolved=caller.form.name;