cascade-dataform — general Data::FormValidator discussion list

[dfv] Questions on writing my own constraints (2nd. attempt)

[Jonas B. N. <jo...@gm...>]

Hello,

I am somewhat a heavy user of (out of the box) Data::FormValidator. I  
am currently attempting to port some of my CPAN code, which has  
validation behavior to Data::FormValidator::Constraints::* modules.

I have followed the documentation and everything seems to work, but I  
feel I am missing something, I have examined several of the other  
implementations of constraints on CPAN, but this has not made me  
completely confident in how Data::FormValidator works or at least  
expect me to do things.

So I have a few questions, please bear with me since some of this  
things my be obvious, but I have just not understood the concept  
completely.

I have a constraint module.

It exports by request: valid_cvr, this validates whether a given  
parameter is a valid cvs according to an algorithm implemented in  
Business::DK::CVR.

At the same time I want to support untainting, in that sense that if  
any of the flags:

- untaint_all_constraints
- untaint_constraint_fields

Are set to true, this is also recommended in the POD.

So I have implemented:

match_cvr, also exported by request. The only thing this method does  
is match against the data for a certain format, no actual validation  
is done (see: valid_cvr above).

The implementations I have seen seem to have implemented either valid_  
or match_ as a thin wrapper for the other, so I am unsure as to I need  
to separate the two, which lead to the following questions.

1. If a user defines a profile with a field named cvr, would match_cvr  
be used to untaint this magically and would this not require default  
export? I can see a scenario where the user is only interested in  
untainting data not necessarily validating, so the separation in  
implementation makes sense in my opinion

2. It seems as if a validation, results in auto-untainting, according  
to my tests, where match_cvr is not called at all, so match_cvr does  
not need to be wrapped, is there any policies regarding this I should  
be aware of

So to sort of wrap this way too long mail up, I am unsure as to what  
the role and when a match_ method should be implemented and called.  
Let me know if I am unclear, but I have spent a lot of time writing  
tests to sort of try to get my head around writing my own constraints.


Thanks,

jonasbn


--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

Re: [dfv] Altering data in D::FV::Results

[Amelia I. <ame...@gm...>]

Back in Gotham City on 6 Aug 2008, at 13:46, Michael Peters wrote:

> Amelia Ireland wrote:
>
>> I want the validator to automatically ignore invalid and missing   
>> fields for some query parameters and use the default instead. I've   
>> created a subclass with this functionality, but I don't know  
>> whether  this is something that would be generally useful or not.
>
> Is it possible that you can do these things either before processing  
> the data and/or in your validator methods?

Yes, I was thinking about both of those options. I think perhaps my  
expectations of what the validator should do are probably slightly  
different to what DFV aims for; I want my validator to return the  
parameters ready for execution, or an error if one of the required  
parameters is off. There is plenty of scope for customising D::FV to  
do that without too much extra effort, though.

Amelia.

--
Amelia Ireland
GO Editorial Office
http://www.ebi.ac.uk || http://www.berkeleybop.org
BBOP Plant Project: http://bbopgarden.blogspot.com

Re: [dfv] Altering data in D::FV::Results

[Mark S. <ma...@su...>]

On Wed, 06 Aug 2008 16:46:42 -0400
Michael Peters <mp...@pl...> wrote:

> Amelia Ireland wrote:
> 
> > I want the validator to automatically ignore invalid and missing  
> > fields for some query parameters and use the default instead. I've  
> > created a subclass with this functionality, but I don't know whether  
> > this is something that would be generally useful or not. 
> 
> Is it possible that you can do these things either before processing the 
> data and/or in your validator methods?
> 
>    # before validation
>    $query->param('can_be_missing' => $default)
>      unless defined $query->param('can_be_missing');
> 
>    # in your validate method
>    my $dfv = shift;
>    my $val = $dfv->get_current_constraint_value();
>    return $default if !defined $val;
>    # do my real validation

Or along the same lines, the profile could be modified or replaced in a given
case, so that the missing/invalid came out as expected.

   Mark 

Re: [dfv] Altering data in D::FV::Results

[Michael P. <mp...@pl...>]

Amelia Ireland wrote:

> I want the validator to automatically ignore invalid and missing  
> fields for some query parameters and use the default instead. I've  
> created a subclass with this functionality, but I don't know whether  
> this is something that would be generally useful or not. 

Is it possible that you can do these things either before processing the 
data and/or in your validator methods?

   # before validation
   $query->param('can_be_missing' => $default)
     unless defined $query->param('can_be_missing');

   # in your validate method
   my $dfv = shift;
   my $val = $dfv->get_current_constraint_value();
   return $default if !defined $val;
   # do my real validation



> 
> Cheers,
> Amelia.
> 
> --
> Amelia Ireland
> GO Editorial Office
> http://www.ebi.ac.uk || http://www.berkeleybop.org
> BBOP Plant Project: http://bbopgarden.blogspot.com
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cascade-DataForm mailing list
> Cas...@li...
> https://lists.sourceforge.net/lists/listinfo/cascade-dataform
> 

-- 
Michael Peters
Plus Three, LP

Re: [dfv] Altering data in D::FV::Results

[Amelia I. <ame...@gm...>]

Back in Gotham City on 6 Aug 2008, at 12:18, Mark Stosberg wrote:

> On Wed, 6 Aug 2008 09:55:43 -0700
> Amelia Ireland <ame...@gm...> wrote:
[snip]
>> If I did want to be able to
>> add/edit values post-validation and have $r->success / $r->invalid /
>> $r->missing / $r->unknown return the correct, up-to-date values,  
>> would
>> I be better off creating my own subclass of D::FV::Results with these
>> capabilities?
>
> I think so. In years of hanging out this mailing list, this is the  
> first time
> I've heard of something trying to use DFV this way.
>
> I'm opening to hearing why this kind of functionality should be  
> included in
> DFV, but it seems very rarely needed.

I want the validator to automatically ignore invalid and missing  
fields for some query parameters and use the default instead. I've  
created a subclass with this functionality, but I don't know whether  
this is something that would be generally useful or not. Ideally I'd  
have flags which would tell DFV what to do when an error was  
discovered, e.g. missing => use the default, don't throw an error;  
invalid => use default, warn but don't throw an error, etc.. That's  
probably beyond what DFV was intended to do, though, so I wouldn't  
suggest such functionality needed to be added.

