Carl Franks schrieb:
On 27/02/07, Mario Minati <[EMAIL PROTECTED]> 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

_______________________________________________
Html-widget mailing list
Html-widget@lists.rawmode.org
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget

Reply via email to