Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95184 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45735 invoked from network); 15 Aug 2016 10:53:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2016 10:53:54 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:29078] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/E0-36656-14F91B75 for ; Mon, 15 Aug 2016 06:53:53 -0400 Message-ID: <25.E0.36656.14F91B75@pb1.pair.com> To: internals@lists.php.net References: <10fbcb03-5de8-4d9a-da1c-7e2bf77937cb@lsces.co.uk> In-Reply-To: Date: Mon, 15 Aug 2016 11:53:47 +0100 Lines: 13 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] Simple variable handling. From: TonyMarston@hotmail.com ("Tony Marston") "Marco Pivetta" wrote in message news:CADyq6s+LjfL5g2mLNz=XSk7BWT=P3vFTGsiCGJGCK-tz0ce5KA@mail.gmail.com... > >Hey Tony, > >On Sun, Aug 14, 2016 at 10:50 AM, Tony Marston >wrote: > >> "Marco Pivetta" wrote in message news:CADyq6sKZRBvYFtqyKYVYM4iU >> Ex+2OuUJvHeP1jznM56k3+hznA@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