Cheers,
Amelia.

--
Amelia Ireland
GO Editorial Office
http://www.ebi.ac.uk || http://www.berkeleybop.org
BBOP Plant Project: http://bbopgarden.blogspot.com

Re: [dfv] Altering data in D::FV::Results

[Mark S. <ma...@su...>]

On Wed, 6 Aug 2008 09:55:43 -0700
Amelia Ireland <ame...@gm...> wrote:

> Hi all,
> 
> According to the D::FV::Results docs, you can add data to the valid  
> results using the syntax
> 
> $new_value = $r->valid('field',$new_value);
> 
> If you use this after validating to add a valid value to a constraint  
> that was previously invalid, is there anything which would update the  
> list of invalid params? I couldn't see anything when I skimmed the code.

No, the invalid() list is not updated as a side-effect.

> I also couldn't see any way of editing the invalid / missing / unknown  
> params without getting down and dirty and messing with the Results  
> data structure directly. Is that right? 

That's right.

> If I did want to be able to  
> add/edit values post-validation and have $r->success / $r->invalid /  
> $r->missing / $r->unknown return the correct, up-to-date values, would  
> I be better off creating my own subclass of D::FV::Results with these  
> capabilities?

I think so. In years of hanging out this mailing list, this is the first time
I've heard of something trying to use DFV this way.

I'm opening to hearing why this kind of functionality should be included in
DFV, but it seems very rarely needed.

I have seen some perhaps similar approaches in use:

- Running multiple validation cycles in a row for different stages.
- Pre-processing data before it given to DFV.

    Mark
-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[dfv] Altering data in D::FV::Results

[Amelia I. <ame...@gm...>]

Hi all,

According to the D::FV::Results docs, you can add data to the valid  
results using the syntax

$new_value = $r->valid('field',$new_value);

If you use this after validating to add a valid value to a constraint  
that was previously invalid, is there anything which would update the  
list of invalid params? I couldn't see anything when I skimmed the code.

I also couldn't see any way of editing the invalid / missing / unknown  
params without getting down and dirty and messing with the Results  
data structure directly. Is that right? If I did want to be able to  
add/edit values post-validation and have $r->success / $r->invalid /  
$r->missing / $r->unknown return the correct, up-to-date values, would  
I be better off creating my own subclass of D::FV::Results with these  
capabilities?

Thanks,
Amelia.
--
Amelia Ireland
GO Editorial Office
http://www.ebi.ac.uk || http://www.berkeleybop.org
BBOP Plant Project: http://bbopgarden.blogspot.com

Re: [dfv] Constraints and scalar values

[Mark S. <ma...@su...>]

On Wed, 30 Jul 2008 14:34:13 -0700
Amelia Ireland <ame...@gm...> wrote:

> Hello all,
> 
> I've run into a problem with D::FV and I was wondering if there's a  
> simple solution that I'm not seeing.
> 
> I've got a set of tests that I'm using with both D::FV and other parts  
> of my code to check parameters are OK. For the most part, these work  
> fine, as I'm usually comparing two input parameters or checking a  
> value is in a range. However, I am having a little problem with a test  
> to check that an object is of a certain subclass, due to D::FV's  
> assumption that scalars in the 'params' list are the names of input  
> parameters. To illustrate:
> 
> standard way of running the test:
> 
> test($param_value, 'text string')
> 
> This is what I'd like to have in the D::FV profile:
> {  constraint => \&test,
>     params => [ 'param_name', 'text string' ],
> }
> 
> What I want D::FV to do is to pass 'text string' as a string to the  
> test function. Instead, it's looking for a param named 'text string'.  
> Is there an elegant way around this problem, or am I going to have to  
> do some kludgy workaround, like having the text string stored in a  
> hash, which is preprocessed before running the test function?

Amelia, 

Using the "New School" method of writing constraints available with DFV for 4.0
will help address this issue, and look more attractive, too.

The result will be a constraint that is called just like you want it to look:

    test($param_value, 'text string') ;

And you'll be able to implement it so that you process the first value
as a field name, and the second value as a string.

The docs are here:
http://search.cpan.org/~markstos/Data-FormValidator-4.61/lib/Data/FormValidator/Constraints.pm#WRITING_YOUR_OWN_CONSTRAINT_ROUTINES

    Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[dfv] Constraints and scalar values

[Amelia I. <ame...@gm...>]

Hello all,

I've run into a problem with D::FV and I was wondering if there's a  
simple solution that I'm not seeing.

I've got a set of tests that I'm using with both D::FV and other parts  
of my code to check parameters are OK. For the most part, these work  
fine, as I'm usually comparing two input parameters or checking a  
value is in a range. However, I am having a little problem with a test  
to check that an object is of a certain subclass, due to D::FV's  
assumption that scalars in the 'params' list are the names of input  
parameters. To illustrate:

standard way of running the test:

test($param_value, 'text string')

This is what I'd like to have in the D::FV profile:
{  constraint => \&test,
    params => [ 'param_name', 'text string' ],
}

What I want D::FV to do is to pass 'text string' as a string to the  
test function. Instead, it's looking for a param named 'text string'.  
Is there an elegant way around this problem, or am I going to have to  
do some kludgy workaround, like having the text string stored in a  
hash, which is preprocessed before running the test function?

Thanks in advance for any help,

Amelia.

--
Amelia Ireland
GO Editorial Office
http://www.ebi.ac.uk || http://www.berkeleybop.org
BBOP Plant Project: http://bbopgarden.blogspot.com

Re: [dfv] Enterprise implementation of dynamic error messages

[Mark S. <ma...@su...>]

> I understand that dynamic error messages can be implemented by passing a
> coderef to the msgs hash instead of a hashref with the standard error
> messages. In fact, I've done a quick, simple implementation to get a feel
> for how the functionality works. It works great for a one-off, but I'm
> looking for a way to work that functionality into our enterprise (perl) web
> application architecture.
> 
> Currently, our applications provide a validator profile and the hashref of
> error messages and the framework takes care of all the processing and error
> formatting and display. What I'm looking for is a way to allow developers of
> new applications to have their constraints generate dynamic error messages.
> The most common need would be something like a max_length constraint that
> should be able to indicate what the actual max_length argument passed to it
> was so instead of an error like "too long" it should say "can be no more
> than 15 characters".
> 
> Does anyone have any suggestions of how to start on implementing this with
> DFV? I've spent a couple of hours thinking about it and looking through the
> code in DFV and DFV::Results and I the ideas I've had thus far are rather
> involved and include sub-classing both of those classes and rewriting a good
> bit of code.

