|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Alpha 3 Model-App $_record_colsHello,
I have been playing around with alpha 3 just a little. I created a model-based application via the script that uses Vendor_Controller_Model. The default setup worked great. Then, I wanted to tweak a couple of things on the form. For example, I wanted a textarea instead of the default input type=text for a particular field. I tried using the protected property $_record_cols and it seemed to work. $this->_record_cols = array( 'post_id', 'title', 'post'=>array('type'=>'textarea') ); //etc The form element was now a textarea. However, when saving the record, this column is removed by the record's load() method. It determines that this column is not part of the 'whitelist' because the column is now an array. As a result, that column is not saved. In the above example, post_id and title would be fine because they are not arrays. So, I am wondering, am I doing something wrong? Is there a better way to set the form elements? I figured I had to use $_record_cols because that is what gets passed to the form when created. protected function _setFormItem() { $this->form = $this->item->newForm($this->_record_cols); return $this->form; } All I can think of is to create another protected property $_form_cols and override the _setFormItem() method to use that property. Or make some sort of alteration to the Solar_Sql_Model_Record load() method that when checking $cols, also look for arrays and see if their key is in the whitelist. Suggestions? By the way, so far I really like the new Vendor_Controller_Model approach paired with the Vendor_Controller_Page. Much less duplication while still very flexible. Jon _______________________________________________ Solar-talk mailing list Solar-talk@... http://mailman-mail5.webfaction.com/listinfo/solar-talk |
|
|
Re: Alpha 3 Model-App $_record_colsOn Sep 14, 2009, at 00:36 , Jon Elofson wrote: > Hello, > I have been playing around with alpha 3 just a little. I created a > model-based application via the script that uses > Vendor_Controller_Model. The default setup worked great. Then, I > wanted to tweak a couple of things on the form. For example, I wanted > a textarea instead of the default input type=text for a particular > field. I tried using the protected property $_record_cols and it > seemed to work. > > $this->_record_cols = array( > 'post_id', > 'title', > 'post'=>array('type'=>'textarea') > ); > //etc > > The form element was now a textarea. However, when saving the record, > this column is removed by the record's load() method. It determines > that this column is not part of the 'whitelist' because the column is > now an array. As a result, that column is not saved. In the above > example, post_id and title would be fine because they are not arrays. > So, I am wondering, am I doing something wrong? Is there a better way > to set the form elements? I figured I had to use $_record_cols because > that is what gets passed to the form when created. > > protected function _setFormItem() > { > $this->form = $this->item->newForm($this->_record_cols); > return $this->form; > } > > > All I can think of is to create another protected property $_form_cols > and override the _setFormItem() method to use that property. Or make > some sort of alteration to the Solar_Sql_Model_Record load() method > that when checking $cols, also look for arrays and see if their key is > in the whitelist. > > Suggestions? The problem is that $_record_cols is intended only as a column list, not as the more complex structure for hinting newForm(). My initial suggestion is to override the particular Record::newForm() method and add some element customizations. For example: // for class Vendor_Model_Foos public function newForm($cols = null) { $form = parent::newForm($cols); $form->setType('foos[post]', 'textarea'); return $form; } This has the benefit of applying to all controllers that use the model, not just the one controller. Does that help? > By the way, so far I really like the new Vendor_Controller_Model > approach paired with the Vendor_Controller_Page. Much less duplication > while still very flexible. I'm glad it is serving a useful purpose. :-) -- Paul M. Jones http://paul-m-jones.com/ _______________________________________________ Solar-talk mailing list Solar-talk@... http://mailman-mail5.webfaction.com/listinfo/solar-talk |
|
|
Re: Alpha 3 Model-App $_record_colsThanks. I agree. The simple list of cols is better. I should have
checked for methods in Solar_Form (duh). Your suggestion looks like it will work perfectly. Jon On 9/14/09, Paul M Jones <pmjones@...> wrote: > > On Sep 14, 2009, at 00:36 , Jon Elofson wrote: > >> Hello, >> I have been playing around with alpha 3 just a little. I created a >> model-based application via the script that uses >> Vendor_Controller_Model. The default setup worked great. Then, I >> wanted to tweak a couple of things on the form. For example, I wanted >> a textarea instead of the default input type=text for a particular >> field. I tried using the protected property $_record_cols and it >> seemed to work. >> >> $this->_record_cols = array( >> 'post_id', >> 'title', >> 'post'=>array('type'=>'textarea') >> ); >> //etc >> >> The form element was now a textarea. However, when saving the record, >> this column is removed by the record's load() method. It determines >> that this column is not part of the 'whitelist' because the column is >> now an array. As a result, that column is not saved. In the above >> example, post_id and title would be fine because they are not arrays. >> So, I am wondering, am I doing something wrong? Is there a better way >> to set the form elements? I figured I had to use $_record_cols because >> that is what gets passed to the form when created. >> >> protected function _setFormItem() >> { >> $this->form = $this->item->newForm($this->_record_cols); >> return $this->form; >> } >> >> >> All I can think of is to create another protected property $_form_cols >> and override the _setFormItem() method to use that property. Or make >> some sort of alteration to the Solar_Sql_Model_Record load() method >> that when checking $cols, also look for arrays and see if their key is >> in the whitelist. >> >> Suggestions? > > The problem is that $_record_cols is intended only as a column list, > not as the more complex structure for hinting newForm(). > > My initial suggestion is to override the particular Record::newForm() > method and add some element customizations. For example: > > // for class Vendor_Model_Foos > public function newForm($cols = null) > { > $form = parent::newForm($cols); > $form->setType('foos[post]', 'textarea'); > return $form; > } > > This has the benefit of applying to all controllers that use the > model, not just the one controller. > > Does that help? > > >> By the way, so far I really like the new Vendor_Controller_Model >> approach paired with the Vendor_Controller_Page. Much less duplication >> while still very flexible. > > I'm glad it is serving a useful purpose. :-) > > > > > -- > > Paul M. Jones > http://paul-m-jones.com/ > > > > > _______________________________________________ > Solar-talk mailing list > Solar-talk@... > http://mailman-mail5.webfaction.com/listinfo/solar-talk > Solar-talk mailing list Solar-talk@... http://mailman-mail5.webfaction.com/listinfo/solar-talk |
| Free embeddable forum powered by Nabble | Forum Help |