respond_with_model_values is unnecessary because the -
validation_response method returns the form data in the "data" key.
Do you have any other reasons why we need this?
The difference between calling the validation_response or form_data
method is
in the call to '$self->model->default_values($data);'. By forcing a
reread of
values from model I get the values that are set by automatic
processing in
DBIC classes, like IDs and UUIDs.
OK I see. I think we can make this the default behaviour. This will
cause a
database roundtrip but I think it's the best way to make sure that the
data
we give back is the same as the data the user will get when he requests
that item.
What is the point of find_method? I think it is a good idea to make
it
configurable, but I can only think of "first" as a custom find
method.
I have a custom ResultSet class 'DefaultValuesResultset' which
provides
a 'find_or_default' function, that returns the object or creates a
new one,
based on the defaults defined in the db table model classes.
Maybe you could add your motivation to the docs.
Done.
Great! thanks!
I changed the behaviour of 'default_rs_method' to call a default rs
method if present. It's name is derived from the class name.
If 'if($object->can($rs)) {' (122) fails we should warn instead of
debug.
But the intention was that default_rs_method is optional. In many cases
the user will not have such a result set method implemented. A warn will
also be displayed in non debug mode. That could become anoying :-)
REST uses
Moose now and requires Catalyst::Runtime 5.8.
I upgraded accordingly.
And it would be great if you could add tests for all the features you
add :-)
I'm working on that.
Thanks for your thoughts on this project!
moritz
_______________________________________________
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
