CForm
Rate Topic:

Building HTML form is often time-consuming and repetitive. Currently, we usually call CHtml methods to generate labels and input fields, and embed them in HTML code. If we need to different a new form, we would repeat the whole process again. The proposal for CForm is to alleviate this problem.

The main idea is that we use a CForm object to represent the collection of the input fields. The CForm object is backed by a model object which is responsible to perform data validation and other biz logic. The CForm object itself doesn't have any logic and only serves as a container of the input field specifications. For example, a CForm object could be built as:

You may think such rendering is too rigid. If so, you may write another view template, or simplest render the form element one by one in a very complex form layout.

So what are the benefits of this additional abstraction? First, the same CForm object can be rendered using different view templates, which means reusing the form. Second, the same view template can be used to render different CForm objects, which means reusing the view template. Third, when developing a form, developers can focus on writing the form spec while designers focus on views or view templates.

This is a great nightmare in Zend Framework world...
You must google for an entire day and find only one article explaining...

You can have 2 options.
1 - Let the object render their selves with Decorators, subforms and they element (text, radio..) with pre-set html wrappers.
Good for simple form.
Bad for a little complex form.

You make a template and renders each html element in they respective position.

Quote

3. How to group form elements?

I think this was answered in 1.

The CForm idea from qiang is nice.
But please don't do the form thing as in the zend framework it is a nightmare!! I left zend framework mainly for its form management. It is impossibile to customize the html in the form without becoming crazy with decorators etc.

Thank you for the reference to Zend_Form. Yes, I did study it a little bit and also similar feature in other frameworks. I agree that we should not put too much logic and presentation in the form object. While Zend_Form does offer maximum flexibility, its usage is overly complicated and may not be practical as well.

The idea of Yii form is very simple: the form only contains specification of input fields. We let data models to do biz logic, let views to do presentation, and controller to be responsible for binding them all.

Right now the main problem I am considering is how to reuse CHtml in CForm. My original proposal uses widgets as input types, which would require us to implement a widget for every active* method in CHtml.

Right now the main problem I am considering is how to reuse CHtml in CForm. My original proposal uses widgets as input types, which would require us to implement a widget for every active* method in CHtml.

The fiddling I did a while ago with form generation gave me the same impression. Any idea on how to handle labels?

Right now the main problem I am considering is how to reuse CHtml in CForm. My original proposal uses widgets as input types, which would require us to implement a widget for every active* method in CHtml.

I think this is the right way to go.

The final user should only know how to use it and don't concerd if it has thousand widgets.

In the end, it will be severial widgets using helpers. They would have minimal line of codes.

Thank you for the reference to Zend_Form. Yes, I did study it a little bit and also similar feature in other frameworks. I agree that we should not put too much logic and presentation in the form object. While Zend_Form does offer maximum flexibility, its usage is overly complicated and may not be practical as well.

The idea of Yii form is very simple: the form only contains specification of input fields. We let data models to do biz logic, let views to do presentation, and controller to be responsible for binding them all.

A widget class is made for every type of field. There will be a CPasswordField, CTextField etc. These classes will inherit from CField which in turn inherits from CFieldBase. CFieldBase will contain any shared logic between the field classes. CField will be a dummy class which the user can override in his app in order to extend all field classes.

CFieldBase should contain an internal method getLabel() that gets the label from the model. It is used if the label is not overridden in the form config array. This way the user could override this method in CField, for instance to add a period at the end of the label, or make it uppercase. Edit: Actually maybe the labels would be better to be modified in the view?