cascade-dataform — general Data::FormValidator discussion list

Re: [dfv] Two Proposals: "max_values" and add_element();

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

> On Jun 29, 2009, at 8:32 AM, Mark Stosberg wrote:
> >> On Fri, 2009-06-26 at 10:33 -0400, Mark Stosberg wrote:
> >>> I'm considering two enhancements for DFV that'd I'd like feedback  
> >>> on:
> >>
> [...]
> >>> 2. Constructing profiles by element.
> [...]
> >>> http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm#add_element()
> [...]
> > I was thinking that first you would build the traditional static
> > profile, and only after that point would would it make sense to call
> > add_element().
> >
> > I don't want to get a complicated situation of supporting all the
> > possible ways and orders in which you define various pieces of a DFV
> > profile.
> >
> > I would also like to avoid adding a method that returns the merged
> > profile, except perhaps through a debug flag. Although, maybe it's
> > unrealistic to not offer this once we have built-in tools for building
> > dynamic profiles.
> 
> 
> I wouldn't use add_element() unless there were also methods for all  
> the different things that you might want to do to an element - e.g.  
> remove it, alter it, get the new DFV profile with the added element,  
> etc.. I implemented something like this in some DFV-based code that I  
> wrote, and having it as part of DFV could well be useful.

Given your experience with this, would you like to propose what a more full-featured
API for this might look like?

    Mark

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

Re: [dfv] Two Proposals: "max_values" and add_element();

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

> On Fri, 2009-06-26 at 10:33 -0400, Mark Stosberg wrote:
> > I'm considering two enhancements for DFV that'd I'd like feedback on:
> > 
> > 2. Constructing profiles by element.  Currently profiles are primarily built-up
> > by listing out required fields, than optional fields, then constraints.
> > Sometimes it could be usefult to build up a profile in a more element-centric
> > way: You could express "Here's a field to add the profile. It's required, it
> > has this constraint, and it has error message".  This would be very handy if a
> > profile is used in multiple contexts, and you need to dynamically add some
> > fields to it in one context. There is already a model for this,
> > Data::Form::Elements.  Essentially, we could just borrow the "add_element()"
> > method from it: 
> > 
> > http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm#add_element()
> > 
> > To me, this approach would be a more elegant way to handle per-field configurations, like the "max_values" concept. 
> 
> I've needed this in the past, but I'd only use it if it (optionally)
> allowed setting any or all of:
> o constraint_methods
> o defaults
> o field_filters
> o optional 'v' required

I was thinking that first you would build the traditional static
profile, and only after that point would would it make sense to call
add_element().

I don't want to get a complicated situation of supporting all the
possible ways and orders in which you define various pieces of a DFV
profile.

I would also like to avoid adding a method that returns the merged
profile, except perhaps through a debug flag. Although, maybe it's
unrealistic to not offer this once we have built-in tools for building
dynamic profiles.

    Mark

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

[dfv] Fwd: Two Proposals: "max_values" and add_element();

[Julio F. <jul...@gm...>]

Mark,

I like the idea of building the profiles in a per-field basis. Besides
add_element, I think we would need a method to get access to the created
profile in order to modify it. For example, you should be able to add
constraints that affect several fields and I don't see a simple way of doing
this by adding one field at a time.

Data::Form::Elements actually builds the profile in its 'validate' method,
just before it is used, and not in add_element. In my opinion this should be
changed.

Julio Fraire


On Fri, Jun 26, 2009 at 9:33 AM, Mark Stosberg <ma...@su...> wrote:

> 2. Constructing profiles by element.  Currently profiles are primarily
> built-up
> by listing out required fields, than optional fields, then constraints.
> Sometimes it could be usefult to build up a profile in a more
> element-centric
> way: You could express "Here's a field to add the profile. It's required,
> it
> has this constraint, and it has error message".  This would be very handy
> if a
> profile is used in multiple contexts, and you need to dynamically add some
> fields to it in one context. There is already a model for this,
> Data::Form::Elements.  Essentially, we could just borrow the
> "add_element()"
> method from it:
>
>
> http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm#add_element()<http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm#add_element%28%29>
>
>

