Moved to official ideas list at http://drupal.org/node/236469
I'm not a student, but I'm posting this idea as a project I'd like to see happen. The idea was inspired by Benjamin Keen's Really Simple Validation and PHP Validation pair of scripts. Those two scripts use identical rules to perform both client-side and server-side form validation using Javascript and PHP respectively.
The idea here would be to create similar validation functionality for adding rules to Drupal forms. Adding a rule to a field once would add both Javascript and PHP validation. To eliminate duplicate effort, the PHP side might simply leverage the existing rule set of the jQuery Validation plugin. Ideally, the module would function both as a validation API, to be called from custom modules, and as a CCK add-on, for beginners to more easily add validation to CCK forms.
I'd welcome any feedback on the idea.
Comments
Wow, *wicked* idea!!
I've cross-posted to the CCK group, in the hopes we can get their thoughts, as well as possibly pick up a mentor or two.
expand a little
I think that in addition to this it would be to expand on the validation available to cck. It should probably take the current validation (i.e. min words) out of cck and then implement it inside of this new module. Then this new module would provide all current cck validations plus new ones. If someone could do that and make it all work with a jquery/php validation combo - then we'd have a great situation (and have a reasonable amount of work for the summer).
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
I might be missing
I might be missing something, but this can begin its life as a contrib module and then move to core when it is ready. fapi is flexible enough that contrib can do anything that core can do. we don't have any js validation today so there isn't anything to override there.
THis would be pretty cool.
.
Firstly, I agree with Moshe, this should live (at least at the start of its life) in contrib.
But what would be really awesome about this would be if people didn't have to write any custom validation code at all. This would be awesome. Not sure quite how this fits in with your idea.
Some ideas
A) make preg based validators, they are easy to run the same in PHP and JS. Provide a number of them per default and let the advanced user enter her own. B) make AHAH based validators -- send the data to the server so the validator only runs in PHP. This also lets you to do tricky validations against webservices which would rock.
Love the idea. Agree with
Love the idea. Agree with the idea of stripping validation out of CCK and moving it here. I tend to think that validation should be done only in PHP (using AHAH) so it's the same with or without javascript and to make future maintenance easier by eliminating duplication.
The question is how to structure this and how to inject it. Yched and I were thinking about some system similar to the way CCK formatters work where any module could provide a validator for any field. There could be a library of things that work with #validate and CCK could provide a drop-down selector from that list for CCK fields to make it easy to choose one or more.
It seems like it will need a system like CCK uses for formatters, where you have a hook_info() where validators can declare themselves and indicated what kind of data they work with (like by field type -- int, varchar, text). And you need a way you can provide settings for validators. And you need a way to prioritize them so certain validators run before others.
me three
I'll pile on some +1 support on this project. I know I could get some workday time to commit to it.
/me ponders switching from floater mentor to be on this one
FYI if people do want to use
FYI if people do want to use the jQuery validation plugin (which I think is awesome btw ;), it's already on cvs.drupal.org for d5 & d6.
Might be worth looking at
Might be worth looking at the java web framework world for examples. I seem to remember a couple of slick packages that allowed you to define the validation rules on the server side, and then automatically generated matching client-side javascript.
I do not know if replying to
I do not know if replying to this is the proper way to apply. But, I have been trying to figure out a project that would help Drupal utilize AJAX (or AHAH). So, this project sounds like a perfect opportunity for me to offer my skills to take this under as a Summer of Code Project. Let me know, if I should apply elsewhere.
I was wondering what about implementing this as apart of the FAPI. Each form item would have an optional associative key called '#validate' (not the same as the '#validate' for the validate function of the form). This key could hold values like 'integer', 'alphabet', 'alpha-numeric', maybe an array for maximum/minimum (array('max', 5) would test that input fields do not have more than 5 characters or that the maximum selections for select fields is 5). All of these would include PHP and JavaScript validating. However, if you have custom validation that are not in our general fixes, then you can enter array('function', 'insert_function_name') as the value, and then JavaScript would not be applied, instead the validation would work like it does now and use the given function name to run the validation testing.
I am just talking out loud to see if this would make any sense to other people.
Woohoo!
TapocoL,
I'm very happy to see a student interested in this! Tackling it using AJAX (or AHAH) would make it a more interesting project and probably easier to maintain in the long run.
I like the idea of making it part of FAPI eventually, but I agree with those above who have mentioned that it's something that would benefit from some usage and testing time as a contributed module, before being added to core.
If the project does go the AJAX/AHAH route, I think it would still be a good idea to adopt some library that has stood the test of time, to use as a benchmark for what validation tests to include.
I'd also really like to see this module benefit both developers and non-developers (ie, site-builders). In other words, the project should go beyond just creating an API module and create a UI and/or concise documentation for adding rules to any form.
As for applying, you might want to start by checking out Google's Advice for GSoC Students Page. I'm guessing there will be more details posted to this group, around the time that applications officially open on March 24.
Yes to FAPI
This would use FAPI, but not change core FAPI. FAPI already has #validate (to validate the whole form) and #element_validate (to validate an individual form element) and that's what you would use. The job would be to create a library of functions that could be added into the #element_validate array and a method of selecting one or more of them for a specific form element.
So as I said above, I think you're talking about creating a way for modules to register validators and a way to indicate what validators are appropriate for what kinds of form elements, and a way to select a validator for a specific form element.
easy configuration is critical
to prevent this from getting limited traction and then just dying out (no adoption). the validation infrastructure comes first, fapi integration next, but the last piece is accessible configuration (point-and-click). for example, cck field definition must include:
i'm willing to co-mentor
My proposal
The following is a rough draft of my proposal for this Summer of Code project. Please leave your feedback. Thanks.
EDIT: I forgot to mention how the Really Simple Validation and PHP Validation were going to be my basis for the project.
Student application for Google Summer of Code 2008:
First of all, I am Craig Jackson and I would like to thank you for reading my application. I am a Salt Lake Community College student in Salt Lake, UT, and I am currently employed as a web developer working on a Drupal web site. I have been greatly interested with getting involved in open-source development. However, the only area I have been able to help is on forums and submitting issues/bugs. My aspirations are to become a free-lancing web-developer that builds custom web sites and applications. Therefore, I am very excited to give my time and my skills into a Summer of Code project with Drupal. It would be very beneficial to me as a learning developer, and important to Drupal as a system needing a few more high-key features to become ‘THE’ content management system for all.
The aspect I believe Drupal could use help in is ease-of-validating forms through their API. Currently, there are only PHP functions that can be called to validate functions. There is a lack of simple-to-use validation tools, or a system that can be easily extended to support this type of functionality. Plus, Drupal is also lacking in efficiency by having every user load a new page for each submission attempt.
My proposal for Summer of Code 2008 is to create a new system for validating forms in Drupal. This system will be an addition to the Forms API that will be focused on ease-of-use. This will include calls to pre-built validation functions (e.g. email, US phone, numeric, etc.) and custom-extended functions (e.g. alpha-numeric fields, max characters or selections, etc.). After the new API addition is built, my focus will turn to creating efficiency through replicating the validations into JavaScript and creating a simple GUI for the end-users (non-developers).
I have been messing around with my own personal sites and my friends’ sites for more than 10 years, and have been a web developer for nearly a year with my employer. During this time, I have gained extensive knowledge about Drupal and it’s inner-workings. My skills are focused in PHP (Drupal’s language), MySQL (supported Drupal database), Javascript, XHTML and CSS. I believe that I have a strong background that will make this project attainable. However, it will create a challenging atmosphere for me to develop my knowledge of the web.
Thank you for your time and commitment to open-source,
Craig Jackson
I think it will be difficult
I think it will be difficult to get past "simple" validation if this project goes the route of maintaining separate but parallel validation rules in PHP and Javascript. I'd love to see this in any form, but I see much more power in chx's suggestion B) above.
I am unsure of the approach
I am unsure of the approach wanted, between AJAX/AHAH or just a javascript validator. So, I am awaiting further feedback on that.
Both
JS and PHP have rather similar regexps -- not the same , but sufficiently same for a lot of tasks to be doable easy both ways. The owl book (Mastering Regular Expressions from O'Reilly) is basically mandatory for this project.
AHAH/AJAX is also highly required because there are quite a number of validations that can't be done via JS.
Any other comments towards
Any other comments towards my proposal?
php only
concur with chx and cYu, maintaining separate implementations in php and javascript is less than optimal.
potential issues:
possibly could implement regex rules with a javascript wrapper if php and javascript regex implementations are identical (just pass the regex rule around). anything else should be ajax-based with one validation routine implemented in php.
ideally, this infrastructure could function at a low enough level to validate nodes created through import modules.
A high level language for conditions
Would it make sense to have an interface for specifying conditions and generate php and javascript code from that description?
Additionally, does enforcing any sort of relations between form fields fall under the scope of this project? For example a series of select boxes that update there options based on the option selected in previous one. But such things will have very different implementation in php (a validation scheme) and javascript (a preemptive scheme). So probably it makes sense to have a distinction between validations that are applied in a preemptive manner and those that are not.
I am interested in working on improving the form elements usability in general. Have also been looking at better form elements proposal and implementing this kind of functionality surely falls with in the scope of better (more usable) form elements.
Please provide some comments and I will go ahead and submit an application.
Abhaya Agarwal
Abhaya Agarwal
www.pothi.com
Validation rules should have
Validation rules should have knowledge of other form fields, but dynamically adjusting select box options is less about validation and more about manipulation. I believe there are existing options for creating dependent select boxes and defining relationships, so ideally your validation rules could make use of those.
I am assuming this module
I am assuming this module will be using the Drupal.settings property quite a lot, just be careful to keep SEO in mind as search engines will be indexing pointless data websites are outputting this javascript at the top of the markup.
vision media
350designs
Print Huge Edmonton Printing Services
Design Inspiration Gallery
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School