[Html-widget] latest formfu developments - Controller and Constraints

[Carl Franks]

On 27/02/07, Mario Minati <mario at minati.de> wrote:
> Carl Franks schrieb:
> Is it possible that the CallbackOnce constraint works different then
> that one from HTML::Widget?
> I used it like this:
> #    $form->constraint(CallbackOnce => qw/name pre/)->callback(sub {
> #    my ($name, $pre) = @_;
> So I got the values of that fields.
> As I understand your code I only get the value of the field which the
> constraint belongs to. Correct?

Yes, previously the callback got a list of values as its arguments - 1
for each of it's named fields.
    constraint( CallBackOnce => 'foo', 'bar' )
        ->callback( sub { my ( $foo, $bar ) = @_; } );

Now, there's 2 differences.
First, a constraint can only have 1 named field.
For example, the above constraint would actually create 2 new
constraints - so it's the same as doing...
    constraint( CallbackOnce => 'foo' )->callback( \&xxx );
    constraint( CallbackOnce => 'bar' )->callback( \&xxx );
To make up for this, the callback now receives 2 arguments: the value
for the named field, and a copy of the entire input param hashref.
    ->callback( sub { my ( $value, $params ) = @_; } );

> > You could use the FormMethod action, which could even load the bulk of
> > the form from a config file, and then just add the things which need
> > to be done programatically.
> >
> > Because load_config_file() uses Config::Any - which supports loading
> > perl files - you could still define your programatic constraints in a
> > config file (as long as it doesn't require access to runtime data)
> >
> > As far as getting db data into select fields is concerned, there's not
> > really any way around doing that somewhere in your code.
> > If you're using DBIx::Class, you could create a db-specific formfu
> > element which gets the data itself, by accessing the dbic classes
> > directly.
>
> At the moment I am experimenting with the FormMethod Action Class.
>
> For me it would be very usefull if the form creating functon could be
> called with $c as parameter.
> I hanged that in my local code like that:
>     for ( @{ $self->{_attr_params} } ) {
>         for my $method ( split ) {
>             $c->log->debug($method);
>             my $args = $controller->$method($c) || {};
>
>             $form->populate( $args );
>         }
>     }

Good idea.
I've updated the Cat controller so the method gets the $c.

> This way I can autodetect a few elements for the form like this:
> sub company_form {
>     my ($self, $c) = @_;
>
> my $sub = (caller(0))[3];
> $sub =~ s/^([^\:]+\:\:)*//;
> $c->log->debug("Setting default form id to: ".$sub);
> $c->log->debug("Setting default form action to:
> ".$c->uri_for($c->{action}->name));
> return {
>     action    => $c->uri_for($c->{action}->name),
>     id        => $sub,
>     elements  => [ [
> ...
>
> I will put this in a seperate function that provides some common form
> code, or do you want to put it in formMethod to provide some defaults
> that the user could override.

Maybe add a config option, to make all forms automatically get the
action property set to the current url.

> After bringing that to work (yesterday) I decided (today) to switch to
> FormConfig with yml-files, as I can get rid of the formcode in my
> controller. After understanding YAML it works quite well.
> Now I am as  fascinated as you are. ;-)

Cool :)

> There is only one constraint than I cannot create at the moment:
> Some db tables in my model have unique constraints, so I do a search
> with the new data before accepting it.
> I am imaging a hidden field that contains the id of the data set (for
> edit) or an empty string (for create) and constraint on that with the
> model name and the parameters names that have to be included (could be
> autodetected from the required fields).
> But the one thing that is missing to acomplish this is $c from catalyst.
> Do you see a chance to pass it through / hold it in formfu?

Does FormMethod() getting $c now solve this?

> By the way I made a TrimEdges Filter.You can put it in the svn if you want.

I've added it.
The only change I made was changing
    $value =~ s/\s+$//;
to
    $value =~ s/\s+\z//;
because $ allows a linebreak after it, which isn't likely what's
wanted. \z is more explicit.
I think I've changed all the formfu constraints/filters to use that,
but if you come across any that still use $ feel free to fix them!

If you have a google account, I'll give you svn commit access. - But
do please include tests with any changes.
(you don't need to sign up for gmail to get an account, you can sign
up with any email address).

Cheers,
Carl