Hey Tony, On Sun, Aug 14, 2016 at 10:50 AM, Tony Marston <tonymars...@hotmail.com> wrote:
> "Marco Pivetta" wrote in message news:CADyq6sKZRBvYFtqyKYVYM4iU > ex+2ouujvhep1jznm56k3+h...@mail.gmail.com... > >> >> So much confusion... >> >> There are 3 (or more) types of validation in pretty much every web-app, so >> let's please stop calling it simply "validation". >> >> 1. frontend validation (unsafe/unreliable), prevents invalid data >> submission, makes things friendlier for the user >> 2. form validation, in the application layer (your mvc framework or your >> entry point php script): returns error messages to the client (in HTML or >> json or whatever you prefer). It is still not the source of truth >> 3. domain validation, in the core of your domain logic, throws exceptions >> and generally stops execution whenever invalid data is provided: no nice >> error messages required, except for logging/debugging purposes >> > > I do not perform any javascript validation in the frontend. > > I do not distinguish between the application layer and the domain layer. > My framework is based on a combination of the 3 Tier Architecture with its > separate Presentation, Business and Data Access layers and MVC where the > Model is the same as the Business layer and the Controller and View exist > in the Presentation layer. All data validation is performed in the > Model/Business layer objects. > User-side validation, together with simplistic form validation, are both unreliable, and are just added as a layer to "make errors nice and comprehensible to the user". Domain-layer validation does cause exceptions to be thrown. You are supposed to build them in this order regardless: 1. domain validation (fails hard, makes your app crash on purpose, non-recoverable by design) 2. frontend/form validation (fails with error messages to be returned to the user-agent) 3. client-side validation (just added UX, nothing else) The fact that you don't distinguish between application and domain layer is mostly your problem: means that you will have an incomprehensible mix of 1 and 2 at some point (from what I saw in your answer, you seem to have the typical CRUD/anemic domain). > All primary validation - that which is required to verify that the data > for each column matches the specifications for that column - is carried out > by a standard routine within the framework and does not require ANY code to > be written by the developer. The standard routine uses a list of field > specifications which originate from the table's database structure. The > only validation which requires developer intervention is what I call > secondary validation, such as checking that date1 is greater than date2. > These rules should be made explicit. It's fine to have them inferred, having a DSL for them, a validation framework, etc., but they need to be clear, as they are part of your API specification. I NEVER throw exceptions for validation errors as they are NOT exceptions. > They are common occurrences, and my validation routine can produce multiple > errors whereas it could only throw a single exception. > An error or an exception are the same thing, where I come from, Error being a sub-type of Exception. User input is neither an Error nor an Exception, it's just a set of data that you label as valid/invalid, plus you tell "why". That's a function. You then define if continuation in your program's execution requires validity, or if an invalid data handler should produce a different response. > If you are still writing code to perform primary validation on each field > then your coding style is way behind the times. > > If you want the language to change to perform this validation for you I > would strongly suggest that you first learn how to write a standard > validation function in userland code - which I did over 10 years ago - > instead of trying to make the language more complicated just to cover up > your own shortcomings. > There are dozens and dozens of userland stable/maintained/secure libraries that handle these sort of problems: * https://zendframework.github.io/zend-validator/ * http://symfony.com/components/Validator * https://github.com/Respect/Validation And a load more (just peek into https://packagist.org/search/?q=validation). The most relevant ones are usually maintained by knowledgeable people with an acute sense for software security. Dragging more of these features into the language would just complicate things for php-src (security-wise), and reduce the bugfix/patching speed, since sysadmins don't upgrade PHP versions that often (sigh). If the entire suggestion is about what Lester said (standardizing currently existing approaches), then I suggest that you bring this up with the authors/maintainers of those libraries first, asking for what they actually need, or what their users' needs are. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
