[html-formfu] nested_name in a Radiogroup element

[Carl Franks]

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 ?

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.

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

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.

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

Carl