Yes, I was definitely interested in your work. Well, I didn’t say this is how it will be released. It was just a neat summary.
If I could have a suggestion, I’d recommend not to fully remove subviews. One may want to call [font=“Courier New”]$form->render(‘path/to/view’);[/font] so it’d easy to customize the output html.
My other idea is naming syntax. Currently, ids and names are fully auto-generated. What about naming rules, which can determine both?
A naming rule may look like form-{type}-{attribute}. In this case, {type} and {attribute} would replaced by the input field type (text, password, dropdown, etc.) and attribute name identified by form respectively. A rule also may be empty, which means the corresponding html attribute should be omitted.
For subviews, I think one can do $this->renderPartial('view', array('form'=>$form)) to explicitly render a form. This is nearly the same as $form->render('view'). The only difference is that in the view, $this would refer to controller/widget in the former case, while in the latter case it refers to the form object.
The current implementation allows you to customize id easily:
I already use the subforms. They are very convenient.
A quick thought regarding tabular input:
Maybe a Form may take a single model instance or an array of model instances.
In the first case it works as of now in the latter case it builds the form using the tabular input method described in the guide, which should work as the form already reuses CHtml to build the input elements.
With that forms and subforms could be used for tabular inputs.
The data collection of this tabular input forms could also work like the solution described in the guide.
I will think about your suggestion. Feel free to let me know if you have any other suggestions with CForm. This is new thing that we don't have much real experience yet.