Andrew,

It sounds you want error messages that are field-based, or least have the
option to me of the default constraint error isn't specific enough.

Here are some ideas:

- I believe for each field you can see which constraint it failed. I expect in
  the custom 'msgs' code you can analyze this and add specific error messages
  then (if not in the profile). Some people do this in their templates.

- You might also look at Data::Form::Elements 
  http://search.cpan.org/~plural/Data-Form-Elements-0.61/

  It provides an alternate, field-based API to DFV, allowing you to declare a
  custom error message for a field up front. I haven't used it myself nor heard
  much feedback on it, but it seems like it may be helpful to you.

    Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[dfv] Enterprise implementation of dynamic error messages

[Andrew G. <ag...@bu...>]

I understand that dynamic error messages can be implemented by passing a
coderef to the msgs hash instead of a hashref with the standard error
messages. In fact, I've done a quick, simple implementation to get a feel
for how the functionality works. It works great for a one-off, but I'm
looking for a way to work that functionality into our enterprise (perl) web
application architecture.

Currently, our applications provide a validator profile and the hashref of
error messages and the framework takes care of all the processing and error
formatting and display. What I'm looking for is a way to allow developers of
new applications to have their constraints generate dynamic error messages.
The most common need would be something like a max_length constraint that
should be able to indicate what the actual max_length argument passed to it
was so instead of an error like "too long" it should say "can be no more
than 15 characters".

Does anyone have any suggestions of how to start on implementing this with
DFV? I've spent a couple of hours thinking about it and looking through the
code in DFV and DFV::Results and I the ideas I've had thus far are rather
involved and include sub-classing both of those classes and rewriting a good
bit of code.

Any suggestions would be much appreciated.

Andrew

-- 

Andrew Gianni - Senior Programmer Analyst
Administrative Computing Services / Computing and Information Technology
University at Buffalo, State University of New York
email: ag...@bu... | phone: 716.645.5332 | fax: 716.645.3588

Re: [dfv] Data::FormValidator damages my data when untainting

[Michael P. <mp...@pl...>]

Alexander Foken wrote:

> And when not untainting, it seems to take the return value simply as a
> boolean indicating valid data. And THAT behaviour is documented and
> shown in various examples.

If you write your methods to work in untainting then they will work when not
untainting (with the small exception of allowing 0 as a valid value, then you
need to return a zero-but-true value).

>> This allows you to clean up the data as you're untainting. In fact,
>> lots of
>> times cleaning up the data allows you to untaint it.
> I know.
>>  It would be a shame if you
>> had to clean it up twice (once to validate and once to use after
>> validation).
>>   
> 
> Right. But I would prefer not having to change lots of code just to make
> D::FV behave also in untainting mode.

D::FV's built-in methods work for both untainting and non-untainting modes. You
can look at them as examples of how to do the same for your routines.

> That leaves two more failed tests in the script, and at least one more
> bug in the documentation.

I'm sure Mark would take patches to the documentation :)
> 
> Alexander
> 
> ---8<--- cut here ---8<--- cut here ---8<---  cut here ---8<---
> 
> 
> 1..10
> # Taint mode is disabled.
> # *** testing with untainting disabled ***
> ok 1 - all data valid
> # --- prediction: The following tests will pass ---
> ok 2 - input email1 appears in output unmodified
> ok 3 - input email2 appears in output unmodified
> ok 4 - input email3 appears in output unmodified
> ok 5 - input email4 appears in output unmodified
> # *** testing with untainting enabled ***
> ok 6 - all data valid
> # --- prediction: The following tests will fail ---
> ok 7 - input email1 appears in output unmodified
> ok 8 - input email2 appears in output unmodified
> not ok 9 - input email3 appears in output unmodified
> #   Failed test 'input email3 appears in output unmodified'
> #   at d-fv-testcase-untaint.pl line 71.
> #          got: '1'
> #     expected: 'be...@ex...'

That's because your routine is still returning 1. You have:

  return $val=~/\@example.com$/;

> not ok 10 - input email4 appears in output unmodified
> #   Failed test 'input email4 appears in output unmodified'
> #   at d-fv-testcase-untaint.pl line 71.
> #          got: '@example.com'
> #     expected: 'ti...@ex...'

It seems the if you just supply a regex that DFV will return what the match
returned (probably in list context) so it's what matched.

Try changing it from
  email4 => qr/\@example.com/
to
  email4 => qr/.*\@example.com/

I agree that there is a difference when writing your constraints for untainting
mode, but it is possible to write validation rules that work in both.

-- 
Michael Peters
Plus Three, LP

Re: [dfv] Data::FormValidator damages my data when untainting

[Alexander F. <af...@ge...>]

Michael Peters wrote:
> Alexander Foken wrote:
>
>   
>> Everything works well without untainting, all valid data is passed 
>> through unmodified. With untainting enabled, the validated data becomes 
>> either a 1 or some random part (last match?) of the original data.
>>     
>
> When untainting, D::FV just takes the value that you returned and untaints it.
>   
And when not untainting, it seems to take the return value simply as a 
boolean indicating valid data. And THAT behaviour is documented and 
shown in various examples.

> This allows you to clean up the data as you're untainting. In fact, lots of
> times cleaning up the data allows you to untaint it.
I know.
>  It would be a shame if you
> had to clean it up twice (once to validate and once to use after validation).
>   

