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

[Mario Minati]

Carl Franks schrieb:
> 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 );
That I new.
> 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 ) = @_; } );
Ok, I guessed that, but I was not sure as I had problems to backtrack 
the params hash.
That's ok for me.
>
>> > 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.
I saw it in the svn this morning. Thank you.
>
>> 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.
Changes in Catalyst::Controller::HTML::FormFu:

    my %defaults = (
        form_method   => 'form',
        form_stash    => 'form',
        result_stash  => 'result',
        form_attr     => 'Form',
        config_attr   => 'FormConfig',
        method_attr   => 'FormMethod',
        form_action   => "Catalyst::Controller::HTML::FormFu::Action::Form",
        config_action => 
"Catalyst::Controller::HTML::FormFu::Action::Config",
        method_action => 
"Catalyst::Controller::HTML::FormFu::Action::Method",
        constructor   => {},
        config_file_ext => '.yml',
        set_default_action => 0,
    );

and in _form add:
    if ( $config->{set_default_action} ) {
        $form->action( $self->{c}->uri_for( $self->{c}->{action}->name ) );
    }

>> 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?
No, as I'am no creating my form with FormConfig I would like to do with 
a plain Constraint.
The thing is I would need access to $c in the functions of the 
Constraint to gain access to the model. This is not possible at the 
moment. But might be possible via the $element->{stash}.
To my point of view the problem is that the modul should be generally 
useable and this is just a catalyst centric problem. So we should be 
able to solve this only with the FormFu-Controller.
If we want to do so, we need a function that makes it possible that on 
attribute ($c in this case) is coppied in every elements stash. This way 
we can setup this specialy Catalyst - DBIx::Class - Model - Unique 
constraint the same way we setup other constraints.
>
>> 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!
Thanks. \z is indeed better.

Greets,
Mario