Alpha 3 Model-App $_record_cols

View: New views
3 Messages — Rating Filter:   Alert me  

Alpha 3 Model-App $_record_cols

by Jon Elofson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

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_cols

by Paul M Jones-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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

Re: Alpha 3 Model-App $_record_cols

by Jon Elofson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thanks. 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