Right. But I would prefer not having to change lots of code just to make 
D::FV behave also in untainting mode.
>   
>> sub make_email_constraint
>> {
>>     return sub {
>>         my $self=shift;
>>         $self->set_current_constraint_name('email');
>>         my $v=$self->get_current_constraint_value();
>>         return 1 if defined($v) && $v=~/\@example.com$/;
>>         return;
>>     };
>> }
>>     
>
> Try making that sub
> sub make_email_constraint
> {
>     return sub {
>         my $self=shift;
>         $self->set_current_constraint_name('email');
>         my $v=$self->get_current_constraint_value();
>         return $v if defined($v) && $v=~/\@example.com$/;
>         return;
>     };
> }
>   
Like changing the example from D::FV::Tutorial from

        constraints => {
            email1 => sub {
                # copied from D::FV::Tutorial
                my $email=shift;
                if ($email=~/\@example.com$/) {
                    # only allow example.com addresses  
                    return 1; # <--- AS DOCUMENTED
                } else {
                    return 0;
                }
            }
        },

to

        constraints => {
            email1 => sub {
                # copied from D::FV::Tutorial
                my $email=shift;
                if ($email=~/\@example.com$/) {
                    # only allow example.com addresses  
                    return $email; # <-- MAKING IT REALLY WORK
                } else {
                    return 0;
                }
            }
        },


That leaves two more failed tests in the script, and at least one more 
bug in the documentation.

Alexander

---8<--- cut here ---8<--- cut here ---8<---  cut here ---8<---


1..10
# Taint mode is disabled.
# *** testing with untainting disabled ***
ok 1 - all data valid
# --- prediction: The following tests will pass ---
ok 2 - input email1 appears in output unmodified
ok 3 - input email2 appears in output unmodified
ok 4 - input email3 appears in output unmodified
ok 5 - input email4 appears in output unmodified
# *** testing with untainting enabled ***
ok 6 - all data valid
# --- prediction: The following tests will fail ---
ok 7 - input email1 appears in output unmodified
ok 8 - input email2 appears in output unmodified
not ok 9 - input email3 appears in output unmodified
#   Failed test 'input email3 appears in output unmodified'
#   at d-fv-testcase-untaint.pl line 71.
#          got: '1'
#     expected: 'be...@ex...'
not ok 10 - input email4 appears in output unmodified
#   Failed test 'input email4 appears in output unmodified'
#   at d-fv-testcase-untaint.pl line 71.
#          got: '@example.com'
#     expected: 'ti...@ex...'
# Looks like you failed 2 tests of 10.

---8<--- cut here ---8<--- cut here ---8<---  cut here ---8<---



-- 
Alexander Foken
getPraised GmbH

Bei den Mühren 70 | 20457 Hamburg | Germany 
Phone +49 40 80 79 59 59 | Fax +49 40 80 79 59 61 
<mailto:af...@ge...>

Sitz der Gesellschaft: Hamburg 
AG Hamburg, HRB 10 28 34
Umsatzsteuernummer beantragt 
Geschäftsführer: Dr. Dirk P. Weiß, Julia C. Weiß








Please inform us immediately if this e-mail and/or any attachment was 
transmitted incompletely or was not intelligible.
___________________________________________________________________________
 
This e-mail and any attachment is for authorized use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by any other party. 
If you are not an intended recipient then please promptly delete this 
e-mail and any attachment and all copies and inform the sender.

Re: [dfv] Data::FormValidator damages my data when untainting

[Michael P. <mp...@pl...>]

Alexander Foken wrote:

> Everything works well without untainting, all valid data is passed 
> through unmodified. With untainting enabled, the validated data becomes 
> either a 1 or some random part (last match?) of the original data.

When untainting, D::FV just takes the value that you returned and untaints it.
This allows you to clean up the data as you're untainting. In fact, lots of
times cleaning up the data allows you to untaint it. It would be a shame if you
had to clean it up twice (once to validate and once to use after validation).

> sub make_email_constraint
> {
>     return sub {
>         my $self=shift;
>         $self->set_current_constraint_name('email');
>         my $v=$self->get_current_constraint_value();
>         return 1 if defined($v) && $v=~/\@example.com$/;
>         return;
>     };
> }

Try making that sub
sub make_email_constraint
{
    return sub {
        my $self=shift;
        $self->set_current_constraint_name('email');
        my $v=$self->get_current_constraint_value();
        return $v if defined($v) && $v=~/\@example.com$/;
        return;
    };
}

-- 
Michael Peters
Plus Three, LP

[dfv] Data::FormValidator damages my data when untainting

[Alexander F. <af...@ge...>]

Hello List,

I run a CGI/FastCGI application in taint mode using Data::FormValidator 
(v4.57) for input verification. Unfortunately, D::FV damages my data as 
soon as I enable untainting. Test script and perl -V output at the 
bottom of this message.

Everything works well without untainting, all valid data is passed 
through unmodified. With untainting enabled, the validated data becomes 
either a 1 or some random part (last match?) of the original data. I 
expect D::FV to return exactly the data it returns without untainting, 
but with the taint flag disabled.

Alexander Foken

---8<--- cut here ---8<--- cut here ---8<---  cut here ---8<---

#!/usr/bin/perl

use strict;
use warnings;
use Test::More tests => 10;
use Data::FormValidator ();

sub make_email_constraint
{
    return sub {
        my $self=shift;
        $self->set_current_constraint_name('email');
        my $v=$self->get_current_constraint_value();
        return 1 if defined($v) && $v=~/\@example.com$/;
        return;
    };
}

print "# Taint mode is ",${^TAINT} ? ${^TAINT}>0 ? "enabled" : "enabled 
in warnings mode" : "disabled",".\n";

