Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95131 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15228 invoked from network); 14 Aug 2016 08:50:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Aug 2016 08:50:31 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:6420] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/EA-36656-5D030B75 for ; Sun, 14 Aug 2016 04:50:30 -0400 Message-ID: To: internals@lists.php.net References: <10fbcb03-5de8-4d9a-da1c-7e2bf77937cb@lsces.co.uk> In-Reply-To: Date: Sun, 14 Aug 2016 09:50:25 +0100 Lines: 7 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:CADyq6sKZRBvYFtqyKYVYM4iUEx+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. 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. 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. 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. -- Tony Marston >Other than that, the process of validation is a simple function, and not a >magic box: > >validate :: value -> (bool, [string]) > >It receives a value (nested, if necessary) and tells us if it is valid or >not, plus why (as a set of strings, usually). > >This is validation. Please do use separate terminology if you mean: >* "frontend (client-side) validation" >* "frontend (server-side) validation" >* "domain validation" > >Even more specific if you are going with something different, please. > >On 13 Aug 2016 11:01, "Tony Marston" wrote: > >> "Niklas Keller" wrote in message news:CANUQDCjaXeJsCAjyE+q-UhXC >> FjexwRYWLKzMfwRQVDaEwVbLog@mail.gmail.com... >> >>> >>> 2016-08-11 14:42 GMT+02:00 Lester Caine : >>> >>> On 11/08/16 04:56, Michal Brzuchalski wrote: >>>> > You want to stick such validation at runtime at any time with >>>> > variable >>>> and >>>> > throwing \TypeError at any time constraint is broken - wouldn't it > >>>> cause >>>> of >>>> > throwing much more unexpected exceptions during runtime? >>>> > Imagine you'll be passing such variable with constraint into some > >>>> object >>>> > who operates on it and it should expect \TypeError at any time >>>> > because >>>> you >>>> > newer know what sort of constraint and optional validation callback >>>> > is >>>> > sticked to variable! >>>> >>>> Now this is where the fundamental difference in styles comes in. >>>> PERSONALLY I would not be looking to throw exceptions at all. The whole >>>> point of validation is to handle any validation error ... and it is an >>>> error not an exception. >>>> >>>> >>> If not by using exceptions, how would you handle them if you assign such >>> checks to variables and assign a wrong value? >>> >>> Regards, Niklas >>> >>> >> I agree 100% with Lester. Data validation errors are NOT exceptions, they >> are simple errors. Exceptions are supposed to be for exceptional or >> unexpected events, usually pointing to a bug in the code which needs >> fixing, whereas data validation errors are totally expected and regular >> occurrences. >> >> I solved the data validation problem over a decade ago by writing a >> simple >> validation function that has two input variables - an associative array >> of >> field names and their values (such as the $_POST array), and a >> multi-level >> array of field specifications which has a separate array of >> specifications >> (type, size, etc) for each field in that table. The output is an array of >> errors which can contain zero or more entries. I DO NOT use exceptions >> because (a) they are errors and not exceptions, and (b) if I throw an >> exception on the first error then further validation is stopped, and >> everyone knows that there may be multiple errors in a single array of >> values. >> >> If you are still writing code to perform such data validation then you >> are >> behind the times. If you expect the language to perform the validation >> for >> you then your expectations are unreasonable. >> >> -- >> Tony Marston >>