submitting form multiple times

A

Andrew Poulos

I have a "standard" (hidden) form into which input values are set and
then the form is submitted. It appears to be working fine unless the
form is updated and submitted multiple times in quick succession.

The later submits get swallowed.

The target for the form is a hidden iframe.

Is there a way to queue them when the page does not expect/need any
data, as such, back from the server?

Andrew Poulos
 
S

SAM

Le 7/22/09 5:56 AM, Andrew Poulos a écrit :
I have a "standard" (hidden) form into which input values are set and
then the form is submitted. It appears to be working fine unless the
form is updated and submitted multiple times in quick succession.

The later submits get swallowed.

The target for the form is a hidden iframe.

Found anything more complex ?

A system this kind :

<form action="test.htm" target="_blank">
<input mane="one" onkeyup="sender.disabled=(this.value=='');">
<input name="two" onkeyup="sender.disabled=(this.value=='');">
<input name="sender" type=submit disabled onclick="this.disabled">
</form>

to adapt to your design.
 
E

Evertjan.

Andrew Poulos wrote on 22 jul 2009 in comp.lang.javascript:
I have a "standard" (hidden) form into which input values are set and
then the form is submitted. It appears to be working fine unless the
form is updated and submitted multiple times in quick succession.

The later submits get swallowed.

The target for the form is a hidden iframe.

Yes, if the target frame is not loaded, it will be overwritten before
any clientside onload scripting starts.
Is there a way to queue them when the page does not expect/need any
data, as such, back from the server?

I don't know what you are trying to achieve,
but with serverside scripting,
you probably would not need such instable procedures.
 
J

Jorge

I have a "standard" (hidden) form into which input values are set and
then the form is submitted. It appears to be working fine unless the
form is updated and submitted multiple times in quick succession.

The later submits get swallowed.

No, the last one submitted always survives... Trigger an alert
(location.search); in the response .html in order to see. Or look into
the net panel in firebug.
 
B

Bart Van der Donck

Andrew said:
I have a "standard" (hidden) form into which input values are set and
then the form is submitted. It appears to be working fine unless the
form is updated and submitted multiple times in quick succession.

The later submits get swallowed.

The target for the form is a hidden iframe.

Is there a way to queue them when the page does not expect/need any
data, as such, back from the server?

I had observed the same issue:
http://groups.google.com/group/comp.lang.javascript/msg/5fca401d2f2f43ca

My strategy was to not send the submit-action immediately, like

document.myform.submit();

but to execute it after a short time delay of 0.1 second:

setTimeout('document.myform.submit();', 100);
 
J

Jorge

Andrew said:
I have a "standard" (hidden) form into which input values are set and
then the form is submitted. It appears to be working fine unless the
form is updated and submitted multiple times in quick succession.

The later submits get swallowed.

The target for the form is a hidden iframe.

Is there a way to queue them when the page does not expect/need any
data, as such, back from the server?

1.- Create a separate target iframe for each submitted form:

iframe= document.createElement('iframe');
iframe.name= "n"+ n;
document.body.appendChild(iframe);
form.target= iframe.name;
form.submit();

2.- The iframe can delete itself once the response is received:

var me= top.window.document.getElementById(iframeId);
setTimeout(function() {
me.parentNode.removeChild(me);
}, 2222);

It works:
http://jorgechamorro.com/cljs/074/
 
A

Andrew Poulos

Jorge said:
1.- Create a separate target iframe for each submitted form:

iframe= document.createElement('iframe');
iframe.name= "n"+ n;
document.body.appendChild(iframe);
form.target= iframe.name;
form.submit();

2.- The iframe can delete itself once the response is received:

var me= top.window.document.getElementById(iframeId);
setTimeout(function() {
me.parentNode.removeChild(me);
}, 2222);

It works:
http://jorgechamorro.com/cljs/074/
I see it working on your site but I don't understand where iframeId come
from in 2.

And IE 8 complains that
Could not get the type property. This command is not supported. 074,
line 30 character 7

Andrew Poulos
 
J

Jorge

Andrew said:
I see it working on your site but I don't understand where iframeId come
from in 2.

The iframe has an .id= its .name= "n"+ a number. It's embedded in the
search part of the .action url so that it can be retrieved from the
location.search string once the form's response is received into the
iframe and its <script> gets executed. In that example the
location.search string is : "?n=number&rnd=randomNumber"... to extract
the number I do some succesive splittings of the string in arrays:
s.split("?n=")[1].split("&rnd=")[0],

e.g. given s= location.search= "?n=345&rnd=abc" the id we would be
looking for is "n345" :

