cascade-dataform — general Data::FormValidator discussion list

[dfv] chaining constraints

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

Hi,

I have the following constraints:

	constraint_methods => {
		cruiser__email=>[
			email(),
			{
				constraint_method=>sub {
					... new school constraint ...
				}
			},
		]
	}

How can I defer the second check until the first constraint validates?

In other words if email() doesn't validate it is pointless to check the
other constraint and _also_ report that failure to the user.

Thanks,

Re: [dfv] Data::Formvalidator and JQuery validation

[Lyle <web...@co...>]

Mark Stosberg wrote:
>>> Let's see if I can make a starter list of the changes I'd make:
>>>
>>> - Only constraint_methods, no more "constraints" (and perhaps
>>>   constraint_methods would be renamed to be just "constraints")
>>>         
>> I'd say just constraints.
>>     
>
> I agree the shorter name is nicer. Maybe "constraint_methods" could also
> be accepted to make transitioning code either.
>   

Maybe, but isn't that a bit like starting with legacy stuff we are 
trying to avoid?

>>> - Only one way to specify constraints... perhpas a coderef. Note the
>>>   three options we have now: string, hashref and coderef
>>>         
>> How can the coderef approach be used in a way that he profile can be 
>> exported with the constraint method name intact? Or is there a 
>> completely different way of addressing the problem?
>>     
>
> I think there's a different way of addressing the problem. I think it's
> like the case when a subroutine call appears in Template Toolkit or
> HTML::Template::Plugin::Dot. It may look like a subroutine call:
>
>  FV_max_length(20)
>
> But it's treated as a string. So, you could put something like that in a
> profile, and it could be translated into a coderef when it goes into a
> Perl profile, and it could be translated into a JavaScript data
> structure (maybe an anonymous sub) when it goes into a JS profile.
>   

So maybe what I should really look at creating is DFV::SimpleProfile 
with DFV::SimpleProfile::Perl & DFV::SimpleProfile::JQuery?

>>> - Far fewer constraints and filters should ship by default, especially
>>>   some of the poor ones would be removed (Look the TODO failures in the
>>>   test suite to find some poor ones that can't be fixed without 
>>> breaking
>>>   backcompat)
>>>         
>> JS's understanding of Regex is more limited. How would this be 
>> addressed? Maybe JS compatible constraints could be flagged or kept 
>> separate?
>>     
>
> Perhaps we could use the same strategy of a simple profile format that
> can translated into both Perl and JS. JS could implement the solutions
> differently if necessary.
>   

Hmmm... I'd have to have another look at the DFV constraints to have a 
good idea of this. As I understand it, a lot of constraints boil down to 
a regexp.

>>> - Was the 'meta' system really a good idea?
>>>         
>> Was this my proposal? Is there a better solution?
>>     
>
> No, this was I design piece that I contributed to DFV myself. The
> thinking was that sometimes you do expensive operations as part
> validation, and you may be discover something interesting as part of
> that expensive operation. The "meta" system allows constraints to store
> this "metadata" and then you can retrieve it later when you are
> inspecting the validation results. It's a kind of communication through
> side effects. It works, but the logic flow can be hard to follow, much
> like when a global variable is used.
>   

I'll leave that one with you.

>>> - Design Goal: it could be a reasonably easy to have a validation
>>> profile that can be re-used in jQuery. Perhaps this module would
>>> have a method to emit a version of the profile that can be used by
>>> Data.FormValidator (the JavaScript module).  Data.FormValidator may
>>> need a rewrite in the process.         
>> I spent quite a lot of time on Data.FormValidator. It's large, changes
>> to DFV will always need changes in this as well. Clearly a lot of
>> effort went into it, but it's become quite dated. With all the new JS
>> frameworks doing great things with validation I don't think creating
>> or updating a large validation library like this is the way forward.
>> JQuery has several validation plugins. I was thinking some way of
>> linking DFV style constraints with the popular JQuery ones.
>> DFV::JQuery::Plugin_name. The Plugin_name could list constraint
>> methods that are available in both profiles.
>>     
>
> I haven't looked at Data.FormValidator recently, but I agree jQuery is
> very nice. The idea of using an intermediate format would be compatible
> with implementing a solution in jQuery which can make use of the format.
>   

Intermediate format would seem the way forward.

So, what the issue really seems to be with is the make up of the 
validation profile itself. Maybe we should flip my earlier example over 
and start a new namespace:-

Something::Profile
Something::Profile::DFV
Something::Profile::JQuery

A new intermediate profile format designed from the outset to be easily 
exported to the more established validation frameworks, such as DFV and 
JQuery... This gives us a nice new consistent interface, and hides all 
the DFV legacy behind it.

Sounds very good to me :)


Lyle

Re: [dfv] Data::Formvalidator and JQuery validation

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

> > Let's see if I can make a starter list of the changes I'd make:
> >
> > - Only constraint_methods, no more "constraints" (and perhaps
> >   constraint_methods would be renamed to be just "constraints")
> >   
> 
> I'd say just constraints.

I agree the shorter name is nicer. Maybe "constraint_methods" could also
be accepted to make transitioning code either.