foreach my $untaint (0..1) {
    print '# *** testing with untainting ',$untaint ? 'enabled' : 
'disabled'," ***\n";
    my $input=bless {
        email1 => 'jo...@ex...',
        email2 => 'ma...@ex...',
        email3 => 'be...@ex...',
        email4 => 'ti...@ex...',
    },'FakeCGI';

    my $profile={
        $untaint ? (untaint_all_constraints => 1) : (),
        required => [
            'email1',
            'email2',
            'email3',
            'email4',
        ],
        constraints => {
            email1 => sub {
                # copied from D::FV::Tutorial
                my $email=shift;
                if ($email=~/\@example.com$/) {
                    # only allow example.com addresses
                    return 1;
                } else {
                    return 0;
                }
            }
        },
        constraint_methods => {
            email2 => make_email_constraint(),
            email3 => sub {
                # copied from D::FV manual page
                my ($dfv,$val)=@_;
                $dfv->set_current_constraint_name("who_cares");
                return $val=~/\@example.com$/;
            },
            email4 => qr/\@example.com/,
        },
    };
   
    my $r=Data::FormValidator->check($input,$profile);
   
    my $success=$r->success();
    ok($r->success(),'all data valid');

    print "# --- prediction: The following tests will ",$untaint ? 
"fail" : "pass"," ---\n";

    for (1..4) {
        my $name="email$_";
        is($r->valid($name),$input->{$name},"input $name appears in 
output unmodified");
    }
}

package FakeCGI;

sub param
{
    my $self=shift;
    return keys %$self unless @_;
    my $name=shift;
    return $self->{$name};
}


---8<--- cut here ---8<--- cut here ---8<---  cut here ---8<---

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=linux, osvers=2.6.18.6, archname=i486-linux-thread-multi
    uname='linux tree 2.6.18.6 #1 wed feb 14 17:58:17 cst 2007 i686 
athlon-4 i386 gnulinux '
    config_args='-de -Dprefix=/usr -Dcccdlflags=-fPIC 
-Dinstallprefix=/usr -Doptimize=-O2 -march=i486 -mtune=i686 -Dusethreads 
-Duseithreads -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.7 5.8.6 
5.8.5 5.8.4 5.8.3 5.8.2 5.8.1 5.8.0 -Darchname=i486-linux'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define 
usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-fno-strict-aliasing -pipe -Wdeclaration-after-statement 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -march=i486 -mtune=i686',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-fno-strict-aliasing -pipe -Wdeclaration-after-statement 
-I/usr/local/include'
    ccversion='', gccversion='4.1.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
                        PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS
                        USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
  Built under linux
  Compiled at Feb 16 2007 20:31:14
  @INC:
    /usr/lib/perl5/5.8.8/i486-linux-thread-multi
    /usr/lib/perl5/5.8.8
    /usr/lib/perl5/site_perl/5.8.8/i486-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.8
    /usr/lib/perl5/site_perl
    .


---8<--- cut here ---8<--- cut here ---8<---  cut here ---8<---

-- 
Alexander Foken
getPraised GmbH

Bei den Mühren 70 | 20457 Hamburg | Germany 
Phone +49 40 80 79 59 59 | Fax +49 40 80 79 59 61 
<mailto:af...@ge...>

Sitz der Gesellschaft: Hamburg 
AG Hamburg, HRB 10 28 34
Umsatzsteuernummer beantragt 
Geschäftsführer: Dr. Dirk P. Weiß, Julia C. Weiß








Please inform us immediately if this e-mail and/or any attachment was 
transmitted incompletely or was not intelligible.
___________________________________________________________________________
 
This e-mail and any attachment is for authorized use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by any other party. 
If you are not an intended recipient then please promptly delete this 
e-mail and any attachment and all copies and inform the sender.

[dfv] DFV 4.60 released

[Mark S. <ma...@su...>]

DFV 4.60 has now been released. It should appear on CPAN shortly. It
includes the following changes. Thanks to all the contributors!

    [NEW FEATURES]
    - Dependencies can now be specified using a code ref.
      Thanks to Bradley C Bailey, via RT#24935.

    [BUG FIXES]
    - length constraints for min, max and 'between' now work for lengths
       of 32k and longer. (Carl Vincent).
    - We now use Email::Valid to validate e-mail addresses instead of
      our own regrex. Email::Valid passed all our our existing
regression
      tests for e-mail addresses that should pass and fail. Email::Valid
      also correctly recognizes emails with single quote characters in
them.
      These are valid, but our regex didn't recognize them.  (Mark
Stosberg)

    [INTERNALS]
    - Typo in Constraints documentation corrected by K B Shiv Kumar
