On Thursday, 1 May 2014 at 15:11:07 UTC, Nick Sabalausky wrote:
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:

IMO the client shouldn't do any validation, unless you can really, really trust it. That's why I like to do things the following way:

1. user input on the client
2. post using ajax
3. server validates and stores the data
4a. if transaction or data is invalid fails, send errors to the client 4b. if everything's ok, tell the client to redirect to the next page 5. on the client, add error CSS classes to the relevant fields, or execute the redirect


That's a lot of unnecessary back and forth to the server for a
JS-based design. Plus it avoids some of the nicer UX enhancements JS can enable, like validate-as-you-type, and does so without the
benefit of not requiring JS. Kind of a worst of both worlds (no
offence).

Well, naturally I disagree :-)

It's exactly two requests to the server, same as for a normal form submission without JS:
- one for the actual submission
=> server responds either with the errors, or with a redirect URL - and another one for requesting the next page (only if everything was ok)

Technically, you could already send the contents of the new page with the server response, but this has several drawbacks (doesn't change the URL, double POST on reload, etc.), so a redirect is pretty much standard.

I don't see how you could improve on that in respect to the number of requests...

It also degrades gracefully if JS is not enabled: In this case, the form submission will not be intercepted by the JS and therefore won't be turned into an AJAX request. The server notices that it's not an XHR request, and automatically responds by rerendering the form view with all the CSS classes and error messages in place. (This requires a bit more work on the server side, but not a lot.)


Naturally, the server needs to do validation no matter what. But
there's nothing wrong with doing an optional preliminary
validation on the client side first.

Exactly. I just feel that client-side validation is unnecessary duplication in most cases. But sure, it can be used where it makes sense.

Reply via email to