> > - Only one way to specify constraints... perhpas a coderef. Note the
> >   three options we have now: string, hashref and coderef
> >   
> 
> How can the coderef approach be used in a way that he profile can be 
> exported with the constraint method name intact? Or is there a 
> completely different way of addressing the problem?

I think there's a different way of addressing the problem. I think it's
like the case when a subroutine call appears in Template Toolkit or
HTML::Template::Plugin::Dot. It may look like a subroutine call:

 FV_max_length(20)

But it's treated as a string. So, you could put something like that in a
profile, and it could be translated into a coderef when it goes into a
Perl profile, and it could be translated into a JavaScript data
structure (maybe an anonymous sub) when it goes into a JS profile.

> > - The 'msgs' system needs a from-scratch re-think and rewrite.
> >   Perhaps we should only support the callback interface and
> >   leave it other related modules to handle the rest.
> >
> >   I think I want to allow message strings to be in the code, but I want
> >   to make it easy for them to be in a config file or template instead.
> >   
> 
> I think this should be simple strings per field/constraint that can be 
> easily localized.

Ok.

> > - Far fewer constraints and filters should ship by default, especially
> >   some of the poor ones would be removed (Look the TODO failures in the
> >   test suite to find some poor ones that can't be fixed without breaking
> >   backcompat)
> >   
> 
> JS's understanding of Regex is more limited. How would this be 
> addressed? Maybe JS compatible constraints could be flagged or kept 
> separate?

Perhaps we could use the same strategy of a simple profile format that
can translated into both Perl and JS. JS could implement the solutions
differently if necessary.

> > - Was the 'meta' system really a good idea?
> >   
> 
> Was this my proposal? Is there a better solution?

No, this was I design piece that I contributed to DFV myself. The
thinking was that sometimes you do expensive operations as part
validation, and you may be discover something interesting as part of
that expensive operation. The "meta" system allows constraints to store
this "metadata" and then you can retrieve it later when you are
inspecting the validation results. It's a kind of communication through
side effects. It works, but the logic flow can be hard to follow, much
like when a global variable is used.

> > - Design Goal: it could be a reasonably easy to have a validation
> > profile that can be re-used in jQuery. Perhaps this module would
> > have a method to emit a version of the profile that can be used by
> > Data.FormValidator (the JavaScript module).  Data.FormValidator may
> > need a rewrite in the process. 
> >   
> 
> I spent quite a lot of time on Data.FormValidator. It's large, changes
> to DFV will always need changes in this as well. Clearly a lot of
> effort went into it, but it's become quite dated. With all the new JS
> frameworks doing great things with validation I don't think creating
> or updating a large validation library like this is the way forward.
> JQuery has several validation plugins. I was thinking some way of
> linking DFV style constraints with the popular JQuery ones.
> DFV::JQuery::Plugin_name. The Plugin_name could list constraint
> methods that are available in both profiles.

I haven't looked at Data.FormValidator recently, but I agree jQuery is
very nice. The idea of using an intermediate format would be compatible
with implementing a solution in jQuery which can make use of the format.

> > But with all that said, I think I do want something that is easy to
> > transistion to for people who have been using DFV for years.
> 
> If it's largely based on the newer DFV methods, then shouldn't
> transition be easy for those who've kept up with DFV. For those that
> haven't, I'm guessing that they're happy with the old system.

I think it's true that a lot of people already avoid using the parts of
DFV that I would recommend removing or changing. 

> > So, the ease of transition from DFV is also a goal. So, in some
> > cases that could mean keeping some details the same because they are
> > "good enough... and compatible" rather than "the best".
> 
> Should the aim really be to create something that is "good enough"?
> Isn't that what we already have?

I didn't frame that very well. :) What I meant was that I recognize the
goal is to balance several sometimes contradictary goals, such as the
"the best interface" and "compatibility".

> > The first pass can be to design the new module in POD, have that
> > peer-reviewed, and then create it as a second step. 
> 
> Sounds good :)

    Mark

-- 
http://mark.stosberg.com/

Re: [dfv] Data::Formvalidator and JQuery validation

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

> In one project, I had to graft DFV output into other code, so I user
> regexps to manipulate DFV's msgs. Utter madness of course. Perhaps I did
> things wrongly, but it sure convinced me of the one-module-per-task
> approach.

The current system would allow you do something rather custom with
"msgs" by using the msgs callback. If that was the only option, it
would have clearer that it was the thing to use. :)

   Mark

Re: [dfv] Data::Formvalidator and JQuery validation

[Lyle <web...@co...>]

Mark Stosberg wrote:
> Let's see if I can make a starter list of the changes I'd make:
>
> - Only constraint_methods, no more "constraints" (and perhaps
>   constraint_methods would be renamed to be just "constraints")
>   

I'd say just constraints.

> - Only one way to specify constraints... perhpas a coderef. Note the
>   three options we have now: string, hashref and coderef
>   

How can the coderef approach be used in a way that he profile can be 
exported with the constraint method name intact? Or is there a 
completely different way of addressing the problem?

> - The 'msgs' system needs a from-scratch re-think and rewrite.
>   Perhaps we should only support the callback interface and
>   leave it other related modules to handle the rest.
>
>   I think I want to allow message strings to be in the code, but I want
>   to make it easy for them to be in a config file or template instead.
>   

