Re: [whatwg] [wf2] form submission algorithm questions
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] form submission algorithm questions
On 4/16/07, Kristof Zelechovski <[EMAIL PROTECTED]> wrote: What do you mean by "rinse"? Only the end user is in position to make the necessary corrections if the input is invalid. Any interaction with the user should not be executed inside a loop because it is a frustrating experience where you do not know where you are, what you are operating on and how to get out of this mess (reminds me of Emacs recursive edit mode) so that "repeat" afterwards really does not make sense. After the user feels ho is ready, ho can resubmit, triggering another event thereby. Chris I apologize, "rinse and repeat" is a familiar idiom in the U.S. after shampoo bottles started including these instructions. If there is something wrong with the input (as decided by the application), feedback is provided to the user, and she is given an opportunity to fix. This process is iterative (eg rinse and repeat) so that the user can iterate towards success without suffering consequences (such as long waiting times) in between corrections. My proposal intends to put the user in control by offering a more immersive and responsive control, reducing spurious or confusing error messages (of the ilk "you need to enter a string instead of a number"). There is no automatic procedural loop, just an iterative process for validating and submitting sane input. Thanks for pointing out the ambiguity. -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, April 16, 2007 12:11 AM To: WHAT Working Group Mailing List Subject: [whatwg] [wf2] form submission algorithm questions [cut] 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 [cut]
Re: [whatwg] [wf2] form submission algorithm questions
What do you mean by "rinse"? Only the end user is in position to make the necessary corrections if the input is invalid. Any interaction with the user should not be executed inside a loop because it is a frustrating experience where you do not know where you are, what you are operating on and how to get out of this mess (reminds me of Emacs recursive edit mode) so that "repeat" afterwards really does not make sense. After the user feels ho is ready, ho can resubmit, triggering another event thereby. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, April 16, 2007 12:11 AM To: WHAT Working Group Mailing List Subject: [whatwg] [wf2] form submission algorithm questions [cut] 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 [cut]
