On 10/23/07, Peter Karman <[EMAIL PROTECTED]> wrote: > The other thing I haven't yet got to (but was hoping to work on today) is some > ways to tie the validation pieces of RHTML and RDBO together so that the > validation code can be defined in one place. As Cees noted earlier in this > same thread, the default validation code in RDBO is actually less stringent > than the equivalent in RHTMLO, and so right now I am leaning towards a way to > make my RDBO classes call the RHTML::Form::Field validator() code. Any > thoughts about this?
Here's my take. In every large web application I've ever written, the validation imposed by the database, ORM classes, and HTML forms have been different. For example, a database column may accept a 32-bit signed integer (say, because the db doesn't have an "unsigned" type) but the RDBO column only accepts positive numbers, and one of the form fields that takes user input for this column presents a pop-up menu containing only the integers 1-100, while another (say, in the "admin" interface) accepts any positive integer below 1,000,000. IOW, there's a very good reason that validation exists in all these separate places in the Rose framework: so they can diverge. IMO, people are missing the forest for the trees when they compulsively apply DRY. In particular, it's almost always a bad idea to combine HTML form validation and ORM/db constraints. Again, in every large web app I've created, each database table has several forms that write into it--sometimes only writing partial values. The HTML form layer is usually the most restrictive, the ORM less so, and the db itself is the most permissive. At each level, business rules and permissions dictate the ever-increasing specificity of the validation. That's not to say that it's a bad idea to initially *derive* validation from the db metadata. That's a great starting point. But I'm wary of any attempt to *combine* it all into a single place, making it harder to diverge the validation at each level, because IME that always needs to be done eventually. -John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
