[pestaa]

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 $form->render('path/to/view'); 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.

How does this sound?

[qiang]

Thank you for your comments.

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:

'username'=>array(

   'type'=>'text',

   'id'=>'username',

)

I'm not sure about name generation. It is required so that data population is smooth.

[pestaa]

Well put. Very true indeed. It is nice to know we can still use traditional ways instead of adding complexity.

[sdietz]

I really like what I've seen of this Formframework so far.

Also started tinkering with it and porting some of my projects to put it to use.

I may have missed how the tabular input using subforms is used. Could somebody give me a heads up regarding this? (eg. a Game a 2-* Players)

[qiang]

Currently CForm is not designed to work with tabular input yet... It can work with multiple models via subform, though.

[sdietz]

Ok.

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.

[qiang]

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.

[thyseus]

Hello,

is it possible to add an Widget to CForm, that automatically resolves foreign key relations? An example from the CForm-extended Blog demo:

	'status'=>array(

					'type'=>'dropdownlist',

					'items'=>Post::model()->statusOptions,

This could be made easier, since the relation is defined in the Model, something like this:

	'status'=>array(

					'type'=>'foreignkey',

                                        'style'=>'dropDownList',

					'fkmodel'=>'Post',

                                        'fkfield'=>'Status'

Of course, this would only generate the Options "0,1,2" - but i think there could be a lot of Situations where this Widget could be helpful.

I would highly appreciate this (or similiar) function

[pestaa]

thyseus,

<?php
function allStatuses($one)
{
   return $one->Status;
}

...
'status'=>array(
   'type'=>'dropdownlist',
   'items'=>array_map('allStatuses', Post::model()->findAll(array('group'=>'Status', 'select'=>'Status'))),
)