FAQ
I'm experimenting with how best to use the FormValidator plug-in.
I think it's far too complicated, particularly on pages where it's not
appropriate to use it in conjunction with FillInForm and you actually
have to use the API !

What I've done at the moment is create a plug-in which subclasses
Catalyst::Plugin::FormValidator and looks like this:

package Catalyst::Plugin::FormValidator::MergeRequest;
use strict;
use NEXT;
use base 'Catalyst::Plugin::FormValidator';

sub form {
my $c = shift;

if (@_) {
$c->NEXT::form( $c, @_ );

# logic here
# see below for discussion
}

return $c->{form};
}

1;

What I want the 'login' part to do is:
For 'invalid' input, delete it from the request parameters.
For 'valid' input, put it into the request parameters (because it may
have been changed by FormValidator filters).

To do this, is it "acceptable" to change values and delete keys from
the hash-ref returned by $c->req->parameters() ? Will this break
anything?

I'm also unsure about 'unknown' input. As the Data::FormValidator docs
say, "Whether or not this indicates an error in the user input is
application dependant".
Maybe add another method to optionally strip unknowns from the request
parameters?
$c->delete_unknown_params

The purpose of this, is so only the 'auto' routine needs to deal with
$c->form stuff such as invalid and valid
The action routine can simply use $c->req->params as normal, assuming
that all is well.

Thoughts? Ideas?

Carl

