"Marco Pivetta" wrote in message
news:CADyq6s+LjfL5g2mLNz=XSk7BWT=p3vftgsicgjgck-tz0ce...@mail.gmail.com...
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.
I disagree. Common data validation errors are NOT exceptions. Exceptions
should only be thrown in EXCEPTIONAL circumstances and normally indicate a
problem in the code that needs fixing.
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)
Again I disagree. Data validation is performed in only ONE place, and that
is the business layer (the Model in MVC).
The fact that you don't distinguish between application and domain layer is
mostly your problem:
It is not a problem at all. My code works perfectly well, and as it does not
cause any problems it does not need fixing.
means that you will have an incomprehensible mix of 1
and 2 at some point
It is not incomprehensible at all. Data validation is performed by a single
routine which is automatically called by the framework code and does not
require any intervention by the developer.
(from what I saw in your answer, you seem to have the
typical CRUD/anemic domain).
Wrong on both counts. While I do have transaction patterns which can perform
the basic Create/Read/Update/Delete operations on any of my 300 database
tables that accounts for only 4 patterns while my library actually contains
over 40 patterns. That immediately says that my framework is able to provide
much, much more than the 4 basic CRUD operations.
Some people look at my code and say that my classes are anemic while others
say the opposite and accuse me of creating a GOD" class that tries to do
everything. Those people are all wrong. I have a large abstract table class
which contains all the standard functions that can be performed on any
database table, while each concrete table class contains only that code
which is specific to a particular database table. All the standard code is
inherited from the abstract class.
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.
Validation rules are NOT part of any API specification. An API contains
nothing more than a method name and its arguments. Data validation rules can
be extracted from the table's structure in the database schema.
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.
I disagree. You may have been taught that, but it just points to bad
teaching. I was writing database applications with data validation rules for
25 years before I switched to OOP with PHP, and none of those previous
languages had exceptions. When I first heard about exceptions (which did not
exist in PHP4) I read that they were only to be used in exceptional
circumstances, and there was no indication that data validation errors fell
into that category. I have NEVER used exceptions for simple data validation
errors, and I see no reason to change the habits of a lifetime.
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
I don't use any of those as they did not exist when I developed my own
framework with its own method of performing data 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.
I don't care about other people's validation libraries as they did not exist
when I started using PHP in 2002. I built my own framework with its own way
of performing data validation, and this has worked flawlessly for over
years. While I have added to the code over the years to provide enhancements
and the ability to deal with new circumstances, I have never seen the need
to replace it with somebody else's inferior offering.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
