Google Groups

[Gsoc 2012] Form and Model Validation

Wojtek Szkutnik Apr 6, 2012 2:59 AM
Posted in group: SilverStripe Core Development

I just wanted to say "hi" to all fellow GSoC applicants and SilverStripe developers and post some basic ideas about the Form and Model Validation project, which I'll be applying for this year.

Since Form/Model validation is a vast topic and will probably take much longer than one GSoC project, I tried to break it down into several parts: I believe that the Form API and ValidationTransaction are vital to form validation, but their presence in the project depends on how fast we'll progress with the more basic stuff. 

In the following paragraphs I will be referring mostly to Django, since I believe its validation system is reliable, flexible and it's certainly the best one that I worked with. 

What I would like to make priorities of the project are:

1) Introducing Form Widgets.

Django uses two very closely related elements, when it comes to forms: Fields are related to the database representation and backend validation of the values. Widgets are frontend representations of fields. 


A TextInput widget is a simple <input type="text" /> field, which can represent multiple fields. Both CharField and EmailField are represented by the same widget (TextInput), but they have different backend validation rules and different default settings/values.\

I believe that we could implement the same mechanism in SilverStripe. It allows for much more flexibility, makes the code a lot cleaner and easier to modify.

The fields (and maybe widgets as well) can have multiple and custom validators. This is also the most handy way to define some common attributes such as the "required" flag which definitely doesn't belong to the validator, min/max values, and default values.

Also, widget could have some basic attributes which would allow to add additional css classes or html attributes. To make it as clear as possible, I have prepared an image to illustrate it on a very basic level:

2) Refactoring the validators system

This aspect is closely related to my previous point. SilverStripe should allow easily modifiable, highly flexible per-form and per-field validators - this is absolutely crucial for making Forms something more than just a tool for saving data into Models/DataObjects.


Considering the complexity of this task, probably both the scope and the timeline will be subject to heavy discussion during the following weeks. I have tried to estimate the obvious tasks and schedule some time before the coding phase for heavy discussion. 

I haven't included Unit Tests in any description because, obviously, they are developed on a per-feature basis. This leads to a 20-35% increase of development time but eliminates loads of bugs and provides an easy to maintain codebase.

April - May 21 - discussing the project with developers and the community. I believe that the main points of the discussion would be model vs field validation logic and the degree of using DataObject->validate(). Also, this period will probably let us determine a more strict schedule for the project - it obviously has a lot of potential features and choosing their priorities will be as much important as discussing the technical solutions. For instance, the proof of concept for SilverStripe metadata-driven JavaScript validation depends on how extensive the main tasks will be. 

May 21 - June 15 - I believe that during this phase we will mostly concentrate on developing a proper FormField implementation (I feel that there will be a lot of rewrites going on over there). 

Also, the duration of this period depends on how extensively we'll decide to develop the "ModelForm". 

June 15 - June 30 - possibly implementing the form "widgets" described above and separating the interface forms layer from the data management layer. 

July 1 - July 15 - implementing validators, constraints and customisation features for fields and widgets

July 15 - July 30 - First steps related to JavaScript/jQuery validation libraries integration (binding them with optional form attributes etc)