[whatwg] [wf2] form submission algorithm questions
Ian Hickson
ian at hixie.ch
Tue Oct 28 16:16:57 PDT 2008
On Sun, 15 Apr 2007, Benjamin West wrote:
> At
> http://bewest.wordpress.com/2007/04/10/webforms-2-submissionvalidation-model/
> , I discuss the submission/validation algorithm specified in
> http://www.whatwg.org/specs/web-forms/current-work/#form-submission .
> Applications won't be able to trust any incoming input, without some
> mechanism that ensures that the validation steps have been followed.
> Even if such a mechanism existed, I suspect (but lack evidence) that
> most applications require additional validation beyond type and format.
> I also am a bit confused about the usability issues surrounding exposing
> errors in the input type and format to end users.
>
> This creates a maintenance problem: two implementations performing some
> set of similar capabilities. When I do validation in my web
> applications, I implement all the validation on the server, and expose
> the validation through some protocol. Many times, I use some
> combination of XHR + submission + json formatted responses. This
> ensures one implementation that allows the application to communicate
> its expectations of valid input beyond format and type.
>
> Would it be feasible to modify the algorithm to specify some kind of
> protocol to iteratively validate content until it's correct? The
> type/format validation is ok as a baseline for communication an
> application's expectations of input.
Part of the desire here is to dramatically simplify the code and make the
UI much faster. We can't really rely on a server round-trip here, that
would defeat the point. And the code to do this kind of validation would
probably end up non-trivial in comparison to having the validation UI all
client-side and the server just having a generic error message when the
validation fails server-side.
Authors are welcome to implement what you describe themselves, though,
using setCustomValidity().
> I suggest something like:
>
> 1.) Step One: a new event "onvalidate" is dispatched
> 2.) Step Two: Identify form controls.
> 3.) Step Three: build form data set.
> 4.) Step Four: encode data set.
> 5.) Step Five: submit data set to validation URI.
> 6.) Step Six: dispatch recieved
> 7.) Step Seven: process validation results
> if response indicates validity->
> Submit using steps 2 - 8 of original algorithm.
> if response indicates invalid input->
> rinse and repeat
>
> There's a lot of stuff missing from this proposal, I suppose, and I'm
> not even sure how feasible it is to introduce events like onvalidate (or
> some analog).
>
> The protocol for the messages exchanged and the format of the response
> would need to be specified. The data set submitted for validation
> should probably include either the type information specified in the
> markup, or an identifier unique within the application. I suspect some
> profile technology, perhaps combined with XBL, could provide mechanisms
> for facilitating useful error handling interfaces for the end user.
> I'm also unfamiliar with any security concerns.
I think I'd rather see people experimenting with doing this before we
specify a formal way to do it.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list