How else would you validate with the server and provide user feedback on the page with JavaScript? If you actually submit as usual, reload a new page that validates on the server, just write the validation errors old school with the server side code, right?
Anyway, that script was in a one page ajax application. All I ever did in it was send JSON to the server and send JSON back. If it validated, I'd do something, like animate the form out of view and update some widget with the data somewhere. You could just as easily do window.location if it validates. It's server-side validation that feels like client-side validation. On Oct 14, 2010, at 2:46 PM, hairbo wrote: > @Aaron, thanks for the reply as always. Of course, you're right that > good client-side error catching should mean only clean data makes it > to the server, but I shudder at the thought of relying on client-side > validation only. See? I'm shuddering right now. Man, it's cold. > (-; > > If I man up and screw around with Form.Validator.Inline, I'll post > that to this group, if I think the effort is worth the pixels it's > written on. I'll also see if I can take a stab at integrating server- > and client-side error handling. It sort of depends if I think my > overlords will let me screw around with that on company time. > > @Ryan, neat code. Question, though: why do the form submission as > JSON at all? Why not just do a regular form post submission? > Returning JSON makes sense to me, but (unless I'm missing something) > it seems like posting the data via JSON is extra work for not much > win. Have I just opened myself up to ridicule by posing such a > question? > > On Oct 14, 1:22 pm, Ryan Florence <[email protected]> wrote: >> I found this old class. This was one of the first things I ever made with >> MooTools (and JavaScript.) It's surprisingly not completely horrible :) >> >> http://jsfiddle.net/rpflorence/cn8a2/ >> >> It posts the form with JSON, then if it finds an 'error' key in the json it >> runs through that to find all the elements with errors and provides a >> message. Otherwise fires a validate event. >> >> On Oct 14, 2010, at 11:32 AM, Aaron Newton wrote: >> >> >> >>> Sorry to chime in rather late here; was out of town. >> >>> Cheap one: I see the default error behavior I get with >>> Form.Validator.Inline. It's nice, but I was wondering if there was a >>> catalog out there somewhere of other ways to handle the error >>> messages. For example, I'd really like to have the error message >>> appear inside the <label> tag, but I'm trying to be lazy and not write >>> my own...<ducks>. >> >>> If you look at Form.Validator.Inline you'll see that there's not a ton of >>> code. Further, if you extended THAT class you could easily overwrite how it >>> injects feedback into the DOM. >> >>> More in-depth one: So client-side validation is nice, but obviously, >>> you still need to validate data on the server, and you still need to >>> be able to return errors from the server back to the client if you hit >>> errors. So, from that perspective, the only thing that client-side >>> validation really wins you is less of a server load, and maybe a nicer >>> experience for the end user. >> >>> The slick thing to do would be to somehow integrate error messages >>> spit back by the server with error messages from Form.Validator. I'm >>> not 100% sure what the behavior should be like, but in a general way, >>> I'd imagine that the server would return <div class="validation- >>> advice"> tags that somehow Form.Validator would pick up, and then >>> appropriately display (and then appropriately remove, if/when the user >>> inputs data in the proper format). I guess my question is...does this >>> kind of integration exist? How do other folks handle this sort of >>> thing? >> >>> There is not, though I've often found myself contemplating it. I don't >>> think it would be all that hard, but I've never had time for it. In theory >>> the clientside validation should prevent an invalid form from being >>> submitted, so the server errors are never visible...