I think this should be simple strings per field/constraint that can be 
easily localized.

> - Far fewer constraints and filters should ship by default, especially
>   some of the poor ones would be removed (Look the TODO failures in the
>   test suite to find some poor ones that can't be fixed without breaking
>   backcompat)
>   

JS's understanding of Regex is more limited. How would this be 
addressed? Maybe JS compatible constraints could be flagged or kept 
separate?

> - Was the 'meta' system really a good idea?
>   

Was this my proposal? Is there a better solution?

> - Design Goal: it could be a reasonably easy to have a validation
>   profile that can be re-used in jQuery. Perhaps this module
>   would have a method to emit a version of the profile that 
>   can be used by Data.FormValidator (the JavaScript module).
>   Data.FormValidator may need a rewrite in the process. 
>   

I spent quite a lot of time on Data.FormValidator. It's large, changes 
to DFV will always need changes in this as well. Clearly a lot of effort 
went into it, but it's become quite dated. With all the new JS 
frameworks doing great things with validation I don't think creating or 
updating a large validation library like this is the way forward.
JQuery has several validation plugins. I was thinking some way of 
linking DFV style constraints with the popular JQuery ones. 
DFV::JQuery::Plugin_name. The Plugin_name could list constraint methods 
that are available in both profiles.

> But with all that said, I think I do want something that is easy
> to transistion to for people who have been using DFV for years.
>   

If it's largely based on the newer DFV methods, then shouldn't 
transition be easy for those who've kept up with DFV. For those that 
haven't, I'm guessing that they're happy with the old system.

> So, the ease of transition from DFV is also a goal. So, in
> some cases that could mean keeping some details the same because
> they are "good enough... and compatible" rather than "the best".
>   

Should the aim really be to create something that is "good enough"? 
Isn't that what we already have?

> The first pass can be to design the new module in POD, have that
> peer-reviewed, and then create it as a second step. 
>   

Sounds good :)


Lyle

Re: [dfv] Data::Formvalidator and JQuery validation

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

> > ( One day I'd like to make a lighter, simpler version of DFV that
> > removes all the extra ways to do the same thing! )
> 
> Let's do it! :) DFV has a lot of legacy and bloat now. I found it was a 
> pretty steep learning curve the first time is used it (although I had a 
> LOT of input to validate). I'm sure with all your experience with it you 
> have a fairly good idea in your head of how it should be. If a 
> 'framework' for it could be thrashed out on this list, I'd be happy to 
> work on it with you. After all, it's something I'm working on right now 
> for my software. The priorities I see are:-
> 
> Pure Perl option
> Light weight
> Easy to extend
> Easy integration with modern client side JS libraries

Let's see if I can make a starter list of the changes I'd make:

- Only constraint_methods, no more "constraints" (and perhaps
  constraint_methods would be renamed to be just "constraints")

- Only one way to specify constraints... perhpas a coderef. Note the
  three options we have now: string, hashref and coderef

- "missing_optional_valid" would always be on.

- There would be no tainting options. It would either be on all the
  time, or we wouldn't do it at all. 

- Drop the old "validate()" interface

- "validator_packages" would be eliminated

- The 'msgs' system needs a from-scratch re-think and rewrite.
  Perhaps we should only support the callback interface and
  leave it other related modules to handle the rest.

  I think I want to allow message strings to be in the code, but I want
  to make it easy for them to be in a config file or template instead.

- ConstraintsFactory would be eliminated
  - (Should we bundle Data-FormValidator-Constraints-MethodsFactory
    instead? )

- Far fewer constraints and filters should ship by default, especially
  some of the poor ones would be removed (Look the TODO failures in the
  test suite to find some poor ones that can't be fixed without breaking
  backcompat)

- Consider keeping the FV_ prefix going forward.

- Was the 'meta' system really a good idea?

- Any "missing" features that we want to add?

- Consider addressing any bug reports with the new
  rewrite:
  https://rt.cpan.org/Public/Dist/Display.html?Name=Data-FormValidator

- Design Goal: it could be a reasonably easy to have a validation
  profile that can be re-used in jQuery. Perhaps this module
  would have a method to emit a version of the profile that 
  can be used by Data.FormValidator (the JavaScript module).
  Data.FormValidator may need a rewrite in the process. 

But with all that said, I think I do want something that is easy
to transistion to for people who have been using DFV for years.

So, the ease of transition from DFV is also a goal. So, in
some cases that could mean keeping some details the same because
they are "good enough... and compatible" rather than "the best".

That still leaves plently rarely used, unimportant, or bad-idea features
that can be eliminated.

The first pass can be to design the new module in POD, have that
peer-reviewed, and then create it as a second step. 

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

Re: [dfv] Data::Formvalidator and JQuery validation

[Cees H. <ce...@gm...>]

On Fri, Mar 19, 2010 at 9:30 AM, Ron Savage <ro...@sa...> wrote:
> Hi Lyle
>
> On Thu, 2010-03-18 at 15:59 +0000, Lyle wrote:
>> Ideally I don't want to JS validation to result in a server request. I
>> want it all client side so that the server only get's a request if it's
>> all valid or JS is turned off.
>
> This doesn't make any sense. You /always/ need server-side validation.
>
> For instance, a hacker can download your page, delete the Javascript
> validation, and submit any data whatsoever.
>
> The client-side validation is purely to give the user quick feedback.

Hi Ron,

I don't think that is what he meant.  Ideally you want the JavaScript
to be able to handle most if not all of the validation on the client
side so that no requests need to be made to the server until the form
is correctly filled in.  At this point it is submitted to the server
where the normal server side validation is run to ensure no fowl play
is occurring.

if your JavaScript still makes calls back to the server to do
validation then it kind of defeats the purpose of client side
validation.

However, there are some instances where only server side validation
will do (for example seeing if a nickname is already in use).  These
types of validation can be done with an ajax call to the server to
give quick feedback.

But as you said, when the form is submitted you still always recheck
every field on the server as you can't trust what is sent from the
client.

Cheers,

Cees

Re: [dfv] Data::Formvalidator and JQuery validation

[Lyle <web...@co...>]

Ron Savage wrote:
> Hi Lyle
>
> On Thu, 2010-03-18 at 15:59 +0000, Lyle wrote:
>   
>> Ideally I don't want to JS validation to result in a server request. I 
>> want it all client side so that the server only get's a request if it's 
>> all valid or JS is turned off.
>>     
>
> This doesn't make any sense. You /always/ need server-side validation.
>   

??? Obviously.

> For instance, a hacker can download your page, delete the Javascript
> validation, and submit any data whatsoever.
>
> The client-side validation is purely to give the user quick feedback.
>   

No, client side is to produce less calls the server.

User input -> to server -> invalid -> update input -> to server -> 
invalid -> etc... -> to server -> valid.

This can be a lot of needless server calls. With good JS validation all 
or most of those invalid input server calls can be avoided. Obviously 
the server needs to do validation when the input comes in, that goes 
without saying. But these days JS is pretty good, the more you can get 
the client side doing, then less load on your server.

>> Let's do it! :) DFV has a lot of legacy and bloat now. I found it was a 
>> pretty steep learning curve the first time is used it (although I had a 
>> LOT of input to validate). I'm sure with all your experience with it you 
>> have a fairly good idea in your head of how it should be. If a 
>> 'framework' for it could be thrashed out on this list, I'd be happy to 
>> work on it with you. After all, it's something I'm working on right now 
>> for my software. The priorities I see are:-
>>     
>
> Data::Verifier has a much simpler interface, but requires Moose.
>
> Also, it does not offer any Javascript features.
>
> So, if you wish to invent another wheel, Data::Verifier is the type of
> interface to aim for.
>   

Looks interesting, but a Moose dependency seems a bit much when I'm 
trying to ship the dependency tree.

>> Pure Perl option
>> Light weight
>> Easy to extend
>> Easy integration with modern client side JS libraries
>>     
>
> Yes, that'd be nice.
>   

I won't settle for anything less. TBH I'm quite shocked it's not already 
out there...


Lyle

Re: [dfv] Data::Formvalidator and JQuery validation

[Lyle <web...@co...>]

Mark Stosberg wrote:
> I think having a profile that can be used on both the client and server
> sides is great, and is a goal I have pursued before myself. As a result, 
> I wrote this piece of glue a few years ago:
>
> http://search.cpan.org/~markstos/Data-FormValidator-ErrMsgs-JavaScript-1.00/lib/Data/FormValidator/ErrMsgs/JavaScript.pm

Ideally I don't want to JS validation to result in a server request. I 
want it all client side so that the server only get's a request if it's 
all valid or JS is turned off.

>> Since DFV change to use subrefs and closures it wasn't 
>> possible to get the DFV schema from the Perl profile.
>
> The old DFV interface made this easier...

I Really don't want to use any old, legacy or deprecated interfaces. I 
want this to be something that work with the newest/best way of doing 
things.

> Is it just coincidental that your result looks like the hashref
> interface that's also present for constraints?

Yes, but I see the similarity. The new system is better, except that it 
looses the markers like these, that allowed you to know exactly what 
constraint the profile pointed to.
.
> ( One day I'd like to make a lighter, simpler version of DFV that
> removes all the extra ways to do the same thing! )

Let's do it! :) DFV has a lot of legacy and bloat now. I found it was a 
pretty steep learning curve the first time is used it (although I had a 
LOT of input to validate). I'm sure with all your experience with it you 
have a fairly good idea in your head of how it should be. If a 
'framework' for it could be thrashed out on this list, I'd be happy to 
work on it with you. After all, it's something I'm working on right now 
for my software. The priorities I see are:-

Pure Perl option
Light weight
Easy to extend
Easy integration with modern client side JS libraries

Such that it would be easy for people to write extension for JS 
libraries like JQuery.

Validation Profile -> Perl server side validation
                   -> JQuery extension -> Client side validation
                   -> JS library extension -> Client side validation

Rather than try to export the profile as JSON and re-create DFV in JS as 
was done before. Simply have Perl libraries that directly generate all 
the JS code.

