FAQ
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DBIC.pm
Type: application/x-perl
Size: 25830 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/html-formfu/attachments/20080112/57074cca/DBIC-0001.bin

Search Discussions

  • Zbigniew Lukasiak at Jan 13, 2008 at 3:42 pm
    I've simplified it even further - by getting rid of the $attrs
    parameter for the internal functions. The new file is attached.

    Zbigniew
    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/


    --
    Zbigniew Lukasiak
    http://brudnopis.blogspot.com/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: DBIC.pm
    Type: application/x-perl
    Size: 25654 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/html-formfu/attachments/20080113/d6320acb/DBIC-0001.bin
  • Carl Franks at Jan 15, 2008 at 4:13 pm

    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.
    Committed!

    I've also added lots of tests for relationships under nested_name.
    The original code had a bug that failed some tests, but this refactor
    passed all tests fine!

    Thanks,
    Carl
  • Zbigniew Lukasiak at Jan 15, 2008 at 4:21 pm

    On Jan 15, 2008 5:13 PM, Carl Franks wrote:
    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.
    Committed!
    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.

    Cheers,
    Zbigniew
  • Carl Franks at Jan 18, 2008 at 4:03 pm

    On 15/01/2008, Zbigniew Lukasiak wrote:
    On Jan 15, 2008 5:13 PM, Carl Franks wrote:
    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.
    Committed!
    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.
    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.

    Carl
  • Zbigniew Lukasiak at Jan 18, 2008 at 4:37 pm

    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.
    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/
  • Viacheslav Tikhanovskii at Jan 19, 2008 at 2:03 am

    2008/1/18, Zbigniew Lukasiak <zzbbyy@gmail.com>:
    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.
    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:
    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.
  • Zbigniew Lukasiak at Jan 19, 2008 at 7:25 am

    On Jan 19, 2008 3:03 AM, ???????? ??????????? wrote:
    2008/1/18, Zbigniew Lukasiak <zzbbyy@gmail.com>:
    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.
    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:
    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.
    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/
  • Viacheslav Tikhanovskii at Jan 19, 2008 at 12:14 pm

    2008/1/19, Zbigniew Lukasiak <zzbbyy@gmail.com>:
    On Jan 19, 2008 3:03 AM, ???????? ??????????? wrote:
    2008/1/18, Zbigniew Lukasiak <zzbbyy@gmail.com>:
    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.
    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:
    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.
    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/
    Thanx for the reply. I thought nobody sees my mail =/ I'll test a
    little bit later on that issue.
  • Carl Franks at Jan 14, 2008 at 10:13 am

    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.
    It looks good.
    I'm currently working on some more test files - to make absolutely
    sure everything's covered - so hopefully it can be committed very
    soon.

    Thanks,
    Carl
  • Brian Cassidy at Jan 14, 2008 at 12:33 pm

    Carl Franks wrote:
    On 12/01/2008, Zbigniew Lukasiak wrote:

    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.
    (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. :)
    It looks good.
    I'm currently working on some more test files - to make absolutely
    sure everything's covered - so hopefully it can be committed very
    soon.
    Hopefully there's a test for the above issue.

    -Brian
  • Carl Franks at Jan 14, 2008 at 1:04 pm

    On 14/01/2008, Brian Cassidy wrote:
    Carl Franks wrote:
    On 12/01/2008, Zbigniew Lukasiak wrote:

    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.
    (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. :)
    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.

    Carl
  • Brian Cassidy at Jan 14, 2008 at 1:13 pm

    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.
    Fair enough. I see that note now [1].

    -Brian

    [1]
    http://search.cpan.org/dist/HTML-FormFu/lib/HTML/FormFu/Model/DBIC.pm#CAVEATS

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouphtml-formfu @
categoriesperl, catalyst
postedJan 12, '08 at 3:54p
activeJan 19, '08 at 12:14p
posts13
users4
websitemetacpan.org...

People

Translate

site design / logo © 2022 Grokbase