[html-formfu] Processing of Repeatable

Carl Franks fireartist at gmail.com
Tue Feb 12 09:31:06 GMT 2008


On 10/02/2008, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> Hi,
>
> I've discovered that after processing a form with Repeatable block all
> the repeated elements dissapear.  It happens in the trunk svn version.
> I think it is a bug.
>
> Here is how I tested it:
>
> I've added:
>
> warn "Before process\n";
> warn $form;
> $form->process;
> warn "After process\n";
> warn $form;
>
> to t/defaults_from_model/has_many_repeatable_new.t

This is generally what I'd expect to happen.

I'm still nailing down some finer details of how process() should
work, and it certainly needs better documented, but it should only
ever be called once per-request. This is primarily because this is
where a lot of "expensive" things can happen, such as processing input
parameters, building complex elements such as tables / dates, and
making database calls, such as populating Select menus.

Trying to support multiple calls to process() also gets into a murky
area of trying to figure out what's supposed to be rebuilt, and what's
not.

I'm aware that if you're using a Catalyst attribute to put a form on
the stash, it will already have had process() called, and that might
not always be wanted - but I'm not sure how best to deal with that.
An app-wide setting wouldn't be much use.
I don't really want to introduce a plethora of new attribute names
FormConfigNoProcess, etc.
So at the moment, the only way around this is to get a basic form with
$self->form() and populate it yourself.

I'm not sure whether it's documented yet, but it's also going to be a
requirement that process() is called before render() - I want to
completely move away from doing any kind of element-setup in render()
(e.g. tables / dates).

Carl



More information about the HTML-FormFu mailing list