Re: [dfv] Two Proposals: "max_values" and add_element();

[Amelia I. <aj...@eb...>]

On Jun 26, 2009, at 7:33 AM, Mark Stosberg wrote:

> I'm considering two enhancements for DFV that'd I'd like feedback on:
>
> 1. "max_values". Currently DFV currently allows unlimited values to  
> be passed
> through a single field name. This is useful if you have a list of  
> form fields
> that all have the same field name. The problem is that this doesn't  
> allow you
> to be as strict as you might like. What you have want exactly one  
> value for
> each field, not any more? I don't think there's any easy way to tell  
> DFV to be
> strict about this now. To address this, we could allow setting  
> "max_values"
> both globally and locally. Globally, the useful values would be  
> "undef" for
> unlimited values, which is how it works now. Otherwise, you could  
> set it to "1"
> to restrict it to at most one value for each field.
>
> Also, we could add a way to set a local override for specific  
> fields, so that they can have a different number of max values than  
> the global value.


I would definitely welcome this; it always seemed strange to me that  
you can check many aspects of the values, but DFV doesn't check  
whether or not you are allowed more than one value. I wrote some  
additional code to handle this because it was a check that I needed to  
make.

On a related note, it would be handy if DFV::Results returned values  
in a uniform manner, rather than a scalar for single values and an  
arrayref for multiples. Perhaps something could be tied into the  
max_values code - e.g. if the field only allows a single value, return  
a scalar; if undef or multiple values are allowed, return an arrayref.  
Or better still, return an arrayref whatever, and leave the user's  
code to handle it. Maybe it's just me who thinks this, though...

Cheers!

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

[dfv] Two Proposals: "max_values" and add_element();

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

I'm considering two enhancements for DFV that'd I'd like feedback on:

1. "max_values". Currently DFV currently allows unlimited values to be passed
through a single field name. This is useful if you have a list of form fields
that all have the same field name. The problem is that this doesn't allow you
to be as strict as you might like. What you have want exactly one value for
each field, not any more? I don't think there's any easy way to tell DFV to be
strict about this now. To address this, we could allow setting "max_values"
both globally and locally. Globally, the useful values would be "undef" for
unlimited values, which is how it works now. Otherwise, you could set it to "1"
to restrict it to at most one value for each field.

Also, we could add a way to set a local override for specific fields, so that they can have a different number of max values than the global value. 


2. Constructing profiles by element.  Currently profiles are primarily built-up
by listing out required fields, than optional fields, then constraints.
Sometimes it could be usefult to build up a profile in a more element-centric
way: You could express "Here's a field to add the profile. It's required, it
has this constraint, and it has error message".  This would be very handy if a
profile is used in multiple contexts, and you need to dynamically add some
fields to it in one context. There is already a model for this,
Data::Form::Elements.  Essentially, we could just borrow the "add_element()"
method from it: 

http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm#add_element()

To me, this approach would be a more elegant way to handle per-field configurations, like the "max_values" concept. 

What do you think?

    Mark


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

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

Mark Stosberg wrote:

> I think that's right, but a patch is still needed, as the upload-related
> constraints return true/false now. Patch welcome.

patch for Data::FormValidator::Constraints::Upload is attached along with a 
patch to t/upload.t for extra tests:

-- 
Michael Peters
Plus Three, LP

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

> But isn't a FH always true and undef always false? So if it returned a FH if it 
> passed and undef if it didn't it would satisfy both right? No need to change 
> it's behavior if untainting is enabled or disabled.

I think that's right, but a patch is still needed, as the upload-related
constraints return true/false now. Patch welcome.

    Mark

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

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

Mark Stosberg wrote:
>>> I don't think file handles are untaintable. From "perlsec":
>> File handles aren't taintable to begin with, so they don't need untainting. You 
>> can't get a filehandle from an outside process. Filenames yes, filehandles no. 
>> So it should just always return the filehandle, right?
> 
> Constraints need to return true/false if constrainting is off or
> untainted-value/undef if untainting is on. This is possible to do, and
> there is a built-in method to help manage this now.
> 
> If the Upload constraint could be improved this way, then a patch is
> welcome.

