Google Groups

Re: [silverstripe-dev] Re: [GSoC 2012] Form and Model Validation

Dan Rye Apr 24, 2012 3:09 PM
Posted in group: SilverStripe Core Development
This might be of interest to those following this thread:

On Fri, Apr 13, 2012 at 4:14 AM, Wojtek Szkutnik <> wrote:
> I agree that this is something that a SilverStripe developer should be able to do.  For my own apps, I'd probably put email validation on the model and use put on the end of my dummy entries, but that's not something the framework should mandate.

Actually, I beg to disagree on this one :) Dummy data for E-mail
fields is or something similiar, and if you try to
put invalid data into the ORM, it should fail validation. Basically,
if you decide to use an E-mail field, the ORM should validate it as an
E-mail - obviously, you can always perform a raw sql query since the
field is usually represented as a varchar field, but ORM should always
validate the data based on the field specs - that's what it is for ;-)

> However, I don't like that the example talks about "constraints" in one half of the app and "validation" in the other.  This seems like an unnecessary distinction.  However, the difference between constraints and validation could be useful as follows:
>  - "constraints" define validation rules that can be expressed as a set of properties rather than procedural code.
>  - "validation" extends this, adding the kind of validation that needs to be coded.

That's pretty much what I had in mind :)

> Your thinking seems to be going in a direction that the developer who provides the specific DBFields/FormFields/FormWidgets is not responsible for defining the specific
> validation rules for these fields - and these only get configured on the compound structures such as model or form?

Actually, from my point of view, the fields should have some basic
validation rules (obviously, the validation rules for role-specific
fields such as an E-mail field, should use more strict validation than
a imple TextField), but the developer should be allowed to define
additional validators for these.

As for $form->addValidation(function($validationContext) { ... });, I
think it's a code design decision - should we allow to change the
validators from any point in the code? Enforcing validation rules on
form definition seems reasonable in most cases - makes the code much
cleaner. We could probably have some backdoor for specific uses, but
in 99,9% of the cases specifying validation rules on form definition
should be enough.


You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at