>> Thoughts on this please? I can't see any reasons against this or 
>> something similar...
>
> Perhaps Data::Form::Elements would help here... it's an alternate
> interface to DFV:
>
> http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm

Possibly... But it looks like it'll be limited with the kind of stuff 
I'm trying to achieve.


Lyle

Re: [dfv] Data::Formvalidator and JQuery validation

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

On Wed, 17 Mar 2010 23:22:21 +0000
Lyle <web...@co...> wrote:

> Hi All,
>   I had a little time last week to work on my cgiapp/DFV project. One 
> thing I did last time around was combine the server side and client side 
> validation.

I think having a profile that can be used on both the client and server
sides is great, and is a goal I have pursued before myself. As a result, 
I wrote this piece of glue a few years ago:

http://search.cpan.org/~markstos/Data-FormValidator-ErrMsgs-JavaScript-1.00/lib/Data/FormValidator/ErrMsgs/JavaScript.pm

> Since DFV change to use subrefs and closures it wasn't 
> possible to get the DFV schema from the Perl profile.

The old DFV interface made this easier, but had other drawbacks:

constraints => {
    email => 'email'
},

The interface still exists if you want to use it, although it's more
painful and awkward to write custom constraints with it. 

>   I'm hoping I can convince you all to add 'markers' or 'attributes' to 
> the code refs so that we can see what they are. I think this will be a 
> useful feature, not only for this scenario, but open the door for other 
> attributes and features.
> 
> would instead become something like:
> constraint_methods => {
>             email => {
>                        name => 'email',
>                        sub => CODEREF,
>             }
>         }
> 
> (My naming of attributes is likely far from idea, but you get the picture)

Is it just coincidental that your result looks like the hashref
interface that's also present for constraints?

http://search.cpan.org/~markstos/Data-FormValidator-4.66/lib/Data/FormValidator.pm#hashref_style_of_specifying_constraints

That's another older technique that has been de-emphasized because it
re-invents parameter passing in awkward way. It's also still there if
you want to use it.

( One day I'd like to make a lighter, simpler version of DFV that
removes all the extra ways to do the same thing! )

> Thoughts on this please? I can't see any reasons against this or 
> something similar...

Perhaps Data::Form::Elements would help here... it's an alternate
interface to DFV:

http://search.cpan.org/dist/Data-Form-Elements/lib/Data/Form/Elements.pm

I've also bookmarked various related modules which may be of interest,
but I don't think will directly apply to your question:

    http://delicious.com/markjugg/Data::FormValidator

    Mark

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

[dfv] Data::Formvalidator and JQuery validation

[Lyle <web...@co...>]

Hi All,
  I had a little time last week to work on my cgiapp/DFV project. One 
thing I did last time around was combine the server side and client side 
validation. Since DFV change to use subrefs and closures it wasn't 
possible to get the DFV schema from the Perl profile. I ended up 
creating an interim schema which was used to generate both the Perl and 
JS profile, but obviously this wasn't ideal.
  I'm hoping I can convince you all to add 'markers' or 'attributes' to 
the code refs so that we can see what they are. I think this will be a 
useful feature, not only for this scenario, but open the door for other 
attributes and features.

For example:
constraint_methods => {
            email => email(),
        }

which becomes:
constraint_methods => {
            email => CODEREF,
        }

would instead become something like:
constraint_methods => {
            email => {
                       name => 'email',
                       sub => CODEREF,
            }
        }

(My naming of attributes is likely far from idea, but you get the picture)

Thoughts on this please? I can't see any reasons against this or 
something similar...


Lyle

[dfv] Question on required_regexp and optional_regexp

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

Hello,

I am not sure whether it is me who do not grasp the concept of: required_regexp and optional_regexp

I expect that I can provide a pattern of parameters I would like to be mandatory using. Please see my example:

---
#!/usr/bin/perl -w

use strict;
use Data::Dumper;
use Data::FormValidator;
use Test::More qw(no_plan);

my $dfv = Data::FormValidator->new();

my $dfv_profile = {
   required_regexp => qr/(algorithm|digest_type|digest|keytag)1/,
};

my $results = $dfv->check({ digest1 => 'test' }, $dfv_profile);

ok($results->has_missing);

print STDERR Dumper $results;
---

My problem is that has_missing is false.

I have been going over the Data::FormValidator::Results code and I ended up in this section - I was tempted to write a patch, but I just want to verify that I understood the concept.

--
   my $required_re = _create_sub_from_RE($profile->{required_regexp});
   my $optional_re = _create_sub_from_RE($profile->{optional_regexp});

   for my $k (keys %valid) {
      if ($required_re && $required_re->($k)) {
         $required{$k} =  1;
      }

      if ($optional_re && $optional_re->($k)) {
         $optional{$k} =  1;
      }
   }
--

I do not understand why it iterates over valid since unspecified parameters are not evaluated?

Thanks,

jonasbn
--
AIM: BjonasN      Gtalk: jo...@gm...
ICQ: 62401545   MSN: jo...@io...
twitter: jonasbn   blog: http://e-diot.dk/

Re: [dfv] New Data::FormValidator release, 5 more bugs to address

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

On Tue, 05 Jan 2010 09:44:17 -0500
David Kaufman <da...@gi...> wrote:

> Hi Mark,
> 
> Mark Stosberg wrote:
> > 
> > Hello, 
> > 
> > Yesterday I uploaded a new Data::FormValidator release with several updates. 
> 
> Thanks!
> 
> > However, there are still 5 more open bugs in the bug tracker I would like help addressing:
> > http://bit.ly/82IUic
> 
> Hmm, that link doesn't seem to work unless I'm logged in, or have a 
> cookie, or something.  Do I need to register?  I'd like to help.

Thanks, Dave.

You can also start from the main report:
http://rt.cpan.org/Public/Dist/Display.html?Name=Data-FormValidator

It's the open non-wishlist items that we are targeting. (Although feel
free to also look at the wishlist items if you'd like). 

Since I posted there is also a new issue related to "bleadperl" that I
haven't looked at yet.

    Thanks again. 

   Mark

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

Re: [dfv] New Data::FormValidator release, 5 more bugs to address

[David K. <da...@gi...>]

Hi Mark,

Mark Stosberg wrote:
> 
> Hello, 
> 
> Yesterday I uploaded a new Data::FormValidator release with several updates. 

Thanks!

> However, there are still 5 more open bugs in the bug tracker I would like help addressing:
> http://bit.ly/82IUic

Hmm, that link doesn't seem to work unless I'm logged in, or have a 
cookie, or something.  Do I need to register?  I'd like to help.

Thanks,

-dave

[dfv] New Data::FormValidator release, 5 more bugs to address

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

Hello, 

Yesterday I uploaded a new Data::FormValidator release with several updates. Thanks to all those
who contributed updates to it:

http://search.cpan.org/src/MARKSTOS/Data-FormValidator-4.65/Changes
http://search.cpan.org/~markstos/Data-FormValidator-4.65/

However, there are still 5 more open bugs in the bug tracker I would like help addressing:

http://bit.ly/82IUic

If you would like to help work on one, please just leave a comment in the ticket that you are "taking" the ticket. 
If you develop a patch to contribute, you can attach it in "diff -u" format to the ticket. 

(Or if you are inclined, you can check out the darcs archive here and use "darcs send" to submit a patch)
darcs get http://mark.stosberg.com/darcs_hive/dfv/  )

Anyone contributing a fix will get a mention in the "Changes" file in the next release.

If you would like, I can also add anyone who would like as a "CC" on the bug tracker, so you would be notified as
new bugs are filed, and you would potentially help to triage and fix bugs as they come in. Usually this has been just a few per
year, but with the other modules I maintain I haven't always been getting to these promptly. 

The bug you fix may be your own!

Thanks for your help!

    Mark
-- 
http://mark.stosberg.com/

Re: [dfv] DateTime string output?

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

On 11/17/2009 01:29 PM, Louis-David Mitterrand wrote:

> I need a format that postgresql will understand (without having to
> modify the 'datestyle' parameter in postgresql.conf) as as INSERT that
> date into a timestamp.

This is pretty typical. Most applications need to convert dates from 
human formats to machine formats. The key is to realize that you need to 
separate out the validation from the DB specific format. Validation 
should be about validating their format and then keeping it in a neutral 
form (like a DateTime object) that can be used in lots of other places.

> So for now I added 'to_pg_datetime' as second 'contraint_method' after
> the actual one (say, before_today).
>
> Is it the proper way to do it?

No, that's trying to conflate the 2 (IMO) distinct steps. Data 
validation, and data formatting for your database.

> OK, but how can I change the default output format from within the
> 'contraint_method=>before_today(%d/%m/%Y)' declaration?

Why do you need to do it at your data validation step? Just explicitly 
convert it into the Pg format for your query:

   my $date = $dfv_results->valid('my_date');
   ...
   $db_sth->execute(DateTime::Format::Pg->format_datetime($pg));

-- 
Michael Peters
Plus Three, LP

Re: [dfv] DateTime string output?

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

On 11/17/2009 09:42 AM, Louis-David Mitterrand wrote:

> For example if I use:
>
> 	my_constraint =>  after_today('%d/%m/%Y') ## notice: day _before_ month here
>
> then my DateTime object will be stringified as %d/%m/%Y. Is that the
> expected behavior?

Yes, this is the correct behavior.

> How can select a different output than the input format?

First off, why do you need a different stringification format? The only 
reason you should really be stringifying these is for debugging. If your 
code expects something in a particular format you should be explicitly 
setting that format.

But yes, DateTime objects all you to change their default format. See 
http://search.cpan.org/~drolsky/DateTime-0.51/lib/DateTime.pm#Formatters_And_Stringification

-- 
Michael Peters
Plus Three, LP

[dfv] DateTime string output?

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

Hi,

When using Data::FormValidator::Constraints::DateTime in untaint mode
DateTime objects are output. But I noticed these objects are stringified
in the same way as the supplied format passed to the contraint method.

For example if I use:

	my_constraint => after_today('%d/%m/%Y') ## notice: day _before_ month here

then my DateTime object will be stringified as %d/%m/%Y. Is that the
expected behavior? 