But isn't a FH always true and undef always false? So if it returned a FH if it 
passed and undef if it didn't it would satisfy both right? No need to change 
it's behavior if untainting is enabled or disabled.

-- 
Michael Peters
Plus Three, LP

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

> > I don't think file handles are untaintable. From "perlsec":
> 
> File handles aren't taintable to begin with, so they don't need untainting. You 
> can't get a filehandle from an outside process. Filenames yes, filehandles no. 
> So it should just always return the filehandle, right?

Constraints need to return true/false if constrainting is off or
untainted-value/undef if untainting is on. This is possible to do, and
there is a built-in method to help manage this now.

If the Upload constraint could be improved this way, then a patch is
welcome.

> > Even then, the docs for untaint_all_constraints currently make no
> > distinction between built-in constraints and those that are not.
> 
> If we can't fix those built-in constraints to work when the user wants
> untainting then can we should be able to document which constraints
> will not work when untainting is enabled for them.

True.

    Mark

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

Re: [dfv] complicated multi-field validation

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

On Wed, 27 May 2009 12:29:10 -0400
Michael Peters <mp...@pl...> wrote:

> I have a validation need that I'd like to keep in DFV but I'm not entirely sure 
> how. I have several fields: amount1, amount2, amount3 and amount4. Each field is 
> optional but I require that at least 1 is filled. I also need to validate that 
> each one is a valid dollar amount and that each one is less than a known 
> per-field maximum value. All of that is pretty easy, but the killer is that I 
> need to also validate that the total of all of the fields is greater than some 
> known minimum.
> 
> I have a currency() routine that returns a constraint that validates that it's a 
> dollar amount and less than some max and my profile right now looks something 
> like this:
> 
> {
>    require_some => { amount => [1, 'amount1', 'amount2', 'amount3', amount4'] },
>    constraint_methods => {
>      amount1 => currency(max => 10),
>      amount2 => currency(max => 20),
>      amount3 => currency(max => 30),
>      amount4 => currency(max => 40),
>    },
> }
> 
> How can I add a constraint that makes sure the total amount is greater than my 
> $min? I tried putting a constraint_methods entry for just "amount" (since that's 
> the name of the require_some that I used) but that doesn't get called. I also 
> thought about putting an extra routine attached to amount1 but that doesn't get 
> called if amount1 is empty (which is could be since amount2 could be filled 
> instead). And I can't attach that extra method to all of the routines cause that 
> could result in multiple failures. Any thoughts?
> 
> Right now I'm leaning towards just accepting multiple failures and possibly 
> filtering them out later, but I'd like something cleaner if it exists.

What about using a little bit of pre-processing?

Create a new "total" field and add it to the query object as a
pre-calculated value. Then define a constraint on the total field. 

You could possibly define the 'total' using the 'field_filters' feature,
making the work more self-contained with a profile.

    Mark

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

[dfv] complicated multi-field validation

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

I have a validation need that I'd like to keep in DFV but I'm not entirely sure 
how. I have several fields: amount1, amount2, amount3 and amount4. Each field is 
optional but I require that at least 1 is filled. I also need to validate that 
each one is a valid dollar amount and that each one is less than a known 
per-field maximum value. All of that is pretty easy, but the killer is that I 
need to also validate that the total of all of the fields is greater than some 
known minimum.

I have a currency() routine that returns a constraint that validates that it's a 
dollar amount and less than some max and my profile right now looks something 
like this:

{
   require_some => { amount => [1, 'amount1', 'amount2', 'amount3', amount4'] },
   constraint_methods => {
     amount1 => currency(max => 10),
     amount2 => currency(max => 20),
     amount3 => currency(max => 30),
     amount4 => currency(max => 40),
   },
}

How can I add a constraint that makes sure the total amount is greater than my 
$min? I tried putting a constraint_methods entry for just "amount" (since that's 
the name of the require_some that I used) but that doesn't get called. I also 
thought about putting an extra routine attached to amount1 but that doesn't get 
called if amount1 is empty (which is could be since amount2 could be filled 
instead). And I can't attach that extra method to all of the routines cause that 
could result in multiple failures. Any thoughts?

Right now I'm leaning towards just accepting multiple failures and possibly 
filtering them out later, but I'd like something cleaner if it exists.

-- 
Michael Peters
Plus Three, LP

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

Mark Stosberg wrote:

> It should be clearer that you can't just turn it on and have complete
> untainting automatically. As your case illustrates, it behaves badly if
> you turn this one and have any constraints which don't untaint.

Shouldn't the built-in constraint of DFV all support untainting?

-- 
Michael Peters
Plus Three, LP

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

> > Constraints which don't untaint return true or false, or while ones which do
> > should return the untainted value.
> >     
> > The looks like exactly the distinction you are running into here.
> 
> That was the clue I needed to fully understand our Problem. We use 
> CGI::Application::Plugin::ValidateRM and there you can set some default 
> values for validation. And there we set "untaint_all_constraints" as an 
> default. When I disable this option everything works fine. So not using 
> this option in combination with Data::FormValidator::Constraints::Upload 
> is our way to go.

This has come up before, and I think it's an important "doc bug" that we should address,
regarding how we document "untaint_all_constraints":

http://search.cpan.org/~markstos/Data-FormValidator-4.63/lib/Data/FormValidator.pm#untaint_all_constraints

It should be clearer that you can't just turn it on and have complete
untainting automatically. As your case illustrates, it behaves badly if
you turn this one and have any constraints which don't untaint.

Alternatively, perhaps we can add code to guard against this: If this option
is enabled, and any constraint *does not* provide untainting, the system 
could die with error:

"untaint_all_constraints" used with a constraint that doesn't untaint.

...I'm not sure it's actually possible to detect that, but it would be a nice feature
in cases like yours.

    Mark

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

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

[Tim B. <ti...@he...>]

Hi,

Mark Stosberg wrote:

> Constraints which don't untaint return true or false, or while ones which do
> should return the untainted value.
>     
> The looks like exactly the distinction you are running into here.

That was the clue I needed to fully understand our Problem. We use 
CGI::Application::Plugin::ValidateRM and there you can set some default 
values for validation. And there we set "untaint_all_constraints" as an 
default. When I disable this option everything works fine. So not using 
this option in combination with Data::FormValidator::Constraints::Upload 
is our way to go.


Thanks for your help, with best regards,

Tim Bellinghausen


-- 
Tim Bellinghausen, Web-Entwicklung                Tel  +49 511 5352 796
Heise Zeitschriften Verlag GmbH & Co. KG          Fax  +49 511 5352 799
Helstorfer Str. 7, D-30625 Hannover               <mailto:ti...@he...>

Heise Zeitschriften Verlag GmbH & Co. KG
Registergericht: Amtsgericht Hannover HRA 26709

Persönlich haftende Gesellschafterin:
Heise Zeitschriften Verlag Geschäftsführung GmbH
Registergericht: Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder

Re: [dfv] Problems with Data::FormValidator::Constraints::Upload

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

On Tue, 26 May 2009 16:15:01 +0200
Tim Bellinghausen <ti...@he...> wrote:

> Hi,
> 
> after an Update from Data::FormValidator 4.40 to 4.60 we got an very odd 
> behaviour when using Data::FormValidator::Constraints::Upload. When 
> checking an uploaded file, the check always failed, if more than one 
> constraint is checked, e.g. the profile contains something like this:
> 
>      image => [
>          file_format(mime_types => [qw(image/jpeg image/png)]),
>          file_max_bytes(10 * 1024 * 1024),
>          image_min_dimensions(450,  450),
>      ],
> 
> After some analysis, I found out that, after the first check, the data, 
> returned by the results objects get_filterd_data() method, changed from 
> an FH object to 1. So after patching the valid_* methods to return $fh 
> instead of 1 if the checks succeeded everything works fine. But now I am 
> wondering, why this changes are required with our setup. We are using 
> Debian Lenny with perl 5.10.

During this transistion, did you change anything about untainting?

Constraints which don't untaint return true or false, or while ones which do
should return the untainted value.
    
The looks like exactly the distinction you are running into here.

Untainting is required to be done (I recall) through regex captures, which
don't apply to file uploads, complicating this particular case.

To further consider your patch, we also need an automated test that illustrates
something which triggers the failure. Reducing your real-world code into this
test case would likely pin-point the issue, either in your code, or in DFV.


    Mark

[dfv] Problems with Data::FormValidator::Constraints::Upload

[Tim B. <ti...@he...>]

Hi,

after an Update from Data::FormValidator 4.40 to 4.60 we got an very odd 
behaviour when using Data::FormValidator::Constraints::Upload. When 
checking an uploaded file, the check always failed, if more than one 
constraint is checked, e.g. the profile contains something like this:

     image => [
         file_format(mime_types => [qw(image/jpeg image/png)]),
         file_max_bytes(10 * 1024 * 1024),
         image_min_dimensions(450,  450),
     ],

After some analysis, I found out that, after the first check, the data, 
returned by the results objects get_filterd_data() method, changed from 
an FH object to 1. So after patching the valid_* methods to return $fh 
instead of 1 if the checks succeeded everything works fine. But now I am 
wondering, why this changes are required with our setup. We are using 
Debian Lenny with perl 5.10.

Thanks in advance,

Tim Bellinghausen


P.S.: Here is a diff of the changes I made to 
Data::FormValidator::Constraint::Upload:

--- Data/FormValidator/Constraints/Upload.pm	2008-06-20 
13:24:34.000000000 +0200
+++ Data/FormValidator/Constraints/Upload.pm	2009-05-26 
16:01:48.000000000 +0200
@@ -146,7 +146,7 @@
     $info = { %$info, mime_type => $mt, extension => ".$ext" };
     $self->meta($field,$info);

-   return _is_allowed_type($mt, $params);
+   return _is_allowed_type($mt, $params) ? $fh : undef;
  }

  ## Returns true if the passed-in mime-type matches our allowed types
@@ -176,7 +176,7 @@

  	my $q = $self->get_filtered_data;
  	my $field = $self->get_current_constraint_field;
-	my ($width,$height) = _get_img_size($self);
+	my ($width,$height, $fh) = _get_img_size($self);

  	unless ($width) {
  		warn "$0: imgsize test failed";
@@ -188,7 +188,7 @@
     $info = { %$info, width => $width, height => $height };
     $self->meta($field,$info);

-    return (($width <= $$max_width_ref) and ($height <= $$max_height_ref));
+    return (($width <= $$max_width_ref) and ($height <= 
$$max_height_ref)) ? $fh : undef;
  }

  sub valid_file_max_bytes {
@@ -223,7 +223,7 @@
     $info = { %$info, bytes => $file_size  };
     $self->meta($field,$info);

-   return ($file_size <= $max_bytes);
+   return ($file_size <= $max_bytes) ? $fh : undef;
  }

  sub valid_image_min_dimensions {
@@ -243,7 +243,7 @@

  	my $q = $self->get_filtered_data;
  	my $field = $self->get_current_constraint_field;
-	my ($width, $height) = _get_img_size($self);
+	my ($width, $height, $fh) = _get_img_size($self);

  	unless ($width) {
  		warn "image failed processing";
@@ -255,7 +255,7 @@
  	$info = { %$info, width => $width, height => $height };
  	$self->meta($field,$info);

-	return (($width >= $min_width) and ($height >= $min_height));
+	return (($width >= $min_width) and ($height >= $min_height)) ? $fh : 
undef;
  }

  sub _get_img_size
@@ -290,7 +290,7 @@
  		return undef;
  	}

-	return ($width, $height);
+	return ($width, $height, $fh);
  }

  ## fetch filehandle for use with various file type checking


-- 
Tim Bellinghausen, Web-Entwicklung                Tel  +49 511 5352 796
Heise Zeitschriften Verlag GmbH & Co. KG          Fax  +49 511 5352 799
Helstorfer Str. 7, D-30625 Hannover               <mailto:ti...@he...>

Heise Zeitschriften Verlag GmbH & Co. KG
Registergericht: Amtsgericht Hannover HRA 26709

Persönlich haftende Gesellschafterin:
Heise Zeitschriften Verlag Geschäftsführung GmbH
Registergericht: Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder

[dfv] Data::FormValidator::Constraints::Upload - CGI.pm filehandle - spaces in filenames

[Giannis E. <gec...@gm...>]

Hello...

I recently found out a problem (bug?) while using 
Data::FormValidator::Constraints::Upload.
It might also concern you or you might have a suggestion/solution for this.

For details you can have a look at this RT report:

https://rt.cpan.org/Public/Bug/Display.html?id=45233


Thank you,
Giannis

Re: [dfv] Testing if input is scalar or array

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

On Fri, 5 Dec 2008 11:08:25 -0800
Amelia Ireland <aj...@eb...> wrote:

> Hello,
> 
> Is it possible to test whether there are single or multiple input  
> values for a certain parameter using D::FV? I would like to be able to  
> specify that a certain parameter can only have one value, whereas  
> others can have multiple values, and have a test to check this.
> 
> e.g.
> 
> name =>          ## must be a single value
> phone_number =>  ## can have multiple values
> 
> I see that the input values go through an arrayify sub so that each  
> value of a param can be tested in turn, but I didn't know if there was  
> a way to work around this.
> 
> I apologize in advance if this is documented somewhere.

Amelia,

As you've likely confirmed by now, there is no built-in way to do this.
Possibilities might include:

1. pre-processing the data before it gets to data form validator
2. Using distinct field names, like "name.0", "name.1"
3. Writing a custom constraint, which possibly refers back to the raw input.

    Mark

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

Re: [dfv] problem with Data::FormValidator::Constraints::Upload

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

On Tue, 10 Mar 2009 15:48:45 +0100
Louis-David Mitterrand <vin...@ap...> wrote:

> Hi,
> 
> While trying to use Data::FormValidator::Constraints::Upload I get this
> error:
> 
> [Tue Mar 10 15:39:56 2009] Unable to load filehandle at /usr/share/perl5/Data/FormValidator/Constraints/Upload.pm line 278. [Tue Mar 10 15:39:56 2009] image failed processing at /usr/share/perl5/Data/FormValidator/Constraints/Upload.pm line 249.
> 
> FWIW, when not using the Upload.pm-specific constrainsts and rolling my
> own validation routines with Apache2::Upload $r->upload('image__path')
> all is fine.

Thaks for the report. This doesn't sound familiar.

Could you try making a unit or reduced scope test for DFV that pinpoints
the issue?

    Mark

[dfv] problem with Data::FormValidator::Constraints::Upload

[Louis-David M. <vin...@ap...>]

Hi,

While trying to use Data::FormValidator::Constraints::Upload I get this
error:

[Tue Mar 10 15:39:56 2009] Unable to load filehandle at /usr/share/perl5/Data/FormValidator/Constraints/Upload.pm line 278. [Tue Mar 10 15:39:56 2009] image failed processing at /usr/share/perl5/Data/FormValidator/Constraints/Upload.pm line 249.

FWIW, when not using the Upload.pm-specific constrainsts and rolling my
own validation routines with Apache2::Upload $r->upload('image__path')
all is fine.

Re: [dfv] proposed new filter: FV_rename

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

> > For more complex filters, just write your own.
> > 
> > =cut
> > 
> > sub FV_replace {
> >     my ($find,$replace) = @_;
> >     return sub {
> >         my $v = shift;
> >         $v =~ s/$find/$replace/;
> >         return $v;
> >     };
> > }
> 
> Hi Mark,
> 
> I assume the above snippet is in "New School" format?
> 
> In the "New School Constraints Overview" of the
> Data::FormValidator::Constraints man page your example shows:
> 
> sub coolness {
> 	...
> return sub {
> 	my $dfv = shift;
> 	... etc ...
> };
> }
> 
> So what is actually passed to the internal sub? a complex $dfv object or
> the current constraint value (as $v seems to imply)?

I see the confusion here.  Filters never got the "New School" make-over. (If
they ever do, they will be called "filter_methods".

Filters continue to take a single argument, the value to be filtered. By using a subroutine
which returns a closer, we can create a re-usable filter which takes one or more arguments. 

That's what I've done above.

I also noticed that there was a typo in my subject line. The proposed name is
"FV_replace", not "FV_rename".

Since there's been no negative feedback about the proposal, I'll plan to add it
to an official release soon.

    Mark

Re: [dfv] proposed new filter: FV_rename

[Louis-David M. <vin...@ap...>]

On Fri, Feb 13, 2009 at 02:21:22PM -0500, Mark Stosberg wrote:
> 
> For more complex filters, just write your own.
> 
> =cut
> 
> sub FV_replace {
>     my ($find,$replace) = @_;
>     return sub {
>         my $v = shift;
>         $v =~ s/$find/$replace/;
>         return $v;
>     };
> }

Hi Mark,

I assume the above snippet is in "New School" format?

In the "New School Constraints Overview" of the
Data::FormValidator::Constraints man page your example shows:

sub coolness {
	...
return sub {
	my $dfv = shift;
	... etc ...
};
}

So what is actually passed to the internal sub? a complex $dfv object or
the current constraint value (as $v seems to imply)?

Thanks,

-- 
http://www.critikart.net

[dfv] proposed new filter: FV_rename

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

I'm proposing adding the following new built-in filter to DFV. Any feedback on
this? I realize there some kind of more complex find-and-replace
cases this won't handle, but I'm OK with continuing to write my own filters for
those cases, and continuing to suggest that others do the same.

=head2 FV_replace

  use Data::FormValidator::Filters qw(FV_replace);

  field_filters => {
     first_name   => FV_replace(qr/Mark/,'Don'),
  },

FV_replace is a shorthand for writing simple find-and-replace filters.
The above filter would be translated to this:

 sub { my $v = shift; $v =~ s/Mark/Don/; $v }

For more complex filters, just write your own.

=cut

sub FV_replace {
    my ($find,$replace) = @_;
    return sub {
        my $v = shift;
        $v =~ s/$find/$replace/;
        return $v;
    };
}



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

[dfv] split out Data::FormValidator::Constraints::Dates into its own distribution?

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

I'm interested in making Data::FormValidator and it's dependencies installable
as a PurePerl system.

Currently the included "::Dates" constraint module is a problem, because it
depends on Date::Calc, which is not pure perl.

I'm considering a couple options to deal with that:

1. use an internal PurePerl code to check the date and time if Date::Calc is not
   loadable. Lyle has already prepared a patch for this that looks reasonable.

2. Remove the module from the distribution. I think it has a hard-to-solve bug
   with leapyear dates anyway, and Data::FormValidator::Constraints::DateTime is
   really a nicer alternative (and can have a PurePerl dependency chain).
   Data::FormValidator::Constraints::Dates could still be published in its own
   distribution.

3. Actually do both 1. and 2. While the ::DateTime constraint module is nice,
it does have a long dependency chain related to DateTime. It could still be
attractive to some to use the original ::Dates constraints as a self-contained
Pure Perl solution. 

There's also the matter of the ::Upload constraints, which has a dependency
on "Image::Size", which depends on Compress::Zlib, which is not Pure Perl.

For now, I'm pursuing this as an issue to be addressed by Image::Size:
https://rt.cpan.org/Ticket/Display.html?id=42930

    Mark

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

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

> 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

Data::FormValidator does not support untainting without validating, and
there is nothing magical about how untainting happens. You are
responsible for doing the untainting yourself in the routine, as
described in "perldoc perlsec". We can't provide automatic security.

> 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.

My recommendation is not to use the old "match_" and "valid_" syntax at
all, but use the newer method, described here.

http://search.cpan.org/~markstos/Data-FormValidator-4.61/lib/Data/FormValidator/Constraints.pm#New_School_Constraints_Overview

If you did untainting in your routine, use untainted_contraint_value()
as described here:

http://search.cpan.org/~markstos/Data-FormValidator-4.61/lib/Data/FormValidator/Constraints.pm#untainted_constraint_value()

I'm sorry this isn't simpler. I dream of re-writing Data::FormValidator
to rip out all the old way of doing things which only add complication
and confusion to the system at this point. 

Or, even better, I would love to mentor someone to take on this project
themselves.

Most of the code is already written for the project, it's just a matter
of removing all the crufty parts from Data::FormValidator to reveal the
code which needs to remain. :)

    Mark

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