[Seaside-dev] submitFormNamed: weirdness

Michael Lucas-Smith mlucas-smith at cincom.com
Mon Nov 26 19:38:23 UTC 2007


Hi All,

Just recently I hit a weird bug with anchor's submitting forms.. 
specifically using #submitFormNamed:

If you do something like:

html anchor
    callback: [self save];
    submitFormNamed: 'form';
    with: 'Save'.

You'll have the web browser fire off a POST followed immediately by a 
GET on two separate connections making it impossible for Seaside to know 
which should be processed first. Often the GET will finish first, 
causing the browser to redirect to a different page and cancel the POST 
command - which may or may not have run yet.

I saw this appear in the form of a bad demo at OCSTUG where the POST 
submits the form and the GET writes to the database. However, depending 
on timing, the write to the database would have empty values.

If you use #ignoreURL to put a 'return false' on the end of the onclick 
you quickly discover that the anchor's callback is never run.. which is 
puzzling when I found this thread: 
http://www.nabble.com/Anchor-with-submit-and-callback-t2648056.html from 
2006 describing how submitFormNamed: should preserve the action id of 
the previously setup callback. This code doesn't exist in Seaside 2.8 final.

Right now a workable hack is:

html anchor
    callback: [self save];
    submitFormNamed: 'form';
    onClick: 'window.location = this.href';
    ignoreURL;
    with: 'Save'

Which is just ugly as :) and it does mean the browser is still very 
likely to terminate the second POST connection on the server side which 
is likely to raise a "Client disconnect" sort of exception (which is 
probably caught by the server - however, that's sort of besides the point).

Cheers,
Michael



More information about the seaside-dev mailing list