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: 18050
Status: resolved
Priority: 0/
Queue: Data-FormValidator

People
Owner: MARKSTOS [...] cpan.org
Requestors: perlmonkey [...] gmail.com
Cc:
AdminCc:

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



Subject: Defining messages in both the profile and by calling msgs() does not result in a merging of the lists
Per the documentation: Show quoted text
>Controls passed into the <msgs> method will be applied first, followed by > ones applied in the profile. This allows you to keep the controls you > pass to msgs as "global" and override them in a specific profile if needed
Data::FormValidator::Results::_generate_msgs has this code block: <code> my %profile = ( prefix => '', missing => 'Missing', invalid => 'Invalid', invalid_separator => ' ', format => '<span style="color:red;font-weight:bold"><span class="dfv_errors">* %s</span></span>', %{ $self->{msgs} }, %{ $self->{profile}{msgs} }, ); </code> This does not behave the way the POD specifies - $self->{profile}{msgs}{constraints} overrides the $self->{msgs}{constraints}. Like this: <code> use Data::Dumper; my %a = (a => { b => 2, c => 3}); my %b = (a => { d => 4, e => 5}); my %c = (a => {a => 1}, %a, %b ); print Dumper(\%c); </code> The above code results in: <code> $VAR1 = { 'a' => { 'e' => 5, 'd' => 4 } }; </code>
Thanks for the report. Would you mind providing a Test::More style test case that illustrates the issue? If you want to go ahead and include a proposed patch, all the better. Thanks, Mark On Tue Mar 07 18:24:52 2006, guest wrote: Show quoted text
> Per the documentation:
> >Controls passed into the <msgs> method will be applied first, followed by > > ones applied in the profile. This allows you to keep the controls you > > pass to msgs as "global" and override them in a specific profile if
needed Show quoted text
> > > Data::FormValidator::Results::_generate_msgs has this code block: > <code> > my %profile = ( > prefix => '', > missing => 'Missing', > invalid => 'Invalid', > invalid_separator => ' ', > > format => '<span style="color:red;font-weight:bold"><span > class="dfv_errors">* %s</span></span>', > %{ $self->{msgs} }, > %{ $self->{profile}{msgs} }, > ); > </code> > > > This does not behave the way the POD specifies - > $self->{profile}{msgs}{constraints} overrides the > $self->{msgs}{constraints}. > > Like this: > <code> > use Data::Dumper; > my %a = (a => { b => 2, c => 3}); > my %b = (a => { d => 4, e => 5}); > my %c = (a => {a => 1}, > %a, > %b > ); > > print Dumper(\%c); > </code> > > The above code results in: > <code> > $VAR1 = { > 'a' => { > 'e' => 5, > 'd' => 4 > } > }; > </code>
From: perlmonkey [...] gmail.com
Attached is the test script that demonstrates the problem in version 4.12 No patch is neccesary as version 4.30 does not have the same problem. It would be good to add the test to your distribution anyway for regression testing.
use Test::More tests => 11; use strict; use Data::Dumper; use Data::FormValidator; # # Prove this statement in the POD: # The exception here is definitions for your msgs key. You will safely be able to define # some defaults for this key and not have them entirely clobbered just because msgs was # defined in a validation profile. # eval { my $defaults = { msgs => { constraints => { default1 => 'default message', override1 => 'default message', }, }, }; my $data = { profile1 => 1, inline1 => 1, override1 => 1, }; my $profile = { required_regexp => qr/./, constraints => { profile1 => { name => 'profile1', constraint => sub {return}, }, }, constraint_methods => { inline1 => cl_override_msg('inline1', 'inline message'), override1 => cl_override_msg('override1','profile message'), }, msgs => { constraints => { profile1 => 'profile message', override1 => 'profile message', }, }, }; my $validator = Data::FormValidator->new($defaults); ok($validator,'validator instance created'); eval{ my $results = $validator->check($data, $profile); my $msgs = $results->msgs; ok($msgs,'messages exists. line ' . __LINE__); like($msgs->{profile1}, qr/profile message/,'profile1 uses profile message. line ' . __LINE__); like($msgs->{inline1}, qr/inline message/, 'inline1 uses inline message. line ' . __LINE__); like($msgs->{override1}, qr/profile message/,'override1 uses profile message. line ' . __LINE__); }; is ($@, '', "No exception at line " . __LINE__); }; is ($@, '', "No exception at line " . __LINE__); # # Prove that constraint messages can be overridden using the msgs() method from within the constraint. # eval { sub cl_override_msg { my ($name,$message) = @_; return sub { my $dfv = shift; $dfv->name_this($name); my $mhash = {}; $mhash->{constraints}{$name} = $message; $dfv->msgs( $mhash ); return; }; } my $results = Data::FormValidator->check( { profile1 => 1, inline1 => 1, override1 => 1, }, { required => [qw/profile1 inline1 override1/], constraints => => { profile1 => { name => 'profile1', constraint => sub {return}, }, }, constraint_methods => { inline1 => cl_override_msg('inline1', 'inline message'), override1 => cl_override_msg('override1','profile message'), }, msgs => { constraints => { profile1 => 'profile message', override1 => 'profile message', }, }, } ); my $msgs = $results->msgs; like($msgs->{profile1},qr/profile message/,'profile1 uses profile message. line ' . __LINE__); like($msgs->{inline1}, qr/inline message/,'inline1 uses inline message. line ' . __LINE__); like($msgs->{override1}, qr/profile message/,'override1 uses profile message. line ' . __LINE__); }; is ($@, '', "No exception at line " . __LINE__);
On Thu Jul 20 10:50:40 2006, perlmonkey@gmail.com wrote: Show quoted text
> Attached is the test script that demonstrates the problem in version 4.12 > > No patch is neccesary as version 4.30 does not have the same problem. > > It would be good to add the test to your distribution anyway for > regression testing.
Thanks for the contribution. I get the following failures when testing it against the 4.49_1 release. Would you mind you continue looking into this further? I appreciate your help distributing the open source software maintenance work load! ok 1 - validator instance created ok 2 - messages exists. line 50 # Failed test 'inline1 uses inline message. line 52' # in t/msgs_override.t at line 52. # '<span style="color:red;font-weight:bold"><span class="dfv_errors">* Invalid</span></span>' # doesn't match '(?-xism:inline message)' # Failed test 'inline1 uses inline message. line 108' # in t/msgs_override.t at line 108. # '<span style="color:red;font-weight:bold"><span class="dfv_errors">* Invalid</span></span>' # doesn't match '(?-xism:inline message)' # Looks like you failed 2 tests of 11. ok 3 - profile1 uses profile message. line 51 not ok 4 - inline1 uses inline message. line 52 ok 5 - override1 uses profile message. line 53 ok 6 - No exception at line 55 ok 7 - No exception at line 58 ok 8 - profile1 uses profile message. line 107 not ok 9 - inline1 uses inline message. line 108
On Tue Mar 07 18:24:52 2006, guest wrote: Show quoted text
> Per the documentation:
> >Controls passed into the <msgs> method will be applied first, followed by > > ones applied in the profile. This allows you to keep the controls you > > pass to msgs as "global" and override them in a specific profile if
needed Show quoted text
>
I looked at this in more detail, and am declaring this a "doc bug" and have fixed it as such. The intent was that you could override the /top level/ keys within msgs, and it seems to have been working that work. In the bigger picture, putting all this msgs functionality in DFV may have been a mistake. You can could still design a fancy override system, but use the new "msgs" callback to do that. If some other people want the "deep merging" functionality here, we could consider adding it, but I think it's a better long term plan to use the callback system to have msg processing outside of the core, and let DFV focus just on validation and not how to display the results. Mark