Search Discussions

  • Will Hawes at Dec 7, 2005 at 11:11 am

    Carl Franks wrote:
    I'm experimenting with how best to use the FormValidator plug-in.
    I think it's far too complicated, particularly on pages where it's not
    appropriate to use it in conjunction with FillInForm and you actually
    have to use the API !

    What I've done at the moment is create a plug-in which subclasses
    Catalyst::Plugin::FormValidator and looks like this:

    package Catalyst::Plugin::FormValidator::MergeRequest;
    use strict;
    use NEXT;
    use base 'Catalyst::Plugin::FormValidator';

    sub form {
    my $c = shift;

    if (@_) {
    $c->NEXT::form( $c, @_ );

    # logic here
    # see below for discussion
    }

    return $c->{form};
    }

    1;

    What I want the 'login' part to do is:
    For 'invalid' input, delete it from the request parameters.
    For 'valid' input, put it into the request parameters (because it may
    have been changed by FormValidator filters).

    To do this, is it "acceptable" to change values and delete keys from
    the hash-ref returned by $c->req->parameters() ? Will this break
    anything?

    I'm also unsure about 'unknown' input. As the Data::FormValidator docs
    say, "Whether or not this indicates an error in the user input is
    application dependant".
    Maybe add another method to optionally strip unknowns from the request
    parameters?
    $c->delete_unknown_params

    The purpose of this, is so only the 'auto' routine needs to deal with
    $c->form stuff such as invalid and valid
    The action routine can simply use $c->req->params as normal, assuming
    that all is well.

    Thoughts? Ideas?

    Carl

    _______________________________________________
    Catalyst mailing list
    Catalyst@lists.rawmode.org
    http://lists.rawmode.org/mailman/listinfo/catalyst
    I'm not sure I understand what you're trying to do, but you should
    probably consider making a copy of $c->req->params locally if you want
    to modify it.

    Modifying c->req->params sounds like a recipe for disaster. If and when
    it causes anything to break it will make debugging much harder.
  • Carl Franks at Dec 7, 2005 at 12:25 pm

    On 07/12/05, Will Hawes wrote:
    I'm not sure I understand what you're trying to do, but you should
    probably consider making a copy of $c->req->params locally if you want
    to modify it.
    What I'm trying to do is make FormValidator transparent; to allow my
    'action' routine and any other plugins etc, to be able to access the
    input as usual, via $req->params

    I don't want all of the 'action' routines to have to check
    $c->form->missing, $c->form-->valid, etc.
    Modifying c->req->params sounds like a recipe for disaster. If and when
    it causes anything to break it will make debugging much harder.
    I think I'm just going to have to go with my method for now, and see
    if anything breaks - that is unless I hear from someone that knows the
    Catalyst code-base and says 'dont'!

    Cheers,
    Carl
  • Sebastian Riedel at Dec 7, 2005 at 12:48 pm

    Am 07.12.2005 um 12:31 schrieb Carl Franks:
    What I'm trying to do is make FormValidator transparent; to allow my
    'action' routine and any other plugins etc, to be able to access the
    input as usual, via $req->params

    I don't want all of the 'action' routines to have to check
    $c->form->missing, $c->form-->valid, etc.
    Guess you'll like the upcoming HTML::Widget. :)

    http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Widget/

    --
    sebastian
  • Carl Franks at Dec 7, 2005 at 3:07 pm

    Guess you'll like the upcoming HTML::Widget. :)

    http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Widget/
    It looks interesting.

    How close is it to release / how stable is the API ?

    All tests pass on my machine (though that means nothing, not knowing
    how thorough the test suite is ;)

    Carl
  • Sebastian Riedel at Dec 7, 2005 at 3:42 pm

    Am 07.12.2005 um 15:13 schrieb Carl Franks:

    Guess you'll like the upcoming HTML::Widget. :)

    http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Widget/
    It looks interesting.

    How close is it to release / how stable is the API ?

    All tests pass on my machine (though that means nothing, not knowing
    how thorough the test suite is ;)
    Test coverage is quite good, and it's very near a release, planned
    are only bug fixes and some more constraints.


    --
    sebastian
  • Bill Moseley at Dec 7, 2005 at 1:58 pm

    On Wed, Dec 07, 2005 at 11:31:49AM +0000, Carl Franks wrote:
    On 07/12/05, Will Hawes wrote:

    I'm not sure I understand what you're trying to do, but you should
    probably consider making a copy of $c->req->params locally if you want
    to modify it.
    What I'm trying to do is make FormValidator transparent; to allow my
    'action' routine and any other plugins etc, to be able to access the
    input as usual, via $req->params

    I don't want all of the 'action' routines to have to check
    $c->form->missing, $c->form-->valid, etc.
    Do you have more than one action routine handling the same form?

    Doesn't the existence of a single invalid parameter mean the entire
    form is invalid? If so, then the entire form needs to be shown again,
    with sticky values -- including even the invalid ones? So you
    wouldn't want to delete the invalid parameters. And seems you could
    catch that in one place.

    My form handling actions look something like:

    sub edit : Local {
    my ( $self, $c, $id ) = @_;
    my $form = MyApp::Forms::User->new( $id );

    $form->update_from_params( $c )
    if $c->form_posted;
    }


    If I'm not updating the database and instead need the parameters in my
    controller (and need them as modified by the form) then its:

    sub edit : Local {
    my ( $self, $c ) = @_;
    my $form = MyApp::Forms::User->new;

    if ( $c->form_posted && $form->validated( $c ) ) {
    my $date = $form->field( 'date' )->value;
    }
    }

    So I'm not using $c->req->params in my code, but the values returned
    in the "form".

    --
    Bill Moseley
    moseley@hank.org
  • Phil Mitchell at Dec 7, 2005 at 5:33 pm

    On 12/7/05, Carl Franks wrote:
    On 07/12/05, Will Hawes wrote:

    Modifying c->req->params sounds like a recipe for disaster. If and when
    it causes anything to break it will make debugging much harder.
    I think I'm just going to have to go with my method for now, and see
    if anything breaks - that is unless I hear from someone that knows the
    Catalyst code-base and says 'dont'!
    I'd also suggest don't modify $c->req->params. Define your own
    $c->clean_params() -- I wouldn't use a plugin that messed with my raw
    data.
    >


    --
    ==========================
    2People Blog: http://2-people.blogspot.com/
    2People site: http://www.2people.org
  • Sascha Kiefer at Dec 7, 2005 at 11:17 am
    Have you looked at the FormValidator::Simple plugin yet ?

    Regards,
    --esskar
    -----Original Message-----
    From: catalyst-bounces@lists.rawmode.org
    On Behalf Of Carl Franks
    Sent: Mittwoch, 7. Dezember 2005 11:02
    To: Catalyst Mailing List
    Subject: [Catalyst] FormValidator usage / enhancements


    I'm experimenting with how best to use the FormValidator
    plug-in. I think it's far too complicated, particularly on
    pages where it's not appropriate to use it in conjunction
    with FillInForm and you actually have to use the API !

    What I've done at the moment is create a plug-in which
    subclasses Catalyst::Plugin::FormValidator and looks like this:

    package Catalyst::Plugin::FormValidator::MergeRequest;
    use strict;
    use NEXT;
    use base 'Catalyst::Plugin::FormValidator';

    sub form {
    my $c = shift;

    if (@_) {
    $c->NEXT::form( $c, @_ );

    # logic here
    # see below for discussion
    }

    return $c->{form};
    }

    1;

    What I want the 'login' part to do is:
    For 'invalid' input, delete it from the request parameters.
    For 'valid' input, put it into the request parameters
    (because it may have been changed by FormValidator filters).

    To do this, is it "acceptable" to change values and delete
    keys from the hash-ref returned by $c->req->parameters() ?
    Will this break anything?

    I'm also unsure about 'unknown' input. As the
    Data::FormValidator docs say, "Whether or not this indicates
    an error in the user input is application dependant". Maybe
    add another method to optionally strip unknowns from the
    request parameters? $c->delete_unknown_params

    The purpose of this, is so only the 'auto' routine needs to
    deal with $c->form stuff such as invalid and valid The action
    routine can simply use $c->req->params as normal, assuming
    that all is well.

    Thoughts? Ideas?

    Carl

    _______________________________________________
    Catalyst mailing list
    Catalyst@lists.rawmode.org
    http://lists.rawmode.org/mailman/listinfo/catalyst
  • Carl Franks at Dec 7, 2005 at 12:26 pm

    On 07/12/05, Kiefer, Sascha wrote:
    Have you looked at the FormValidator::Simple plugin yet ?
    From looking at the docs, it appears to be just Data::FormValidator
    with a different constraints syntax - it still doesn't provide better
    integration with catalyst.

    Cheers,
    Carl
  • Gabriel Fortuna at Dec 7, 2005 at 3:52 pm

    From: catalyst-bounces@lists.rawmode.org
    All tests pass on my machine (though that means nothing, not knowing
    how thorough the test suite is ;)
    Test coverage is quite good, and it's very near a release, planned
    are only bug fixes and some more constraints.
    It looks interesting, and certainly more grokable than DFV's cat
    plugin... However, more comprehensive documentation is imperative. I got
    a disconnect when trying to understand exactly how it slots into the
    picture... And how to have more than one widget. Might seem like a
    stupid thing, but it will definitely turn away more novice users.
    Please note: This email and its content are subject to the disclaimer as displayed at the following link http://www.is.co.za/disc.asp. Should you not have Web access, send a mail to disclaimers@is.co.za and a copy will be emailed to you.
  • Sebastian Riedel at Dec 7, 2005 at 4:07 pm

    Am 07.12.2005 um 15:57 schrieb Gabriel Fortuna:

    From: catalyst-bounces@lists.rawmode.org
    All tests pass on my machine (though that means nothing, not knowing
    how thorough the test suite is ;)
    Test coverage is quite good, and it's very near a release, planned
    are only bug fixes and some more constraints.
    It looks interesting, and certainly more grokable than DFV's cat
    plugin... However, more comprehensive documentation is imperative.
    I got
    a disconnect when trying to understand exactly how it slots into the
    picture... And how to have more than one widget. Might seem like a
    stupid thing, but it will definitely turn away more novice users.
    my $widget1 = HTML::Widget->new('widget1');
    my $widget2 = HTML::Widget->new('widget2');

    Too complicated? :)
    There is also a Cat plugin at http://dev.catalyst.perl.org/repos/
    Catalyst/trunk/Catalyst-Plugin-HTML-Widget/

    $c->widget('widget1');
    $c->widget('widget2');


    --
    sebastian
  • Hartmaier Alexander at Dec 7, 2005 at 5:00 pm
    Don't forget to add good newbie docs with examples.
    Adding a 'why it's better than DFV' section in the readme or perldoc would be
    good too.
    Looking forward to use it ;-)

    -Alex


    -----Original Message-----
    From: catalyst-bounces@lists.rawmode.org
    On Behalf Of Sebastian Riedel
    Sent: Wednesday, December 07, 2005 4:16 PM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] FormValidator usage / enhancements


    Am 07.12.2005 um 15:57 schrieb Gabriel Fortuna:
    From: catalyst-bounces@lists.rawmode.org
    All tests pass on my machine (though that means nothing, not knowing
    how thorough the test suite is ;)
    Test coverage is quite good, and it's very near a release, planned
    are only bug fixes and some more constraints.
    It looks interesting, and certainly more grokable than DFV's cat
    plugin... However, more comprehensive documentation is imperative.
    I got
    a disconnect when trying to understand exactly how it slots into the
    picture... And how to have more than one widget. Might seem like a
    stupid thing, but it will definitely turn away more novice users.
    my $widget1 = HTML::Widget->new('widget1');
    my $widget2 = HTML::Widget->new('widget2');

    Too complicated? :)
    There is also a Cat plugin at http://dev.catalyst.perl.org/repos/
    Catalyst/trunk/Catalyst-Plugin-HTML-Widget/

    $c->widget('widget1');
    $c->widget('widget2');


    --
    sebastian


    _______________________________________________
    Catalyst mailing list
    Catalyst@lists.rawmode.org
    http://lists.rawmode.org/mailman/listinfo/catalyst
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/x-pkcs7-signature
    Size: 5544 bytes
    Desc: not available
    Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20051207/cb736515/smime-0001.bin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedDec 7, '05 at 10:56a
activeDec 7, '05 at 5:33p
posts13
users8
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase