[html-formfu] Nested forms using has_many relationships from DBIC

[Carl Franks]

On 13/12/2007, Henning Kulander <hennikul at linpro.no> wrote:
> - type: Repeatable
> nested_name: accessipranges
> name: ipranges

btw, you shouldn't need to set 'name' on any block

> The accessipranges is a has_many relationship to a table called
> Accessipranges, and calling that as a method in Perl, DBIC starts the
> correct SELECT and retrieves the values. But in HTML::FormFu it does
> not. I traced this problem and made this patch to DBIC.pm:

Thanks, I've committed the patch (though I think the diff was backwards)
What would be best in future, is if you could checkout the code with
svn, then when you've made changes, you just need to do:
    svn diff > changes.patch
and send the patch file.

> Now I get a form with all related Accesipranges objects. But when I save
> the form, only the first one is processed. That is, if I update the
> second object, validators and condition checks are not run on that
> object, it is not saved either. If I update the first object, it is
> validated and saved to the database using an UPDATE. Creating new
> objects works aswell, but only if the empty object is first.. :)

I've just realised it's not documented yet, but has_many and
many_to_many rels require an extra hidden field, which keeps count of
the number of related rows.
You don't need to set this field's value, that's taken care of automatically.
This is also used to call $repeatable->repeat($count) during
$form->process(), which ensures the constraints, etc. are run
correctly.

This hidden field needs to be outside the Repeatable block, attached
to the same parent as the block.

    ---
    elements:
      - type: Hidden
        name: count
      - type: Repeatable
        increment_field_names: 1
        counter_name: count
          - elements
            ...

Check the tests in t/defaults_from_model and t/save_to_model if
there's anything I've missed.

> 2. Related objects with combined primary key (key using more that one
> column for uniqueness) does not seem to work. Should it? It would be
> usefull when working with legacy database schemas.

There's no support yet for multi-column PK's, as it's not something I use often.
patches + tests welcome!

Cheers,
Carl