Skip Menu |

This queue is for tickets about the Data-FormValidator CPAN distribution.

Maintainer(s)' notes

This is the bug queue for Data::FormValidator.

Report information
The Basics
Id: 22589
Status: resolved
Priority: 0/
Queue: Data-FormValidator

People
Owner: MARKSTOS [...] cpan.org
Requestors: GTERMARS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 4.40
Fixed in: (no value)



Subject: Filters only apply to value being constrained, not other values it may be compared against
When working with both constraints and filters, the filters apply -only- to the value being constrained, and not any other value that it may be compared against. I ran across this while working on a password confirmation form that uses the "trim" filter to validate input; if you enter the same password both times and it has leading/trailing whitespace in it, the FV_eq_with() constraint fails. Failure is because although the field being constrained has been run through the appropriate filters, the other data that is compared against hasn't. According to the docs, however, filters are applied before constraints are invoked. I interpreted that to mean on -all- of the data that could be accessed while invoking the constraints, not just the one value being constrained.
Subject: trythis.pl
CC: 'Data::FormValidator list' <cascade-dataform [...] lists.sourceforge.net>
Subject: Re: [rt.cpan.org #22589] Filters only apply to value being constrained, not other values it may be compared against
Date: Thu, 26 Oct 2006 09:37:52 -0400
To: bug-Data-FormValidator [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Graham TerMarsch via RT wrote: Show quoted text
> > Requestors: GTERMARS@cpan.org > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=22589 > > > > When working with both constraints and filters, the filters > apply -only- to the value being constrained, and not any other value > that it may be compared against. > > I ran across this while working on a password confirmation form that > uses the "trim" filter to validate input; if you enter the same > password both times and it has leading/trailing whitespace in it, the > FV_eq_with() constraint fails. > > Failure is because although the field being constrained has been run > through the appropriate filters, the other data that is compared > against hasn't. > > According to the docs, however, filters are applied before constraints > are invoked. I interpreted that to mean on -all- of the data that > could be accessed while invoking the constraints, not just the one > value being constrained.
I agree with the assessment that the current behavior here seems wrong. A formal test case and patch would be appreciated. I'm CC'ing the list to notify everyone of the issue, and open the doors for other people to participate in addressing it as well. For anyone who chooses to: Please add your comments and code to the bug tracker so we've got central place to track the resolution. Thanks! Mark
On Thu Oct 26 09:40:45 2006, mark@summersault.com wrote: Show quoted text
> Graham TerMarsch via RT wrote:
Show quoted text
> > When working with both constraints and filters, the filters > > apply -only- to the value being constrained, and not any other value > > that it may be compared against.
[...] Show quoted text
> > Failure is because although the field being constrained has been run > > through the appropriate filters, the other data that is compared > > against hasn't.
The problem isn't that the filters haven't been applied, it's that the FV_eq_with method uses the get_input_data() method to retrieve the other parameters to the constraint, rather than using the parameters that were passed directly. get_input_data() returns the (unfiltered) raw input, so FV_eq_with (and any method that uses get_input_data()) doesn't see the result of the filters. A solution is to use the parameter passed directly to the method: sub FV_eq_with { return sub { my $dfv = shift; $dfv->name_this('eq_with'); my $curr_val = $dfv->get_current_constraint_value; my $other_val = shift; return ($curr_val eq $other_val); } } This doesn't address the problem that the documentation is inaccurate in that it suggests using $dfv->get_input_data() to retrieve the other fields for examination. The problem is that there isn't any way to get to the intermediate filtered fields before the constraints are applied -- they are stored in a lexical %valid hash in the _process method. Any ideas for a way to access the filtered data from constraints other than passing the values in directly? Thanks, -E
CC: "Evan A. Zacks" <e [...] zacks.org>
Subject: Re: [rt.cpan.org #22589] Filters only apply to value being constrained, not other values it may be compared against
Date: Thu, 26 Oct 2006 11:34:13 -0400
To: bug-Data-FormValidator [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Show quoted text
> > Any ideas for a way to access the filtered data from constraints other > than passing the values in directly?
Evan, Thanks for looking at this. It sounds like we need a new "get_filtered_data()" function for just this purpose. Mark
From: GTERMARS [...] cpan.org
On Thu Oct 26 09:40:45 2006, mark@summersault.com wrote: Show quoted text
> Graham TerMarsch via RT wrote: > I agree with the assessment that the current behavior here seems > wrong. > > A formal test case and patch would be appreciated. I'm CC'ing the > list to notify everyone of the issue, and open the doors for other > people to participate in addressing it as well.
I've attached a patch here which implements a new "get_filtered_data()" method and which addresses the problem that I'd encountered (by updating FV_eq_with to use filtered data instead of input data). A new test file was added to test the method and to verify my use case.
Binary files Data-FormValidator-4.49_1.orig/Data-FormValidator-4.49_1.tar.gz and Data-FormValidator-4.49_1/Data-FormValidator-4.49_1.tar.gz differ diff -r --new-file Data-FormValidator-4.49_1.orig/lib/Data/FormValidator/Constraints.pm Data-FormValidator-4.49_1/lib/Data/FormValidator/Constraints.pm 326c326 < my $data = $dfv->get_input_data; --- > my $data = $dfv->get_filtered_data; 531c531 < my $data = $dfv->get_input_data; --- > my $data = $dfv->get_filtered_data; 771c771 < my $data = $dfv->get_input_data; --- > my $data = $dfv->get_filtered_data; 835a836,848 > =head3 get_filtered_data() > > Returns the filtered input data. This may be a CGI object if that's what > was used in the constraint routine. > > B<Examples:> > > # Raw and uncensored > my $data = $self->get_filtered_data; > > # tamed to be a hashref, if it wasn't already > my $data = $self->get_filtered_data( as_hashref => 1 ); > diff -r --new-file Data-FormValidator-4.49_1.orig/lib/Data/FormValidator/Results.pm Data-FormValidator-4.49_1/lib/Data/FormValidator/Results.pm 170a171,173 > > # store the filtered data away for later use > $self->{__FILTERED_DATA} = \%valid; 726a730,741 > sub get_filtered_data { > my $self = shift; > my %p = @_; > if ($p{as_hashref}) { > my %hash = $self->_get_input_as_hash( $self->{__FILTERED_DATA} ); > return \%hash; > } > else { > return $self->{__FILTERED_DATA}; > } > } > diff -r --new-file Data-FormValidator-4.49_1.orig/MANIFEST Data-FormValidator-4.49_1/MANIFEST 55a56 > t/get_filtered_data.t diff -r --new-file Data-FormValidator-4.49_1.orig/t/get_filtered_data.t Data-FormValidator-4.49_1/t/get_filtered_data.t 0a1,48 > use strict; > use Test::More tests => 4; > use Data::FormValidator; > use Data::FormValidator::Constraints qw(FV_eq_with); > > # Empty data/empty results; make sure fcn call works fine > access_filtered_data_no_data: { > my $results = Data::FormValidator->check( {}, {} ); > my $filtered = $results->get_filtered_data(); > is_deeply( $filtered, {}, 'get_filtered_data works for empty hashref' ); > } > > # Test to make sure that we can access filtered data and that it looks right. > access_filtered_data: { > my $data = { > 'password' => ' foo ', > 'confirm' => ' foo ', > }; > my $expect_filtered_data = { > 'password' => 'foo', > 'confirm' => 'foo', > }; > my $profile = { > 'required' => [qw( password confirm )], > 'filters' => 'trim', > }; > my $results = Data::FormValidator->check( $data, $profile ); > my $filtered = $results->get_filtered_data(); > is_deeply( $filtered, $expect_filtered_data, 'get_filtered_data returns correct filtered data' ); > } > > # RT#22589; FV_eq_with uses 'get_filtered_data()' > rt22589: { > my $data = { > 'password' => ' foo ', > 'confirm' => ' foo ', > }; > my $profile = { > 'required' => [qw( password confirm )], > 'filters' => 'trim', > 'constraint_methods' => { > 'confirm' => FV_eq_with('password'), > }, > }; > my $results = Data::FormValidator->check( $data, $profile ); > ok( $results->valid('password'), 'password valid' ); > ok( $results->valid('confirm'), 'confirm valid' ); > }
Graham, Thanks for your work on this. I've applied the patch now, with credit to you. However, I did further refine it. The structure returned is always a hashref, so there is no need for the "as_hashref' option. Mark On Fri Nov 03 17:54:26 2006, GTERMARS wrote: Show quoted text
> On Thu Oct 26 09:40:45 2006, mark@summersault.com wrote:
> > Graham TerMarsch via RT wrote: > > I agree with the assessment that the current behavior here seems > > wrong. > > > > A formal test case and patch would be appreciated. I'm CC'ing the > > list to notify everyone of the issue, and open the doors for other > > people to participate in addressing it as well.
> > I've attached a patch here which implements a > new "get_filtered_data()" method and which addresses the problem that > I'd encountered (by updating FV_eq_with to use filtered data instead > of input data). A new test file was added to test the method and to > verify my use case.