StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Validating on the client and validating on the server serve different purposes entirely. Validating on the <em>server</em> is to make sure your model invariants hold and has to be done to maintain data integrity. Validating on the <em>client</em> is so the user has a friendly error message telling him that his input would've validated data integrity instead of having a traceback blow up into his face.</p> <p>So there's a subtle difference in that when validating on the server you only really care <em>whether or not</em> the data is valid. On the client you also care, on a finer-grained level, <em>why</em> the input could be invalid. (Another thing that has to be handled at the client is an input format error, i.e. entering characters where a number is expected.)</p> <p>It is possible to meet in the middle a little. If your model validity constraints are specified declaratively, you can use that metadata to generate <em>some</em> of the client validations, but they're not really sufficient. A good example would be user registration. Commonly you want two password fields, and you want the input in both to match, but the model will only contain one attribute for the password. You might also want to check the password complexity, but it's not necessarily a domain model invariant. (That is, your application will function correctly even if users have weak passwords, and the password complexity policy can change over time without the data integrity breaking.) </p> <p>Another problem specific to client-side validation is that you often need to express a dependency between the validation checks. I.e. you have a required field that's a number that must be lower than <code>100</code>. You need to validate that a) the field has a value; b) that the field value is a valid integer; and c) the field value is lower than <code>100</code>. If any of these checks fails, you want to avoid displaying unnecessary error messages for further checks in the sequence in order to tell the user what his specific mistake was. The model doesn't need to care about that distinction. (Aside: this is where some frameworks fail miserably - either JSF or Spring MVC or either of them first attempts to do data-type conversion from the input strings to the form object properties, and if that fails, they cannot perform any further validations.)</p> <p><strong>In conclusion</strong>, the above implies that if you care about data integrity, <em>and</em> usability, you necessarily have to validate data at least twice, since the validations achieve different purposes even if there's some overlap. Client-side validation will have more checks and more finer-grained checks than the model-layer validation. I wouldn't really try to unify them except where your chosen framework makes it easy. (I don't know about Pyramid - Django makes these concerns separate in that <code>Form</code>s are a different layer than your <code>Model</code>s, both can be validated, and they're joined by <code>ModelForm</code>s that let you add additional validations to the ones performed by the model.)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload