[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