On 15/08/16 06:17, Stanislav Malyshev wrote: >> There is misunderstanding on this. >> > As I wrote explicitly in the RFC, input validation and user input >> > mistakes must be handled differently. >> > >> > "The input validation (or think it as assertion or requirement) error" >> > that this RFC is dealing, is should never happen conditions (or think >> > it as contract should never fail).
> This is what I'm not sure I understand - when this approach would be > used? I.e. if I get data from the user, I surely can not claim I can > impose any conditions on the data that would never fail. Is it assumed > I'd pre-filter the data before passing it to this filter? Keeping things simple ... I like your nice flowchart ... BUT Input logic is a LOT more complex than that. I need to be able to use the rule set that you are hiding in the filter to CREATE the page that your little man is looking at. Those rules create the browser side validation everybody seems to think is pointless, but is essential in modern web apps? Those rules may well flag that if some 'variable' already exists browser side actions can amend the workflow and load the selected data. At the very least input validation once the input array reaches the server may require different rules based on some of the responses, and 'business logic' requires 'sanitized' variables to carry out that process. Sanitation that may vary depending on the workflow. Basically the simplistic view that everything can be reduced to a fixed single chain is not what happens in reality. The output array to amend the stored data WILL have a different set of variables depending on the route through, so any filter needs to be able to be built from the set of rules that the variables define. And in my own storage process, the set of variables being stored are individual records in table who's wrapping transaction must complete or roll back and add new failure flags to the set of variables before deciding what to return to the user screen. You can not assume your output process will complete without errors and those errors will amend the rest of the chain. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
