[html-formfu] Composed Date

[Carl Franks]

2008/4/11 Zbigniew Lukasiak <zzbbyy at gmail.com>:
> Last week I've spent trying to make easy composable elements.  So that
>  you could build an element out of many others - and then just add an
>  inflator to compose all the individual field values to the value of
>  the whole.  First of all I wanted a flexible DateTime element.

...

>  As you can see you can build the Date element out of individual
>  Selects arranged into Blocks etc - so this works - but the
>  stringification is still a hack.

I like the idea, but it does need generalizing a bit.
I've taken the idea of your inflator and committed a new
Inflator::CompoundDateTime and Deflator::CompoundDateTime (r1004).
There's docs and tests, but the general idea is that they get added to
a Multi field which should contain appropriate Text or Select fields
representing any of year / month / day / hour / minute / second /
nanosecond / time_zone.

    ---
    element:
      - type: Multi
        name: date

        elements:
          - name: day
          - name: month
          - name: year

        inflator:
          - type: CompoundDateTime

        deflator:
          - type: CompoundDateTime

Given the following input:
    {
        'date.day' => 31,
        'date.month' => 12,
        'date.year => 1999,
    }
This will be inflated to a DateTime object on the 'date' Multi field:
    my $dt = $form->param_value('date');

Given a DateTime object as a default:
    $form->default_values({ date => $datetime });
The deflator will set the appropriate default values on the individual
child-fields.

I think we could probably make these also support your am/pm selector idea.

As a Multi is a field as well as a block, this should work ok with
Model::DBIC - though I've not tested that yet.
I also propose that more general Compound* inflators and deflators are
also written, to support such things as Moritz's recent field-joining
request.

Back to your Composed.pm element - there's a couple of main problems with it.
First, it's probably confusing that it allows you to add Block
elements to it, and not just Field elements - as it inherits from
Multi - which is restricted to only allowing Field child-elements.
There seem to be too much special-case logic within the string() sub -
specifically, you should only use the contents of the $render data
structure, and not call methods on $self.
Everything within string() will need to be duplicated within the TT
templates, which only have access to the $render data.

Unfortunately, it looks like you started work in this before I made
some changes to the Date element a few weeks ago - as Composed.pm can
now be made a lot simpler.
Specifically, it only needs to inherit from Multi - not both _Field and Multi.
You can also delete your overridden methods: (get_elements,
nested_name, nested_names, new, get_fields) as they all do the right
thing now that it only inherits from Multi.

I think, though, for non-date compound fields (combining several
fields into 1 value) - analogous to Rose::HTML::Form::Field::Compound
- we probably just need a Multi element with appropriate Deflator and
Inflators.

I don't really know where this is going... but I better send it now
before it gets stuck in my 'Drafts' folder ( or as I typically think
of it: '/dev/null' )

Carl