(RT#32358)
    - Add some tests and docs for "date_and_time" constraint, from
      Data::FormValidator:::Constraints::Dates.  It appears  there may
still
      exist a leap-year bug with the date parser. See the TODO test in
      t/dates_closure.t for details. An alternative is to use
      Data::FormValidator::Constraints::DateTime
      (Mark Stosberg, Matt Christian)



   Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . .
   Mark Stosberg            Principal Developer
   ma...@su...     Summersault, LLC
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[dfv] Questions on writing my own contraints

[Jonas B. N. <jo...@gm...>]

Hello,

I am somewhat a heavy user of (out of the box) Data::FormValidator. I  
am currently attempting to port some of my CPAN code, which has  
validation behavior to Data::FormValidator::Constraints::* modules.

I have followed the documentation and everything seems to work, but I  
feel I am missing something, I have examined several of the other  
implementations of constraints on CPAN, but this has not made me  
completely confident in how Data::FormValidator works or at least  
expect me to do things.

So I have a few questions, please bear with me since some of this  
things my be obvious, but I have just not understood the concept  
completely.

I have a constraint module.

It exports by request: valid_cvr, this validates whether a given  
parameter is a valid cvs according to an algorithm implemented in  
Business::DK::CVR.

At the same time I want to support untainting, in that sense that if  
any of the flags:

- untaint_all_constraints
- untaint_constraint_fields

Are set to true, this is also recommended in the POD.

So I have implemented:

match_cvr, also exported by request. The only thing this method does  
is match against the data for a certain format, no actual validation  
is done (see: valid_cvr above).

The implementations I have seen seem to have implemented either valid_  
or match_ as a thin wrapper for the other, so I am unsure as to I need  
to separate the two, which lead to the following questions.

1. If a user defines a profile with a field named cvr, would match_cvr  
be used to untaint this magically and would this not require default  
export? I can see a scenario where the user is only interested in  
untainting data not necessarily validating, so the separation in  
implementation makes sense in my opinion

2. It seems as if a validation, results in auto-untainting, according  
to my tests, where match_cvr is not called at all, so match_cvr does  
not need to be wrapped, is there any policies regarding this I should  
be aware of

So to sort of wrap this way too long mail up, I am unsure as to what  
the role and when a match_ method should be implemented and called.  
Let me know if I am unclear, but I have spent a lot of time writing  
tests to sort of try to get my head around writing my own constraints.


Thanks,

jonasbn
--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

Re: [dfv] Fw: FAIL Data-FormValidator-4.57 MSWin32-x86-multi-thread 5.1

[Mark S. <ma...@su...>]

On Fri, 09 May 2008 15:32:26 +0100
Dave Howorth <dho...@mr...> wrote:

> Mark Stosberg wrote:
> > I could use help debugging this test failure for DFV on  Perl 5.10. 
> > It has something to do with not finding Perl6::Junction.
> 
> I read something a while ago that suggested DFV failed to declare
> Perl6::Junction as a dependency. That would presumably explain the test
> failure. Is it in fact the case?

We do declare it, as seen on CPAN:

http://search.cpan.org/src/MARKSTOS/Data-FormValidator-4.57/Build.PL
http://search.cpan.org/src/MARKSTOS/Data-FormValidator-4.57/Makefile.PL

    Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

Re: [dfv] Fw: FAIL Data-FormValidator-4.57 MSWin32-x86-multi-thread 5.1

[Dave H. <dho...@mr...>]

Mark Stosberg wrote:
> I could use help debugging this test failure for DFV on  Perl 5.10. 
> It has something to do with not finding Perl6::Junction.

I read something a while ago that suggested DFV failed to declare
Perl6::Junction as a dependency. That would presumably explain the test
failure. Is it in fact the case?

Cheers, Dave

[dfv] Fw: FAIL Data-FormValidator-4.57 MSWin32-x86-multi-thread 5.1

[Mark S. <ma...@su...>]

I could use help debugging this test failure for DFV on  Perl 5.10. 
It has something to do with not finding Perl6::Junction.

    Mark

---------------

Begin forwarded message:

Date: Fri, 9 May 2008 09:34:55 -0400
From: DAGOLDEN <dag...@cp...>
To: cpa...@pe...
Cc: MAR...@cp...
Subject: FAIL Data-FormValidator-4.57 MSWin32-x86-multi-thread 5.1


This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible.  See
http://testers.cpan.org/

Please cc any replies to cpa...@pe... to keep other
test volunteers informed and to prevent any duplicate effort.

--
Dear Mark Stosberg,
    
This is a computer-generated report for Data-FormValidator-4.57
on perl 5.10.0, created by CPAN-Reporter-1.13. 

Thank you for uploading your work to CPAN.  However, there was a problem
testing your distribution.

If you think this report is invalid, please consult the CPAN Testers Wiki
for suggestions on how to avoid getting FAIL reports for missing library
or binary dependencies, unsupported operating systems, and so on:

http://cpantest.grango.org/wiki/CPANAuthorNotes

Sections of this report:

    * Tester comments
    * Program output
    * Prerequisites
    * Environment and other context

------------------------------
TESTER COMMENTS
------------------------------

Additional comments from tester: 

this report is from an automated smoke testing program
and was not reviewed by a human for accuracy

------------------------------
PROGRAM OUTPUT
------------------------------

Output from 'C:\strawberry\perl\bin\perl.exe ./Build test':

t\00_base..................................ok
t\02_code_ref..............................ok
t\03_dependency............................ok
t\04_arrayify_undef........................ok
t\05_valid_ip_address......................ok
t\06_regexp_map............................ok
t\09_require_some..........................ok
t\11_procedural_match......................ok
t\13_validator_packages....................ok
t\15_literal_param_constraints.............ok
t\16_cgi_object............................ok
t\17_multi_valued_keys.....................ok
t\18_constraint_refs.......................ok
t\19_refs_as_values........................ok
t\20_careful_exception_handling............ok
t\21_multiple_fields.......................ok
t\25_results...............................ok
t\26_qr....................................ok
t\27_qualify_ref_happy_death...............ok
t\28_defaults_for_new......................ok
t\30_filter_definedness....................ok
t\FV_length................................ok
t\any_errors...............................ok
t\check_profile_syntax.....................ok
t\constraint_method........................ok
t\constraint_method_string.................ok
t\constraint_regexp_map_profile_reuse......ok
t\constraints_builtin......................ok
t\constraints_builtin_closure..............ok
t\constraints_factory......................ok
t\constraints_invalid_once_only............ok
t\constraints_regexp_map_interaction.......ok
t\constraints_reuse........................ok
t\credit_card..............................ok
t\dates....................................ok
t\dates_closure............................ok
t\dependency_groups........................ok
t\filter_constraints.......................ok
t\filters_builtin..........................ok
t\filters_shouldnt_modify..................ok
t\get_filtered_data........................ok
t\get_input_data...........................ok
t\missing_optional.........................ok
t\msgs.....................................ok
t\multiple_constraints.....................ok
t\params_not_mentioned.....................ok
t\pod......................................ok
t\procedural_valid.........................ok
t\profile_checking.........................ok
t\regexp_common............................ok
t\regexp_common_closure....................Variable "$s" is not available at (re_eval 39) line 1.
Variable "$x" is not available at (re_eval 39) line 1.
ok
t\results_success..........................ok
t\simple...................................ok
t\tt_and_overload..........................skipped: Template Toolkit required
t\undefined_arrayref.......................ok
t\unknown..................................ok
t\untaint..................................Can't locate Perl6/Junction.pm in @INC (@INC contains: ./lib C \strawberry\cpan\build\Data-FormValidator-4.57-XVvWLx\blib\lib;C \strawberry\cpan\build\Data-FormValidator-4.57-XVvWLx\blib\arch;C \strawberry\cpan\build\Data-FormValidator-4.57-XVvWLx\_build\lib;C \strawberry\cpan\build\HTML-FillInForm-2.00-n4sWJE\blib\arch;C \strawberry\cpan\build\HTML-FillInForm-2.00-n4sWJE\blib\lib;C \strawberry\cpan\build\CGI-Application-4.06-khb6vC\blib\arch;C \strawberry\cpan\build\CGI-Application-4.06-khb6vC\blib\lib;C \strawberry\cpan\build\HTML-Template-2.9-dvHnIq\blib\arch;C \strawberry\cpan\build\HTML-Template-2.9-dvHnIq\blib\lib;C \strawberry\cpan\build\File-MMagic-1.27-vxPeaj/blib/arch;C \strawberry\cpan\build\File-MMagic-1.27-vxPeaj/blib/lib;C \strawberry\cpan\build\Regexp-Common-2.120-xo2KsI/blib/arch;C \strawberry\cpan\build\Regexp-Common-2.120-xo2KsI/blib/lib;C \strawberry\cpan\build\Date-Calc-5.4-khCPS9/blib/arch;C \strawberry\cpan\build\Date-Calc-5.4-khCPS9/blib/lib;C \strawberry\cpan\build\Bit-Vector-6.4-_DJuhk/blib/arch;C \strawberry\cpan\build\Bit-Vector-6.4-_DJuhk/blib/lib;C \strawberry\cpan\build\Carp-Clan-6.00-NeocN3/blib/arch;C \strawberry\cpan\build\Carp-Clan-6.00-NeocN3/blib/lib;C \strawberry\cpan\build\Perl6-Junction-1.30000-Jn9d7g/blib/arch;C \strawberry\cpan\build\Perl6-Junction-1.30000-Jn9d7g/blib/lib;C \strawberry\cpan\build\MIME-Types-1.23-RFzgKb/blib/arch;C \strawberry\cpan\build\MIME-Types-1.23-RFzgKb/blib/lib;C \strawberry\cpan\build\Test-Pod-1.26-7tfjLR/blib/arch;C \strawberry\cpan\build\Test-Pod-1.26-7tfjLR/blib/lib;C \strawberry\cpan\build\Image-Size-3.1.1-P75TKA/blib/arch;C \strawberry\cpan\build\Image-Size-3.1.1-P75TKA/blib/lib;C \strawberry\cpan\build\HTML-FillInForm-2.00-n4sWJE/blib/arch;C \strawberry\cpan\build\HTML-FillInForm-2.00-n4sWJE/blib/lib;C \strawberry\cpan\build\CGI-Application-4.06-khb6vC/blib/arch;C \strawberry\cpan\build\CGI-Application-4.06-khb6vC/blib/lib;C \strawberry\cpan\build\HTML-Template-2.9-dvHnIq/blib/arch;C \strawberry\cpan\build\HTML-Template-2.9-dvHnIq/blib/lib C:/STRAWB~1/perl/lib C:/STRAWB~1/perl/site/lib) at lib/Data/FormValidator.pm line 28.
BEGIN failed--compilation aborted at lib/Data/FormValidator.pm line 28.
Compilation failed in require at ./t/untaint.pl line 6.
BEGIN failed--compilation aborted at ./t/untaint.pl line 6.
 Failed 55/55 subtests 
t\upload...................................# Skipping CGI::Simple Tests
# testing with CGI.pm version: 3.29
# Running tests with CGI
ok
t\upload_closure...........................# testing with CGI.pm version: 3.29
ok

Test Summary Report
-------------------
t\untaint.t                            (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 55 tests but ran 0.
Files=59, Tests=499, 53 wallclock secs ( 0.11 usr +  0.97 sys =  1.08 CPU)
Result: FAIL
Failed 1/59 test programs. 0/499 subtests failed.

------------------------------
PREREQUISITES
------------------------------

Prerequisite modules loaded:

requires:

    Module          Need  Have    
    --------------- ----- --------
    Date::Calc      5     5.4     
    File::MMagic    1.17  1.27    
    Image::Size     0     3.100001
    MIME::Types     1.005 1.23    
    overload        0     1.06    
    perl            5.008 5.010000
    Perl6::Junction 1.1   1.30000 
    Regexp::Common  0     2.120   
    Scalar::Util    0     1.19    
    Test::More      0     0.78    

------------------------------
ENVIRONMENT AND OTHER CONTEXT
------------------------------

Environment variables:

    AUTOMATED_TESTING = 1
    COMSPEC = C:\WINDOWS\system32\cmd.exe
    INCLUDE = ;C:\strawberry\c\include;C:\strawberry\perl\lib\CORE;C:\strawberry\c\include;C:\strawberry\perl\lib\CORE
    LIB = ;C:\strawberry\c\lib;C:\strawberry\perl\bin;C:\strawberry\c\lib;C:\strawberry\perl\bin
    NUMBER_OF_PROCESSORS = 1
    PATH = C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\bin;C:\strawberry\c\bin;C:\strawberry\perl\bin;C:\strawberry\c\bin;C:\strawberry\perl\bin
    PERL5LIB = C:\strawberry\cpan\build\File-MMagic-1.27-vxPeaj/blib/arch;C:\strawberry\cpan\build\File-MMagic-1.27-vxPeaj/blib/lib;C:\strawberry\cpan\build\Regexp-Common-2.120-xo2KsI/blib/arch;C:\strawberry\cpan\build\Regexp-Common-2.120-xo2KsI/blib/lib;C:\strawberry\cpan\build\Date-Calc-5.4-khCPS9/blib/arch;C:\strawberry\cpan\build\Date-Calc-5.4-khCPS9/blib/lib;C:\strawberry\cpan\build\Bit-Vector-6.4-_DJuhk/blib/arch;C:\strawberry\cpan\build\Bit-Vector-6.4-_DJuhk/blib/lib;C:\strawberry\cpan\build\Carp-Clan-6.00-NeocN3/blib/arch;C:\strawberry\cpan\build\Carp-Clan-6.00-NeocN3/blib/lib;C:\strawberry\cpan\build\Perl6-Junction-1.30000-Jn9d7g/blib/arch;C:\strawberry\cpan\build\Perl6-Junction-1.30000-Jn9d7g/blib/lib;C:\strawberry\cpan\build\MIME-Types-1.23-RFzgKb/blib/arch;C:\strawberry\cpan\build\MIME-Types-1.23-RFzgKb/blib/lib;C:\strawberry\cpan\build\Test-Pod-1.26-7tfjLR/blib/arch;C:\strawberry\cpan\build\Test-Pod-1.26-7tfjLR/blib/lib;C:\strawberry\cpan\build\Image-Size-3.1.1-P75TKA/blib/arch;C:\strawberry\cpan\build\Image-Size-3.1.1-P75TKA/blib/lib;C:\strawberry\cpan\build\HTML-FillInForm-2.00-n4sWJE/blib/arch;C:\strawberry\cpan\build\HTML-FillInForm-2.00-n4sWJE/blib/lib;C:\strawberry\cpan\build\CGI-Application-4.06-khb6vC/blib/arch;C:\strawberry\cpan\build\CGI-Application-4.06-khb6vC/blib/lib;C:\strawberry\cpan\build\HTML-Template-2.9-dvHnIq/blib/arch;C:\strawberry\cpan\build\HTML-Template-2.9-dvHnIq/blib/lib
    PERL5OPT = 
    PERL5_CPANPLUS_IS_RUNNING = 332
    PERL5_CPAN_IS_RUNNING = 332
    PERL5_CPAN_IS_RUNNING_IN_RECURSION = 828,332
    PERL_CR_SMOKER_CURRENT = CGI-Application-Plugin-ValidateRM-2.2
    PERL_MM_USE_DEFAULT = 1
    PROCESSOR_IDENTIFIER = x86 Family 6 Model 15 Stepping 6, GenuineIntel
    TEMP = C:\DOCUME~1\David\LOCALS~1\Temp
    TERM = dumb

Perl special variables (and OS-specific diagnostics, for MSWin32):

    $^X = C:\strawberry\perl\bin\perl.exe
    $UID/$EUID = 0 / 0
    $GID = 0
    $EGID = 0
    Win32::GetOSName = WinXP/.Net
    Win32::GetOSVersion = Service Pack 2, 5, 1, 2600, 2, 2, 0, 768, 1
    Win32::FsType = FAT32
    Win32::IsAdminUser = 1

Perl module toolchain versions installed:

    Module              Have     
    ------------------- ---------
    CPAN                1.92_61  
    Cwd                 3.2701   
    ExtUtils::CBuilder  0.21     
    ExtUtils::Command   1.14     
    ExtUtils::Install   1.50     
    ExtUtils::MakeMaker 6.44     
    ExtUtils::Manifest  1.51_01  
    ExtUtils::ParseXS   2.19     
    File::Spec          3.2701   
    Module::Build       0.2808_01
    Module::Signature   n/a      
    Test::Harness       3.10     
    Test::More          0.78     
    YAML                0.66     
    YAML::Syck          1.04     
    version             0.74     


--

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX',
    optimize='-s -O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='3.4.5', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags ='-s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"'
    libpth=C:\strawberry\c\lib
    libs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32
    perllibs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32
    libc=-lmsvcrt, so=dll, useshrplib=true, libperl=libperl510.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"'


-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

Re: [dfv] volunteer sought for DFV length test and bug fix.

[Mark S. <ma...@su...>]

Carl,

Your patch for improved length calculation has now been applied to the
DFV darcs repo and will appear in the next release. There are a couple
of other pending improvements, otherwise I would just put out the next
release tonight.

Thanks again for the contribution!

    Mark

-- 
 . . . . 1997-2007: Ten Years of Excellence. . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

Re: [dfv] PATCH: email constraint handling real names and apostrophes

[Mark S. <ma...@su...>]

>> Mark Stosberg <ma...@st...>
>>
>> I know that's an RFC valid format, but DFV rejects it because it most often 
>> not what we mean when we say "enter your email address here".
> 
> Be careful not to confuse the various kinds of email addresses.
> 
> What you showed above is a "mailbox," which is "either an addr-spec or a phrase
> followed by a route-addr."  A route-addr is an addr-spec inside of angle
> brackets.  (Well, there's more to it, but nothing that ever, ever, ever comes
> up.)
> 
> When you say, "Please provide your email address," you generally mean, "please
> provide an addr-spec."  
 >
 > ...
> 
> I think, but am not sure, that you canjust fail if $addr ne $input.  

Ok, then here's a refactoring if the DFV function, which passes all of 
the existing DFV tests for what we want to accept and reject, plus a new 
test that accepts apostrophes as a valid part of the user name.  The 
($addr eq $input) test was necessary to make the test mentioned above 
fail like I wanted.

Have I missed anything else, or is this ready to go golden in a DFV release?

sub match_email {
     my $in_email = shift;

     require Email::Valid;
     my $valid_email;

     # The extra check that the result matches the input prevents
     # an address like this from being considered valid: Joe Smith 
<jo...@sm...>
     if (    ($valid_email = Email::Valid->address($in_email) )
         and ($valid_email eq $in_email)) {
         return $valid_email;
     }
     else {
         return undef;
     }
}


> Confused yet?  Please enjoy my YAPC::NA talk, Email Hates the Living:
> 
>   http://conferences.mongueurs.net/yn2008/talk/963

I will likely be there!

    Mark

-- 
  . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Mark Stosberg            Principal Developer
    ma...@su...     Summersault, LLC
    765-939-9301 ext 202     database driven websites
  . . . . . http://www.summersault.com/ . . . . . . . .

Re: [dfv] The email constraint and including real names.

[Mark S. <ma...@su...>]

Michael Peters wrote:
> Mark Stosberg wrote:
> 
>> Do you see many "false negatives"... addresses you accepted but should 
>> have been rejected?
> 
> I can't recall any.

Thanks.

I've done a preliminary patch to DFV to switch to using Email::Valid as 
a backend. We already had a number of tests for e-mail formats that we'd 
like to accept and reject. After switching to Email::Valid, one test 
failed in the DFV suite, which related to this format:

Mark Stosberg <ma...@st...>

I know that's an RFC valid format, but DFV rejects it because it most 
often not what we mean when we say "enter your email address here".

I'm curious how Email::Valid users handle this case. Would you then 
strip out the "extra" stuff if it exists, or just go ahead and store the 
whole thing in the database?

Personally, I like the DFV behavior of rejecting this format, at least 
in the context of validating web forms.

    Mark

Re: [dfv] The email constraint and apostrophes...how strict should we be?

[Michael P. <mp...@pl...>]

Mark Stosberg wrote:

> Do you see many "false negatives"... addresses you accepted but should 
> have been rejected?

I can't recall any.

-- 
Michael Peters
Plus Three, LP

Re: [dfv] The email constraint and apostrophes...how strict should we be?

[Mark S. <ma...@su...>]

Ricardo, and Michael: Thank you for your informed responses.

> Email::Valid is an excellent way to validate to RFC, and then the extra steps
> that make the check useful, like valid or existing domains.  Its regex, while
> hairy and complex, does not allow in any false positives that I know of.

Do you see many "false negatives"... addresses you accepted but should 
have been rejected?

       Mark