W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2004

[whatwg] Any way to submit only those parts of a form that havechanged?

From: Ben Meadowcroft <ben@benmeadowcroft.com>
Date: Wed, 15 Dec 2004 23:25:59 -0000
Message-ID: <003001c4e2fd$73c35180$dd160550@BensPC>
> From: Ian Hickson 13 December 2004 21:37
> On Sun, 12 Dec 2004, Ben Meadowcroft wrote:
> > > >
> > > > I don't feel like doing a detailed readthrough of the spec again
> > > > (though I did glance at parts that looked relevant),
> but is there
> > > > anything in WF2 that allows only parts of a form that
> have changed
> > > > from their default value to be submitted?
> > >
> > > There isn't; what would the use case be?
> >
> > Seriously though I recently had to frig this by adding hidden form
> > elements using Javascript to the form on an onchange
> handler indicating
> > when a field had been changed so you don't have to do
> lookups on the
> > backend data first to decide if there has been a change or not.
>
> Be very careful with this -- you should always assume that the
> client-provided data is hostile, and not trusted.

Actually I think that rather than submitting only part of a form the form
could be submitted with some additional indication of which form fields
were set. My simple mechanism merely appended the string "_changed" to the
form name of the submitted value so that I could check if the form had
been changed. So for example, a submission of
"value1=test&value2=testagain" became
"value1=test&value2=testagain&value2_changed=true" when value2 was the
form element that was modified. There are no doubt "better" ways of doing
this but the simplest thing that worked won out... You could probably put
it all in one hidden field and use it like the viewstate in asp.net say.

> > You can then dynamically construct an update statement (in SQL say)
> > that
> > only updates those fields that have changed (Which might be
> important if
> > updating certain fields could lead to lots of potentially expensive
> > trigger knock ons in the database).
>
> It's quite possible that the field changed while the page was
> being shown
> to the user, though, for example if the user loaded the page twice,
> modified the pages differently, and then submitted both, or
> if two users
> did the same thing (unknowingly). Since different databases
> would have
> different ways of handling this, I don't know that we would
> want the UA to
> be doing anything about it. It seems like it would be best to let the
> server handle it as appropriate.

This proposal gives the server process a better understanding of what
happened on the client and thus a better chance to handle the input.

> (Note that there is also the problem of how to handle
> checkboxes that I
> mentioned earlier. Any proposal for how to handle this would have to
> address that issue first.)

Not a problem using my mechaism as proposed above, if a checkbox becomes
unchecked it will still submit a "*_changed" field (or equivalent) to
indicate this.

Note that I'm not suggesting we use the "_changed" style or anything, just
that the functionality would be useful.

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3034 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20041215/28262619/attachment.bin>
Received on Wednesday, 15 December 2004 15:25:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:38 UTC