submitting form multiple times

Discussion in 'Javascript' started by Andrew Poulos, Jul 22, 2009.

  1. 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
     
    Andrew Poulos, Jul 22, 2009
    #1
    1. Advertisements

  2. Andrew Poulos

    SAM Guest

    Le 7/22/09 5:56 AM, Andrew Poulos a écrit :
    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.
     
    SAM, Jul 22, 2009
    #2
    1. Advertisements

  3. Andrew Poulos

    Evertjan. Guest

    Andrew Poulos wrote on 22 jul 2009 in comp.lang.javascript:
    Yes, if the target frame is not loaded, it will be overwritten before
    any clientside onload scripting starts.
    I don't know what you are trying to achieve,
    but with serverside scripting,
    you probably would not need such instable procedures.
     
    Evertjan., Jul 22, 2009
    #3
  4. Andrew Poulos

    Jorge Guest

    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.
     
    Jorge, Jul 22, 2009
    #4
  5. 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);
     
    Bart Van der Donck, Jul 22, 2009
    #5
  6. Andrew Poulos

    Jorge Guest

    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/
     
    Jorge, Jul 22, 2009
    #6
  7. 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
     
    Andrew Poulos, Jul 22, 2009
    #7
  8. Andrew Poulos

    Jorge Guest

    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.
    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.
     
    Jorge, Jul 22, 2009
    #8
  9. 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
     
    Andrew Poulos, Jul 23, 2009
    #9
  10. Andrew Poulos

    Jorge Guest

    Jorge, Jul 23, 2009
    #10
  11. Andrew Poulos, Jul 23, 2009
    #11
  12. Andrew Poulos

    Jorge Guest

    Jorge, Jul 23, 2009
    #12
  13. Andrew Poulos

    NickFitz Guest

    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.
     
    NickFitz, Jul 23, 2009
    #13
  14. Andrew Poulos

    Jorge Guest

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

    http://gs.statcounter.com/#browser-ww-yearly-2007-2009
     
    Jorge, Jul 23, 2009
    #14
  15. Andrew Poulos

    NickFitz Guest

    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.
     
    NickFitz, Jul 23, 2009
    #15
  16. Andrew Poulos

    Jorge Guest

    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 !
     
    Jorge, Jul 23, 2009
    #16
  17. Andrew Poulos

    Jorge Guest

    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.
     
    Jorge, Jul 23, 2009
    #17
  18. Andrew Poulos

    Jorge Guest

    Times are changin' ...
     
    Jorge, Jul 23, 2009
    #18
  19. Andrew Poulos

    Jorge Guest

    Ok. Thanks again. ICab still renders the inputs with the appearance
    wrong (as .type="text").
    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.
     
    Jorge, Jul 23, 2009
    #19
  20. Andrew Poulos

    Eric Bednarz Guest

    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 :)
     
    Eric Bednarz, Jul 23, 2009
    #20
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.