here’s the list of supported (and not yet supported) form elements (types) and the Tb-widgets they are rendered with; e.g. for a textFieldRow just use ‘type’=>‘text’.
As far as I understood by looking at the source, it maps the CForm compatible types to Booster field generators, which makes perfect sense for compatibility between TbForm and CForm. But whether its set to text or TextFieldRow, both fail. Here is the relevant part of the trace:
<p>CActiveForm and its behaviors do not have a method or closure named "textFieldRow". (/Users/devuser/dev/yii/framework/base/CComponent.php:266)</p><pre>#0 /Users/devuser/dev/yii/app/protected/extensions/bootstrap/widgets/TbFormInputElement.php(117): CComponent->__call('textFieldRow', Array)
#1 /Users/devuser/dev/yii/app/protected/extensions/bootstrap/widgets/TbFormInputElement.php(117): CActiveForm->textFieldRow(Object(Aechannel), 'email', Array, Array)
#2 /Users/devuser/dev/yii/app/protected/extensions/bootstrap/widgets/TbForm.php(161): TbFormInputElement->render()
#3 /Users/devuser/dev/yii/framework/web/form/CForm.php(477): TbForm->renderElement(Object(TbFormInputElement))
#4 /Users/devuser/dev/yii/framework/web/form/CForm.php(461): CForm->renderElements()
I can force many errors on my side but not this one. When you say "changing CForm to TbForm produces an error" where are you changing it. Please post your action and view code.
Maybe my error in thinking is trying to use TbForm exactly as CForm?
Action:
public function actionGetChannel(){
$model = new Aechannel();
$form = new CForm('aesettings.views.forms.email', $model);
if($form->submitted()){
$this->redirect(array('dashboard'));
} else{
$this->renderPartial('aesettings.views.default.setting', array('form'=>$form),false);
}
}
In case you wondering about the renderPartial part, its because I’m loading it inside a modal using ajax.
If one doesn’t define ‘maxFileSize’ and ‘acceptFileTypes’ when calling the widget; shouldn’t the widget automatically check if these values are defined as validation rules in the model class?
This way, one would only have to define the rules once.
That is a good idea, you mean to include the checking of the validation rules and apply those to the model if the were on the JS widget setup or viceversa?
PS: I would like to personally thank you for your support and help ‘Don Felipe’
Yes. Just in case someone does not add these options but they have already been defined in the model’s attribute and validation rules. Then, an easy check via getValidators(attributeName) will do the trick. If someone adds these options to the widget setup it would make sense to set the validation rule for this scenario.
I will replace the old jQuery file upload with the TbFileUpload widget on my side soon. Let me know if you want me to do this and send another pull request… if you can wait until Wed perhaps? I owe you one for the extended filter.
As far as I know, CJuiDatepicker (or other "widgets") cannot be placed with a proper label in front of them (unless I missed something. Highly probable).
I recently proposed a wrapper that fitted my requirement (rendering a CJuiDatePicker as a regular field) but was rejected, so I’m looking for a way to do that without the hassle of extending TbActiveForm, TbInput and the like.
Question is: How to I render a CJuiDatePicker (or whatever widget for that case) like I render other fields (Example: echo $form->fileFieldRow($model, ‘fileName’)
Why it cannot be used as we regularly do? We have the Bootstrap jquery css to display those widgets. Isn’t it good enough?
I have something discussed with kazuo that is to create a TbHtml Helper component that will extend from CHtml and will take care of the most common input tags + HTML5 type. Maybe that could be a good place for it?
Two of the upcoming widgets are already done on 1.0.6-wip branch… I just wanted to give you an advance
There will be more to come…
PS: After I include the last ones I believe are useful for YiiBooster. Will spend some time to develop the API docs… this is going far too much and we require some proper docs.