[html-formfu] nested_name in a Radiogroup element

[Jonas Alves]

On Nov 21, 2007 3:33 PM, Carl Franks <fireartist at gmail.com> wrote:
> On 20/11/2007, Jonas Alves <jonas.alves at gmail.com> wrote:
> > On Nov 20, 2007 4:22 PM, Carl Franks <fireartist at gmail.com> wrote:
> > > The reason for this is that FormFu-Model-DBIC will require you to
> > > follow conventions matching field names to column names, and block's
> > > nested_name to relationship names.
> > > This provides the ability to fill a forms' default values from a
> > > single row, following any depth of relationships, with a single method
> > > call.
> > > Likewise, you can update a dbic row, and any depth of relationships
> > > from a submitted form, using only one method call.
> >
> > Yes, that's what I'm already doing.
>
> Once it's ready, are you going to think about a solution that takes
> advantage of the functionality in HTML-FormFu-Model-DBIC ?

Yes, I think so. :)

> I can see several problems with passing the data to DBIC's create / update.
>
> Checkboxes aren't handled correctly - if a checkbox is unchecked, it's
> parameter name is not sent by the browser at all, meaning that simply
> passing params() to DBIC won't set the column to NULL.

You are right, we need some logic in the way.

> Passing deep data structures to $row->update() for has_many
> relationships can only create new related rows, it can't update
> existing rows.

I think that this kind of stuff should be handled at DBIC side. Pedro
Melo already has a solution for it, but i don't know when will it be
released. Some examples from his tests:

$c_spec = dclone($spec = {
  users => [
    { id => $user1->id, _delete => 1 },
    { id => $user2->id, _delete => 0 },
  ],
});
$item->merge($spec);
is_deeply($spec, $c_spec, 'data was preserved intact after delete');
is($project->items->count, 1, 'we have the correct number of items');

my $project3 = $schema->resultset('Projects')->merge({
  name => 'big one',
  items => [
    { type => 'task',        name => 'finish this stuff', attachments => [
        { filename => 'file1' },
        { filename => 'file2' },
        { filename => 'file3' },
    ] },
    { type => 'defect',      name => 'cleanup that one' },
    { type => 'enhancement', name => 'make it pretty', attachments => [
        { filename => 'file1' },
    ] },
  ],
});
ok(blessed($project3));
is($project3->items->count, 3, 'super merge did ok');

He has a new merge method in the Result and ResultSet classes that
handles many-to-many rels, deletes, etc. It's very cool.


> Add to this the fact that you're having to battle to get the data into
> the right form for DBIC, I'm still having trouble seeing the merit in
> this approach.
>
> HTML-FormFu-Model-DBIC already handles these scenarios, as well as
> others such as:
> Use a Repeatable block to edit all columns, from all related rows, for
> a has_many relationship
>   - configure it to support having a Checkbox on each row, that if
> checked, deletes that related row.
>   - configure it to add an extra repeat of the block, to allow adding
> a new row, at the same time as editing existing rows.
>
> Use a Select or Checkboxgroup element to add/delete many_to_many relationships.

It seems powerful I would like to look at it. :)
Maybe for many_to_many relationships a double select widget would be
better than a simple select with the multi attribute.

>
> > > I expect this functionality to be later extended to allow configuring,
> > > so that you don't have to follow these conventions,
> >
> > What kind of configuration are you planing here?
>
> Elements now have a db() hashref that the new model uses for some
> config settings.
>
> I can imagine maybe something like:
>
>     name: foo
>     db: { column: bar }
>
> or
>
>     type: Select
>     name: foo
>     db: { relationship: bar }
>
> ...so that your field names don't have to match the database.
> However, as I said, I'm not interested in coding this, as I'll just
> make my form names match my database.
>

Yes, me too. :)

Cheers,
-- 
Jonas