Am 18.08.2009 um 11:46 schrieb Carl Franks:
2009/8/17 Nick Spacek <nick.spa...@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
_______________________________________________
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
