[html-formfu] Re: DBIC::Validation::FormFu RFC & Element::Date patch

[Jonas Alves]

Hi Carl,

On 22/10/2007, Carl Franks <fireartist at gmail.com> wrote:
>
> Jonas,
>
> On 20/10/2007, Jonas Alves <jonas.alves at gmail.com> wrote:
> >
> > Hi Carl,
> > The 'date' parameter is created only if 'date.*' parameters are passed
> to
> > process. But dbic deletes them, so FormFu never gets anything about the
> date
> > field.
>
> Okay, I understand; because you're passing $c->req->params to
> create(), by the time your DBIC::Validation::FormFu gets the params,
> they've already been censored (?) by DBIC, so there's nothing for
> FormFu to expand.


Exactly. :)

> How is the work on nested-params going? How would it work? Some months ago
> I
> > wrote something about nested-params to the HTML::Widget list but never
> got a
> > response. See
> > http://lists.scsys.co.uk/pipermail/html-widget/2007-April/000602.html.
> > Will it work something like that?
>
> I'll have a go at adding the nested-params support over the next day or
> so.


Cool. :D

If I don't get it done, then I'll push out another cpan release, and
> then apply your patch. (I'm not wanting the patch in a cpan release,
> because I don't know want to break anything if it ends up not working
> quite like that.)


I don't think it will break anything, but I agree with you that the patch
should be applied after the next cpan release.


You'll probably have to explicitly set either
>    $form->nested(1)
> or
>     $fieldset->nested(1)
> to get the behaviour, so that people can't completely break your
> application just by changing param names and feeding hashes into code
> that isn't expecting them.


Seams reasonable. :)

While I like the idea of getting repetitive code out of the
> controller, there are several aspects to the proposal I don't like.
>
> I'd rather let Catalyst::Controller::HTML::FormFu handle creating the
> forms, at least then you can set global config in the applications
> myapp.yml file, such as:
>     'Controller::HTML::FormFu':
>       constructor:
>         render_class_args:
>           ENCODING: UTF-8
> Whereas, it looks like that'll all have to be repeated for
> DBIx::Class::Validation


Nope, I pretend to create a DBIC::Schema::Valitadion class and a subclass of
Catalyst::Model::DBIC::Schema (like Catalyst::Model::DBIC::Schema::QueryLog)
to handle that.

The problem you've had is because you're having to pass
> $c->req->params to create(), rather than $form->params.
> I'd much prefer something like:
>
>   $schema->create( $c->stash->{form}->params )
>         if $c->stash->{form}->submitted_and_valid;



Yep, that's the way I used before. But now I like to say just
$schema->create( $params ) and that's it.

It's not clear whether you use different actions for displaying the
> form and then handling the form.


It's the same uri for the browser. But in MyApp I use the REST Controller.
It's something like this:

__PACKAGE__->mk_accessors(qw/model_name create_uri/);

sub root : Chained('base') PathPart('') Args(0) REST {}

# Show the Form to create a new entry
sub root_GET {
    my ( $self, $c ) =3D @_;
    $c->stash(form =3D> $self->model->form);
}

# Get the data from the form and redisplay with errors if invalid
# or redirect to a success page if valid
sub root_POST : MyAction('CheckError') {
    my ( $self, $c ) =3D @_;
    my $new =3D $self->model->create($c->req->params);
    $c->redirect($self->create_uri);
}

sub model {
    my $self =3D shift;
    my $c =3D Catalyst::Controller::BindLex::_get_c_obj(1);
    return $c->model($self->model_name);
}


I like to use the same action for both, partly so that I can let
> Catalyst::Controller::HTML::FormFu automatically fill in the form's
> action url.
> I'm also not too keen on seeing the form object being thrown as an
> exception.
> I'd expect a new exception class to be created for that.


Yes, I agree with that. throwing the form was just a way to test the
behavior. The form should be an attribute of the exception.

I'm attempting to make time now to look at DBIC integration as a
> whole, as I feel there's lots of parts that scratch individual itches,
> but there's not a good generic solution yet.


That's what I'm trying to achieve too. :) I've some of ideas and prototypes
that I pretend to send to the list.

-- =

Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/html-formfu/attachments/20071022/2e=
b26c20/attachment.htm