Symfony-framework.com

Fabien has returned from the IPC 2007 in Frankfurt and he has published all the slides of his presentation in his new blog.

He promised to commit the last two missing classes (sfForm and sfFormField) by the end of the month.

After that commit, the last missing element for the waited new Framework will be the documentation.

In this article, I will briefly explain all the significant changes of Symfony 1.1 so that you will have fewer doubts deciding between: rewrite part of your old code, simply update your application or use the new Symfony 1.1 only in new developments.

I will really appreciate your comments and your choice about upgrading.

Mauro Casula
symfony-framework.com

• New task framework

The new task framework will be very simple to extend and will be organized in task namespaces.

Task namespaces examples:
> symfony generate:app …
> symfony generate:controller …
> symfony generate:module …
> symfony plugin:install sfGuardPlugin

In addicion, it has been introduced a very usefull task help system:
> symfony help plugin:install

It will be possible to call a task directly from the code:
$task = new sfCacheClearTask($dispatcher);
$task->run();

• Event dispacher and dependencies re-organization

Developers worked very hard over the core classes, removing dependencies and singletons and introducing a new event dispatcher system.

• New Form, Widget, Validator framework

As I wrote in my previous post, the symfony form handling system has been completely rewritten.
The old validation system will be still included in Symfony 1.1; the only thing we have to do about to still use is to set the parameter “compat_10: on” in settings.yml.

The new approach consist of three different sub-systems:

- Widgets ( sfWidget )
- Validators ( sfValidator and sfValidatorSchema )
- Forms ( sfForm )

Each one of these sub-systems are stateless, completely independent from the other classes;
so it will be possible to use this system outside a symfony application.

Widgets:

A widget is an object that can be rendered as an HTML string. It substitutes the use of the helpers.
The base class of all form widgets is called sfWidgetForm: Symfony 1.1 will provide a set of ready to use widgets like sfWidgetFormInput.
The use of a Widget is very simple and similar to the use of a helper:

// create a new input widget
$w = new sfWidgetFormInput();
// render widget
echo $w->render(’first_name’, ‘Fabien’);
// returns the widget as HTML
<input type=”text” name=”first_name” value=”Fabien” id=”first_name” />

In Symfony 1.1 will be introduced the sfWidgetFormSchema class.
A widget schema is simply a group of named widgets.

$w1 = new sfWidgetFormInput();
$w = new sfWidgetFormSchema(array(
‘first_name’ => $w1,
‘last_name’ => $w1,
));

Validators:

As in the old releases of Symfony, all validators will extend sfValidator class.
Validator class is stateless and you can aggregate validators to create new extended validators.

The concept of a validator schema is very similar to the concept of widget schema.
A validator schema is a set of named validators.

Forms:

Fabien define a Form as the glue between a validator schema and a widget schema.

The sfForm class will be the class the user will use when he have to interact with a Web form.

From the model to the view, from the view to the validator and from the validator to the model
sfForm class has all the methods you need for build an html form, to set the apropriate
validation rules of every field and finally for retrieve the data and save it.

I will close this article, writing about the sfFormPropel class.
I think this is simply the best we can expect from a framework.
sfFormPropel class introspects the Propel schema and maps Propel/Creole types to symfony validators and
widgets, intercepting foreign keys and many to many relationships.

Symfony 1.1 will be a little revolution.
Maybe, many developers will use the “compat_10: true” option instead of rewrite the form and validation code of their applications, but for the new projects new features will be the best way.