[html-formfu] refactoring defaults_from_model (DBIC)

On Jan 12, 2008 4:54 PM, Zbigniew Lukasiak wrote:
Hi all,

I've changed defaults_from_model. Instead of scanning the db fields of
the given row and then matching them against form fields - I made it
walk through the form fields and match them against the db fields.
That let me reduce the code twice ( in line numbers and number of
subroutines), and also the coupling between the routines (by reducing
the number of parameters they take). I believe the resulting code is
much simpler - and it is also more general (works for has_many
relations with Select boxes and probably makes less assumptions about
the structure of the form). All tests passed.

The resulting HTML::FormFu::Model::DBIC is attached - please comment.

If no one is against it I'll commit it to the svn soon.

I am planning to add updating relationships to the DBIx::Class update
method - and then base save_to_model on that. This should be another
big code reduction.

--
Zbigniew Lukasiak
http://perlalchemy.blogspot.com/

On 13/01/2008, Zbigniew Lukasiak wrote:
I've simplified it even further - by getting rid of the $attrs
parameter for the internal functions. The new file is attached.

On Jan 15, 2008 5:13 PM, Carl Franks wrote:
Committed!

On 15/01/2008, Zbigniew Lukasiak wrote:
Great!

I've got also a few tests - I'll try them out and if they are still
passing I'll commit them as well.

On Jan 18, 2008 5:03 PM, Carl Franks wrote:

I noticed that the refactor had reverted back to the old behaviour of
always using get_column() - I've fixed that so that it uses
$row->$name() accessors (when it doesn't clash with a rel name), and
added tests to ensure that DBIC column inflators are being run.

2008/1/18, Zbigniew Lukasiak <zzbbyy@gmail.com>:
Ah - I was actually thinking about that - but I forgot about the
inflators - sorry.

By the way in my code I've started to make sure that rels have
different names than columns - this way I can alway call
$row->$name().

Cheers,
Zbyszek
http://perlalchemy.blogspot.com/
From svn (r787) my code breaks like this:

On Jan 19, 2008 3:03 AM, ???????? ??????????? wrote:
2008/1/18, Zbigniew Lukasiak <zzbbyy@gmail.com>:
Can't call method "result_source" without a package or object
reference at /home/...perl5/site_perl/5.8.8/HTML/FormFu/Model/DBIC.pm
line 71.

After i rolled back to r776 everything worked fine as expected.

2008/1/19, Zbigniew Lukasiak <zzbbyy@gmail.com>:
Check out the new version. I think I've fixed that bug. Yesterday I
discovered that the new version would recurse in defaults_from_model
for nested blocks that are not relations (like Date) - the result is
the error you received.

I've also added some tests in that commit - I hope I did not forget
about something.

Cheers,
Zbigniew
http://perlalchemy.blogspot.com/

On 12/01/2008, Zbigniew Lukasiak wrote:
Hi all,

I've changed defaults_from_model. Instead of scanning the db fields of
the given row and then matching them against form fields - I made it
walk through the form fields and match them against the db fields.
That let me reduce the code twice ( in line numbers and number of
subroutines), and also the coupling between the routines (by reducing
the number of parameters they take). I believe the resulting code is
much simpler - and it is also more general (works for has_many
relations with Select boxes and probably makes less assumptions about
the structure of the form). All tests passed.

The resulting HTML::FormFu::Model::DBIC is attached - please comment.

If no one is against it I'll commit it to the svn soon.

I am planning to add updating relationships to the DBIx::Class update
method - and then base save_to_model on that. This should be another
big code reduction.

Carl Franks wrote:

On 14/01/2008, Brian Cassidy wrote:
Carl Franks wrote:
(Note, I haven't looked at your code yet)

Depending on how you do this it could bring back the "delete" bug,
where-in a form element named "delete" would actually execute the
"delete" method on the dbic object, thereby removing the row from the
database.

You're probably well-aware of the issue, but I just want to state it to
the list to be safe. :)

Carl Franks wrote:
That bug is already back - intentionally :)
Using get/set_column() was no use, because dbic inflators / deflators
weren't being called.
I'm pretty sure our docs just mention to not use columns with dbic
built-in names.