OPF: Open Power Forms - ideas and suggestions

[Zyx]

We're launching a new OPL project called Open Power Forms. The new library will be built upon Open Power Template and the main goal is to provide advanced and flexible form support for this template engine. You are encouraged to post here your ideas and suggestions, as it would be good for us to know, what your expectations are.

First, I'm going to post some key topics...

The goal

Many frameworks already provide their own form processors. Some of them are very good, but unsually they have been designed for PHP-based templates and are quite unsuitable for template engines like OPT. The main goal is to create a good form processor that is able to use OPT's rendering features, such as snippets and components, natively.

Forms

The forms will be creating, using the objective approach. We simply create an object of a form class and execute it. The application may have different form classes for different forms and OPF will guarantee proper handling in any context.

The presentation part will be managed with Open Power Template extended with a set of components, new instructions and data formats that will allow to deploy each form in a template and define its layout on the template side with snippets etc. OPF will provide a set of ready widgets built upon the OPT component mechanism. The programmer will be able to define the widget either on the script- or template-side, depending on his/her needs. In simple forms, the widgets could be rendered with a simple sections, whereas in complex forms with specific layout needs, the template designer will have a full control over the layout of each field and the form structure without the need to create 8374394 files and classes - everything in one template.

The key areas:
 - OPF will generate the widget code automatically. The ordinary HTML forms will be certainly supported, but I can also add the support for Web Forms 2.0 or XForms. The programmer would be able to select the output technology in the configuration. If we decide to support XForms, OPF will need to provide the necessary framework to render the forms in this technology, as XForms is quite complex.
 
Refactoring

The code refactoring and portability will be provided with event listeners, where the programmer will be able to write the entire support for a commonly used feature (i.e. "tag behaviour") and add it to several forms. Furthermore, he will have a possibility to store the definitions of commonly used fields in one, centralized repository.

AJAX

OPF will support AJAX. The forms will be able to respond to the AJAX events in the same way, as to the library-generated events. There must be chosen AJAX library and created some JS generator.

Validation

OPF will provide its own validators and data filters.

External support

In the future, we are going to replace the Zend_Form with OPF in the OPL port for Zend Framework, removing the last dependency with Zend_View.

Furthermore, I'm thinking about a built-in support for Doctrine ORM, i.e. by providing some helpers for it in the standard distribution. Currently, I have two ideas:
 - A helper that will prepare the form from the model definition.
 - A helper that will save the form data to the model automatically.

OK, now it's your turn :).

[eXtreme]

CSRF support, like in symfony forms - with global and per form enabling/disabling.

[Alan vel LBO]

Because eXtreme did mention about Symfony, I'll write one thing I would like to see in OPF, based on what I don't like with sf forms.

sf doesn't provide support of field-objects out-of-box. By field I understand object which holds both: validation and presentation data.

So, in place of:

Code:

$this->setWidget('commercial_activity_number', new sfWidgetFormFilterInput());
$this->getWidget('commercial_activity_number')->setOption('with_empty', false);

$this->setValidator('commercial_activity_number', new sfValidatorSchemaFilter('text', new sfValidatorCommercialActivityNumber()));

I would rather just drop-in:

Code:

$this->setField('commercial_activity_number', new CommercialActivityNumberField());

Of course I'm not against decoupling of validation and presentation. But creating some kind of glue in between is crucial for simplifying initial configuration .

I think this point is valid even if OPF won't resemble sf forms in a bit and you should take it into consideration.

Cheers, Alan

[Zyx]

Alan vel LBO -> OPF will do have field objects :).

[Zyx]

Another point to wishlist:

* PHP 5.3/6.0 unicode support.

[eagle00789]

when using a textarea, please provide support to use a WYSIWYG editor (one of the users choice...)

[Zyx]

Good idea - actually I think the WYSIWYG editor would be available as an another type of widget or something like that.