Validation as property of the form

In the CakePHP framework, validation rules ar a property of the model. That is, it does not matter where the data comes from: when you want to write it in a model, it will have to pass the validation.

Instead in symfony, you specify validation rules per form. Since there may be more than one form per model (and forms may involve data from different models) the result is that data for some model may have to pass different filters, according to the form it comes from.

开发者_如何学Python

I understand that this might be occasionally useful, and indeed CakePHP provides methods to specify different validation rules on the fly if you want to. But this is the exception, not the rule. It seems to me that designing the other way opens the door for bugs, where you update your validation rules, but forget to check all the forms.

On the other hand I'm sure that Fabien Potencier is smarter than me, and probably has put some thought into this design. So mhy question is:

What are the good reasons to have per-form validation (as a rule, not as an exception)?

---

I would say that they are 2 different things.

Model Validation - validates that the data coming into the model is valid for persistence and maintains business logic integrity (common CakePHP validation)

Form Data Filtering - validates that the form is filled in using acceptable values. Obviously there is some overlap and a lot of the time the form validation is handled by the model validation. Other times it might not be.

For example, a form might need to know the state of a checkbox in order to determine the next section of a wizard that needs to be displayed. This has nothing to do with the model but is a valid validation requirement. (checkbox or radio button has a value in a set of legal values)

Of course, using CakePHP you can easily enough write a component / behavior combo that deals with both scenarios using keyed indexes in the validation array. Easy enough to set a key 'default' that gets used always, and a key for each 'action' that determines additional validation logic.

There are even a few pre-built solutions if you google a little bit.

---

You forget about inhertitance. Here's what I mean:

• basic validation rules come from your database schema, stuff like string length, field type, etc. - these go into the BaseModelForm class
• you can easily override these in subclasses, like ModelForm (and you are advised to, as Base~ classes are autogenerated and you'll lose your modifications at the next regen)
• you can subclass these again if you need to alter a few validators (or widgets).

I sometimes have different validation rules per form, like one for the backend, one for the frontend - even though they are dealing with the same model. Basic rules come from the autogenerated class, and I change a few widgets and validators, or remove a few.

---

Good reasons as far as I know: 1. Few forms. 2. Forms with vastly different functionality. 3. email might need to pass different validations (login email might need to have a URL from email@thisSite.com, while registration emails can be from any domain).