s.split("?n=") gives the array ["", "345&rnd=abc"], so take the second
element [1] of that array: "345&rnd=abc" and split it again:

"345&rnd=abc".split("&rnd=") gives ["345", "abc"], the number we're
looking for is the first element [0]: "345", so the id would be
"n"+"345" === "n345"

Hope that helps.
And IE 8 complains that
Could not get the type property. This command is not supported. 074,
line 30 character 7

I hate IE. I don't know (nor care) what's going on... :) AFAICS this
code is standards-compliant, it works fine in ~ any (*) browser but IE,
so, it's IE's problem, not mine.

(*) Tested in Safari/Mac, FireFox/Mac, Opera/Mac, iCab/Mac, Chrome/XP,
Firefox/XP, Opera/XP, Safari/XP.
 
A

Andrew Poulos

Jorge said:
Andrew said:
I see it working on your site but I don't understand where iframeId
come from in 2.

The iframe has an .id= its .name= "n"+ a number. It's embedded in the
search part of the .action url so that it can be retrieved from the
location.search string once the form's response is received into the
iframe and its <script> gets executed. In that example the
location.search string is : "?n=number&rnd=randomNumber"... to extract
the number I do some succesive splittings of the string in arrays:
s.split("?n=")[1].split("&rnd=")[0],

e.g. given s= location.search= "?n=345&rnd=abc" the id we would be
looking for is "n345" :

s.split("?n=") gives the array ["", "345&rnd=abc"], so take the second
element [1] of that array: "345&rnd=abc" and split it again:

"345&rnd=abc".split("&rnd=") gives ["345", "abc"], the number we're
looking for is the first element [0]: "345", so the id would be
"n"+"345" === "n345"

Hope that helps.
And IE 8 complains that
Could not get the type property. This command is not supported. 074,
line 30 character 7

I hate IE. I don't know (nor care) what's going on... :) AFAICS this
code is standards-compliant, it works fine in ~ any (*) browser but IE,
so, it's IE's problem, not mine.

(*) Tested in Safari/Mac, FireFox/Mac, Opera/Mac, iCab/Mac, Chrome/XP,
Firefox/XP, Opera/XP, Safari/XP.

Funny that you choose to ignore the, by far, most used browser in the
world, but that's not to say I'm not thankful for your help (which I am).

Andrew Poulos
 
N

NickFitz


The w3schools statistics are (like most of their content) meaningless
and irrelevant. The only people who visit that site are people
involved in web development, and those people tend to use browsers
other than IE.

It's like surveying the crowd at London Fashion Week and using the
results to argue that 95% of people always wear designer clothes to
work. Meanwhile the real world slogs on in its greasy overalls and
drip-dry suits.

The statcounter.com site Andrew links to is much closer to reflecting
reality: it shows around 50% worldwide share for IE [1], which seems
reasonable. (Looking at the stats for countries like Ukraine [2] and
similar CIS countries always surprises people, too.)

[1] <http://gs.statcounter.com/#browser-ww-daily-20090601-20090630-
bar>
[2] <http://gs.statcounter.com/#browser-UA-daily-20090601-20090630-
bar>

Regards,

Nick.
 
J

Jorge

Is it, really ? Still ? Sure ?

The w3schools statistics are (like most of their content) meaningless
and irrelevant. The only people who visit that site are people
involved in web development, and those people tend to use browsers
other than IE.

It's like surveying the crowd at London Fashion Week and using the
results to argue that 95% of people always wear designer clothes to
work. Meanwhile the real world slogs on in its greasy overalls and
drip-dry suits.

The statcounter.com site Andrew links to is much closer to reflecting
reality: it shows around 50% worldwide share for IE [1], which seems
reasonable. (Looking at the stats for countries like Ukraine [2] and
similar CIS countries always surprises people, too.)

[1] <http://gs.statcounter.com/#browser-ww-daily-20090601-20090630-
bar>
[2] <http://gs.statcounter.com/#browser-UA-daily-20090601-20090630-
bar>

Regards,

But the trend is the same, no matter where you look :)

http://gs.statcounter.com/#browser-ww-yearly-2007-2009
 
N

NickFitz

But the trend is the same, no matter where you look :)

http://gs.statcounter.com/#browser-ww-yearly-2007-2009

If we assume that IE's decline continues, and continues at the same
rate, you can start thinking about ending support for it in about ten
years ;-)

Remember a few years ago, when people were insisting that Firefox was
worth supporting even if it only had ~5% market share? ("Not
supporting it is like turning away one in twenty customers" was one of
the arguments people came up with.)

Unfortunately, exactly the same arguments apply to IE. If it was
important to support Firefox then, it will remain important to support
IE for the indefinite future.

