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: http://wojtekszkutnik.com/gsoc/gsoc1.png
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.
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