[html-formfu] FormFu::Model subclassing

Moritz Onken onken at houseofdesign.de
Tue Aug 18 21:13:22 GMT 2009


Am 18.08.2009 um 11:46 schrieb Carl Franks:

> 2009/8/17 Nick Spacek <nick.spacek at gmail.com>:
>> I tried this as well, and Dumper-ed the result of the update. It  
>> comes back
>> with an empty title field! :)
>
> I can confirm this - the HashRef model doesn't work as I would  
> expect it to.
>
> In both the DBIC and LDAP models, default_values() retrieves values
> from an external source, and sets the fields' default() with them.
>
> update() / create() take the user-submitted values, and updates the
> external source with them.
>
> In Model::HashRef, default_values() seems to do what I would expect -
> it sets the fields' default() with the values supplied as an argument
> to $form->model->default_values().
>
> However, create() seems to just create its hash-ref with the value
> from each field's default_values() method.
> This value never comes from user-submitted data.
> The create() tests should be checking that it returns a data structure
> based on what's fed to $form->process( { } ).
> It should be getting the values from $form->param_value() /
> param_list() / param_array().
>
> Also, I notice that in t/model/hashref_create.t it builds a { value =>
> x, label => y } hash-ref for a Select field - I don't think it should
> be doing that - it should just be using the scalar value that was
> committed.
>
> And lastly ;) create() is calling $form->render() - this shouldn't be
> necessary  - and really shouldn't be happening in a method that should
> just be processing user-submitted data.

I'll look into that.

The behaviour for select fields can be disabled if you set
$model->options(0). This will create the hash as you would expect it.

cheers,

moritz



More information about the HTML-FormFu mailing list