4 Form Validation
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Introduction
Forms and validation go hand-in-hand in most (web) frameworks. A form is defined in HTML, its data encoded and submitted by the browser, as the body of an HTTP request. The framework usually converts the data into an associative array for us, so we can take from it what we need inside the controller. There are a number of things we always have to consider:
- We expect certain keys to exist, but maybe they don’t, because the form didn’t show a particular field, the browser didn’t submit the data, or the user has tampered with the request body.
- We expect certain values to be provided by the user, and expect these values to be within certain lengths, ranges, etc. The user may not have filled in the form correctly, or again, they may have tampered with the request body.
So before we can use the submitted data we always have to be careful about verifying its correctness. We have to make sure that we don’t process invalid data, or even save it into our database. This means we should stop the execution of our business logic as soon as some value is missing or looks wrong. The only way to reliably stop execution is to throw an exception, which will let us jump out of the current method immediately. However, if we stop execution at the first sign of a problem, we’ll have a hard time communicating with the user. We can’t just display any exception message to the user since that poses a security risk.
By relying solely on exceptions for validation, we may also get the user into an endless cycle of trial and error. They fill out the form, submit it, fix the first reported error, submit it again, fix the next reported error, and so on. This isn’t a great user experience. Instead, we want to show nice and friendly (often localized or translated) error messages below each form field for which the user didn’t provide a correct value.
Based on these considerations we may conclude that the two major reasons for performing validation on user-submitted data are:
- To offer protection against invalid data being processed by our application (i.e. guarantee data consistency)
- To help the user provide valid data (i.e. improve the user experience)
Form Validation
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Protecting Data Inside the Model
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Delegating Protection to Value Objects
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Removing Duplicate Validation Logic
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Defining an Explicit Shape for the Input Data
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Rules for Decoupling
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Don’t Pass a Single Array of Data to create()
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Enforcing the Use of Closure-based Form Validation
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Conclusion
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.