How can select a different output than the input format?

[dfv] Support for custom messages in named constraints

[Bruno D. B. de S. <he...@ar...>]

Hi Mark

I  submitted a Whislist bug for Data::FormValidator to support custom 
error messages using named constraints in the validation profile.
In the manual there is a reference to using named constraints to change 
the message shown to the user if the validation fail, but the built-in 
constraints ignores this configuration.

See the profile below:

sub _my_profile {
    my ($self) = @_;

    return {
        required => [qw(
            username
            password
        )],
    
        constraint_methods => {
                name => 'my_custom_length_between_message',
                constraint_method => FV_length_between(6, 10)
            },
            password => FV_length_between(8, 40),
        },
        msgs => {
            constraints => {
                my_custom_length_between_message    => 'Username must be 
between 6 an 10 digits',
                length_between            => 'Please check the length of 
your input',
            },
        },
    };
}

In the username it will show the my_custom_length_between_message as it 
is named, and in the case it isn't named, it will use the default 
constraint name.

I came to two possible solutions to the problem.

First solution:

Change the "set_current_constraint_name" and "name_this" functions in 
Data/FormValidator/Results.pm to:

sub set_current_constraint_name {
        my $self = shift;
        my $value = shift;
        $self->{__CURRENT_CONSTRAINT_NAME} = $value unless 
$self->{__CURRENT_CONSTRAINT_NAME};
}

sub name_this {
        my $self = shift;
        my $value = shift;
        $self->{__CURRENT_CONSTRAINT_NAME} = $value unless 
$self->{__CURRENT_CONSTRAINT_NAME};
}


Second solution:

Change all call's to "set_current_constraint_name" and "name_this" in 
the built-in constraints.

For example:

sub FV_max_length {
    my ($max) = @_;
    croak "max is required" unless defined $max;
    return sub {
        my ($dfv,$value) = @_;
        $dfv->name_this('max_length');
        return undef if ( length($value) > $max );
        # Use a regexp to untaint
        $value=~/(.*)/;
        return $dfv->untainted_constraint_value($1);
    }
}

sub FV_max_length {
    my ($max) = @_;
    croak "max is required" unless defined $max;
    return sub {
        my ($dfv,$value) = @_;
        $dfv->name_this('max_length')  unless 
$dfv->get_current_constraint_name();
        return undef if ( length($value) > $max );
        # Use a regexp to untaint
        $value=~/(.*)/;
        return $dfv->untainted_constraint_value($1);
    }
}

I tested both solutions here and they seem to work without problems.

[dfv] Trouble using HTML::Mason in CGI::Application

[Chris C. <cgi...@li...>]

I would like to use HTML::Mason as the templating system for CGI::Application as it so much "richer" than any other templating module, but it is giving me a hard time.

What I would like is this:

1) in the startup runmode (called: start): display a complete form (made up of Mason components)
2) in the next runmode (called: show_submit): check the form fields using the ValidateRM plugin method: check_rm
3) if an constraint as defined in the profile for the form is violated, I would like the form to be redisplayed, this time making clear which constraint(s) for which form field(s) failed

This is what I have tried: 

sub setup
{
  my $self = shift;
  $self->start_mode('start');
  $self->mode_param('rm');
  $self->run_modes( 'start'       => 'start',
                    'show_submit' => 'show_submit',);

}

sub start
{
  my $self = shift;

  $self->stash->{template} = '/match_admin_main.html'; # This file consists of a couple of Mason components.
  return $self->interp_exec(entity => "opleiding");    # This shows my form just fine!
}


