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

People
Owner: Nobody in particular
Requestors: robin [...] robinclarke.net
Cc:
AdminCc:

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



Subject: Bug with Data::FormValidator::Results
Date: Wed, 19 Nov 2008 03:11:20 +0100 (CET)
To: bug-Data-FormValidator [...] rt.cpan.org
From: Robin Clarke <robin [...] robinclarke.net>
Hello! I'm not sure if this is considered a bug, but it's something which took me by surprise, and if it's a "feature", should be documented: Here's a simplified example of how I was using the Data::FormValidator: sub function { my $hashref_input = shift; my $check = Data::FormValidator->check( $hashref_input, { # conditions } ); # At this point ref( $check ) shows Data::FormValidator::Results return $check; } my $results = &function( $hashref_input ); # Now $results is the result of $results->success(), and so calling # $results->valid() causes an error I got around this by dereferencing/referencing: return \$check; } my $results = ${ &function( $hashref_input ) }; But this is not "nice". It'd be real cool if you could document, or fix this feature, and save others some headache. Best winds, -Robin- -- P.S. Check out my revamped, bloggish website: http://robinclarke.net/
Subject: Re: [rt.cpan.org #41051] Bug with Data::FormValidator::Results
Date: Wed, 19 Nov 2008 10:18:43 -0500
To: bug-Data-FormValidator [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Show quoted text
> I'm not sure if this is considered a bug, but it's something which took me > by surprise, and if it's a "feature", should be documented: > > Here's a simplified example of how I was using the Data::FormValidator: > > sub function > { > my $hashref_input = shift; > my $check = Data::FormValidator->check( $hashref_input, { # conditions } ); > # At this point ref( $check ) shows Data::FormValidator::Results > return $check; > } > > my $results = &function( $hashref_input ); > # Now $results is the result of $results->success(), and so calling > # $results->valid() causes an error > > I got around this by dereferencing/referencing: > > return \$check; > } > > my $results = ${ &function( $hashref_input ) }; > > But this is not "nice". > > It'd be real cool if you could document, or fix this feature, and save > others some headache.
Robin, I believe what you ran into is related to this bit of documentation from ::Results: "As a shorthand, When the $results object is used in boolean context, it is overloaded to use the value of success() instead." I'm not sure where you are introducing the boolean context, but this looks unusual: my $results = ${ &function( $hashref_input ) }; Normally this would be done instead: my $results = function( $hashref_input ); You might also try this: "return ($check)" If you have an idea of ways to further clarify the documentation about this, I'm open to it. Mark
Subject: Re: [rt.cpan.org #41051] Bug with Data::FormValidator::Results
Date: Wed, 19 Nov 2008 19:59:32 +0100 (CET)
To: "mark [...] summersault.com via RT" <bug-Data-FormValidator [...] rt.cpan.org>
From: Robin Clarke <robin [...] robinclarke.net>
Hi Mark, I'm very sorry for, not reading the documentation properly (I feel like a right dork now having missed out exactly the sentance I complained was missing), and then, wasting your time. I guess working over-tired isn't worth it! I owe you a beer! Best winds, -Robin- On Wed, 19 Nov 2008, mark@summersault.com via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=41051 > >
>> I'm not sure if this is considered a bug, but it's something which took me >> by surprise, and if it's a "feature", should be documented: >> >> Here's a simplified example of how I was using the Data::FormValidator: >> >> sub function >> { >> my $hashref_input = shift; >> my $check = Data::FormValidator->check( $hashref_input, { # conditions } ); >> # At this point ref( $check ) shows Data::FormValidator::Results >> return $check; >> } >> >> my $results = &function( $hashref_input ); >> # Now $results is the result of $results->success(), and so calling >> # $results->valid() causes an error >> >> I got around this by dereferencing/referencing: >> >> return \$check; >> } >> >> my $results = ${ &function( $hashref_input ) }; >> >> But this is not "nice". >> >> It'd be real cool if you could document, or fix this feature, and save >> others some headache.
> > Robin, > > I believe what you ran into is related to this bit of documentation from ::Results: > > "As a shorthand, When the $results object is used in boolean context, it is > overloaded to use the value of success() instead." > > I'm not sure where you are introducing the boolean context, but this looks unusual: > > my $results = ${ &function( $hashref_input ) }; > > Normally this would be done instead: > > my $results = function( $hashref_input ); > > You might also try this: "return ($check)" > > If you have an idea of ways to further clarify the documentation about this, I'm open to it. > > > Mark >
Subject: Re: [rt.cpan.org #41051] Bug with Data::FormValidator::Results
Date: Wed, 19 Nov 2008 14:06:14 -0500
To: bug-Data-FormValidator [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Show quoted text
> I'm very sorry for, not reading the documentation properly (I feel like a > right dork now having missed out exactly the sentance I complained was > missing), and then, wasting your time. I guess working over-tired isn't > worth it! > I owe you a beer!
Robin, I'm sorry I was talked into to adding this behavior in the first place. I haven't found it particularly useful myself, and I doubt you are the only person who has been unpleasantly surprised by this "feature". If or when Data::FormValidator is re-written, I would definitely consider dropping this feature. Your feedback has been helpful.... although if you aren't sure whether or not something is a bug, please ask about it on the mailing list first, so other users can share the support load. Thanks! Mark
I'm resolving this as a non-bug.