Thread: [dfv] Data::Formvalidator and JQuery validation
Status: Inactive
Brought to you by:
markjugg
Menu
▾
▴
cascade-dataform
|
From: Lyle <web...@co...> - 2010-03-18 00:01:52
|
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
|
|
From: Mark S. <ma...@su...> - 2010-03-18 14:32:51
|
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/ . . . . . . . . |
|
From: Lyle <web...@co...> - 2010-03-18 15:59:59
|
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 |
|
From: Mark S. <ma...@su...> - 2010-03-19 14:03:14
|
> > ( 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/ . . . . . . . .
|
|
From: Lyle <web...@co...> - 2010-03-20 03:45:17
|
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 |
|
From: Mark S. <ma...@su...> - 2010-03-25 00:36:16
|
> > 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/
|
|
From: Lyle <web...@co...> - 2010-04-02 19:47:50
|
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 |
|
From: Cees H. <ce...@gm...> - 2010-03-19 00:39:06
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X