Regards,

Nick.
 
J

Jorge

The - type - properties of form controls tend to be (and certainly are
on windows IE) write-once (once set they cannot be changed). There is a
default type of "text", so in the event of not explicitly setting a -
type - property there is a question of when/how that default gets
applied. It must be applied before the field can be rendered (else the
browser will not know what it is to render). It appears that in the case
of not explicitly setting it, IE sets the - type - property to the
default at the point of adding the filed to the document (the
appendChild call in this case), and does so by setting the - type -
attribute itself (consuming the write-once opportunity). Thus, any
subsequent attempt to set the property throws an exception. This
situation can be avoided (with no observed negative impact on any other
browser) by setting the - type - property explicitly, prior to inserting
the Element into the document (assuming that a type other than "text" is
wanted).

At the point of the error, the input element was already inserted into
the form element, but the form element itself wasn't inserted yet in
the document...

Anyway, that was it: to assign the attributes before inserting, and
it's fixed now. Thanks, Cornford !
 
J

Jorge

NickFitz said:
If we assume that IE's decline continues, and continues at the same
rate, you can start thinking about ending support for it in about ten
years ;-)

Not me. And not many like me. It's time to kill the beast.

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/c765558bf8bc992c

If IE8 continues lacking in as many ways as it currently does, its
decline will not only continue, but even accelerate further. They'd
better follow HTML5 as the others + google are doing. But can M$ swallow
such a bitter pill ? : the WHATWG was founded by Apple + Mozilla + Opera
!. And google's behind, supporting them.
 
J

Jorge

Richard said:
Perhaps the difference in perspective between the view from some 'ivory
tower' (a place were you can get way with not caring) and the world of
commercial web development where knowing how to support IE has been the
absolute minimum requirement for at least a decade.

Times are changin' ...
 
J

Jorge

Maybe it was not inserted into "the document", but it was inserted into
'a document'. IE browsers have a habit of creating DocumentFragment
nodes to contain fragemnts of doucment structure that have not yet been
inserted into a document proper.

From the W3C Core DOM spec:-

| Interface DocumentFragment
|
| DocumentFragment is a "lightweight" or "minimal" Document
| object. ...

- so a documentFragment is a document (even if not a very capable one).

You can see the effect in your own code by adding the folowing two
alerts:-

    function newForm () {
      ++n;

      if (theForm) {
        theForm.parentNode.removeChild(theForm);
      }
      theForm= document.createElement('form');
      theForm.action= "test.html";

alert('1: '+theForm.parentNode);

      nCounterFormField= document.createElement('input');
      nCounterFormField.type= "hidden";
      nCounterFormField.name= "n";
      theForm.appendChild(nCounterFormField);

      randomFormField= document.createElement('input');
      randomFormField.type= "hidden";
      randomFormField.name= "rnd";
      theForm.appendChild(randomFormField);

alert('2: '+theForm.parentNode.nodeType);

      theButton= document.createElement('input');
      theButton.type= "button";
      theButton.value= "SUBMIT FORM";
      theButton.onclick= fghi;
      theForm.appendChild(theButton);

      putItHere.appendChild(theForm);
    }

The first alerts "1: null", implying that at that point - theForm - has
no - parentNode -, while the second alerts "2: 11", showing - theForm -
as having a - parentNode - of type 11. The type 11 node is the
DocumentFragment. Thus the act of appending the INPUT filed to the FORM
element has the side effect of creating a DocumentFragment and appending
the FORM to that DocumentFragment in addition to appending the INPUT
field to the FORM. And so the INPUT filed is being added to a document
as a consequence of being appended to a FORM that had no - parentNode -
at that time.

Ok. Thanks again. ICab still renders the inputs with the appearance
wrong (as .type="text").
Unsurprising, but if you really don't care about IE why did you fix it
at all?

Because you've put it so easy.

Do you know as well why does IE7 ignore the form's .target ? : they
end up in a new window.
 
E

Eric Bednarz

Jorge said:
Do you know as well why does IE7 ignore the form's .target ? : they
end up in a new window.

That is the documented behaviour if no name was found,

| If there is no existing window or frame with the same name as
| specified in the target, a new window is opened with a name equal to
| the value of the target.
<http://msdn.microsoft.com/en-us/library/ms534659(VS.85).aspx>

so the first thing to check – if you don’t already know that you cannot
set the name property for a dynamically created IFRAME element – would
be if there’s a name attribute set. There isn’t.

The above excerpt already points to a workaround:

iframe.contentWindow.name = iframe.id = 'fubar';

(unless you prefer the silly
document.createElement('<element attribute="value">')
borkaround :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top