D For A Web Developer

[via Digitalmars-d]

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.