sub show_submit
{
  my $self = shift;
  my $errs = shift;
  my $q    = $self->query;

  my ($err_page,$results);

  ($results,$err_page) = $self->check_rm('start','_maintain_language_valprof');
  return $err_page if ($err_page);

This fails to reload the form completely, stating as the reason in the webserver logfile: Premature end of script headers.
This puzzles me because starting off in runmode: start works very well!

Reading through the documentation of CGI::Application::Plugin::Mason I came across the: html_tmpl_class method, which I've used to set it to 'HTML::Mason' but this only results in an error indication that method: new cannot be found using the HTML::Mason package.

Can this puzzle be solved? What do I need to do in order to be able to create an application that works along the lines as described at the top?

Thanks you for any advice that helps out,

Chris


_________________________________________________________________
What can you do with the new Windows Live? Find out
http://www.microsoft.com/windows/windowslive/default.aspx

[dfv] msgs format issue

[Mike.G <hy...@gm...>]

Hi, I got one issue on msgs method.
when I want to change the default invalid error messages.

my code like this:

1 package InMarry::Action::User::Register;
   2 use strict;
   3 use warnings;
   4 use base qw/InMarry/;
   5 use Data::FormValidator::Constraints qw(email FV_min_length);
   6
   8 sub register:Default {
   9     my $this = shift;
  10
  11
  14     if ( $this->session->param('username') ) {
  16         $this->redirect('index.html');
  17     };
  18
  20     return $this->tt_process('register.tt2');
  21 }
  22
  24 sub register_submit:Path('submit') {
  25     my $this = shift;
  26     my $check_form_result = $this->check_rm('_register_form_validate',
  27         '_register_form_profile', { fill_password=>0}) ||
  28     return $this->check_rm_error_page;
  29
  30
  31 }
  34 sub _register_form_validate {
  35     my $this = shift;
  36     my $errs = shift;
  37
  38     return $this->tt_process('register.tt2', $errs);
  39 }
  40
  41
  43 sub _register_form_profile {
  44     return {
  45         required=>[
  46             qw/user_email
  47             user_password
  48             user_name/
  49         ],
  50
  51         constraint_methods=>{
  52             user_email=>email(),
  53             user_password=>{
  54                 name=>'user_password_min_length',
  55                 constraint_method=>FV_min_length(8)
  56             },
  57         },
  58
  59         msgs=> {
  60             constraints=>{
  61                 email=>'email is not valid',
  62                 'user_password_min_length'=>'can't be less than 8
characters',
  64             },
  65         },
  66
  67
  68     };
  69 }
  70
  71
  72 1;

when I input a less than 8 character password,  it the error message always
is default message content, not my define on line 62.

why?

and the other question: how to custom special field message content and
format?


thanks

Mike.G

Re: [dfv] Nullify Filter

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

On Thu, 9 Jul 2009 09:45:09 -0500
fREW Schmidt <fr...@gm...> wrote:

> Hello all,
> 
> I would like to created a filter that would convert '' to undef.  I thought
> I had but it doesn't seem to be working.  The following is my filter, let me
> know if you see what's wrong or why I can't do this:

Looks reasonable to me.

Is filter_nullify actually being called? It looks reasonable to me. 
If you add a "warn" in filter_trim(), is it actually get called?

You could install Devel::Trace and use this:

perl -d:Trace your_script.pl

And you'd get a printout of the everything called in the course of the
run. That could help pinpoint where it quit working as expected for you.

    Mark

[dfv] Nullify Filter

[fREW S. <fr...@gm...>]

Hello all,

I would like to created a filter that would convert '' to undef.  I thought
I had but it doesn't seem to be working.  The following is my filter, let me
know if you see what's wrong or why I can't do this:

package Data::FormValidator::Filters::Nullify;

use strict;
use warnings;

use vars qw($VERSION @EXPORT_OK );

BEGIN {
   require Exporter;
   $VERSION = '0.01';
   use base 'Exporter';
   @EXPORT_OK = qw( filter_nullify );
}

sub filter_nullify {
   my $value = shift;
   if ( $value eq '' ) {
      return undef;
   } else {
      return $value;
   }
}

1;

And in action:

   profile => {
      constraint_methods => {
     fixture_amount   => FV_num_int(),
     fixture_id       => FV_num_int(),
     photo_id         => FV_num_int(),
     photo_neg_id     => FV_num_int(),
     overall_length   => FV_num_real(),
      },
      filters => ['trim'],
      field_filters => {
     id => 'uc',
     fixture_amount => 'nullify',  # < should become undef instead of ''
      },
      optional => [ qw{
        id description ipc_location_line_1 ipc_location_line_2
        plane_installed_on task_type repair_spec ad material_type
        fixture_amount photo_id photo_neg_id
        positive_pressure_test negative_pressure_test overall_length
        comments has_drawing has_apature_card is_ils_listed
     }],
      missing_optional_valid => 1,
      validator_packages     => [qw(Data::FormValidator::Filters::Nullify)],


Any tips?

-- 
fREW Schmidt
http://blog.afoolishmanifesto.com

Re: [dfv] [rt.cpan.org #47502] Parameter is not recognized as unknown if it is undefined or empty string

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

> Conditions:
> Data::FormValidator v4.63
> 
> Steps to reproduce:
> perl -MData::FormValidator -le '$r = Data::FormValidator->check({datum
> => undef}, {}); print join " ", 0+ $r->has_unknown, $r->unknown'
> perl -MData::FormValidator -le '$r = Data::FormValidator->check({datum
> => ""}, {}); print join " ", 0+ $r->has_unknown, $r->unknown'
> perl -MData::FormValidator -le '$r = Data::FormValidator->check({datum
> => 0}, {}); print join " ", 0+ $r->has_unknown, $r->unknown'
> perl -MData::FormValidator -le '$r = Data::FormValidator->check({datum
> => 1}, {}); print join " ", 0+ $r->has_unknown, $r->unknown'
> 
> Result:
> 0
> 0
> 1 datum
> 1 datum
> 
> Expected result:
> 1 datum
> 1 datum
> 1 datum
> 1 datum

Thaks for the clear report. I am willing to have the requested change in
Data::FormValidator.

You, or anyone else, is welcome to submit a test case and patch to
address it.

    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();

[Ron S. <ro...@sa...>]

Hi Mark

On Mon, 2009-06-29 at 11:32 -0400, 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.  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().

Understood. But as soon as an API is available, people will use it (if
they can) to build the profile step-by-step.

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

Sure. I was not explicit, but was thinking the call ought to take a hash
of options.

I am certainly not recommending a whole slew of methods, one per
attribute. Just merge in the params with any pre-set attributes.

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

Exactly. And offering a write-only API sure looks odd. Better let the
user get their data back!


-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html