[whatwg] [wf2] form submission algorithm questions

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'