Posted by xano on August 18, 2008 at 5:32pm
This afternoon TapocoL, cYu and I (Kaaskop @ IRC) discussed the possibilities of CCK, Validation API and Fapilicious to work together on form processing. Currently, CCK features built-in validation for specific fields, like addresses. Fapilicious is a library which (though still under development) features built-in field validation for any form field. Validation API mainly is a UI for creating custom validators and using them for CCK fields.
A few of the ideas:
- Move hardcoded validation (addresses, phone numbers, etc) from CCK to Fapilicious so other modules can use this as well.
- Let Validation API use the hardcoded validation functions in Fapilicious for custom CCK fields. Default CCK fields (again, things like addresses and phone numbers) may still access the validators in Fapilicious directly.
- Rename Validation API to Validation UI as this will reflect its purpose more accurately.
- By moving all validation to Fapilicious/Validation API AJAX validation (which Validation API provides) will be available for all forms that use the validators from one of those two modules.
- If CCK calls Fapilicious validators directly, we need to communicate this to Validation API so it can apply AJAX validation.
These are only ideas that need to be shaped into real plans, so please tell us what you people think!
Comments
I think I have advertised
I think I have advertised the AJAX validation inappropriately. We developed the AJAX validation for the purpose of running a full Drupal FAPI validation and returning errors or success. The AJAX validation is really not linked to Validation API module at all now, and we are talking about moving it to merge with another project (http://drupal.org/project/ajax_validation).
Part of the problem is that Validation API is nearly complete for GSoC, and so this would be a vast change from how Validation API is currently setup. And, I am still unsure of how FAPIlicious will be defining validators differently than how it is setup in Validation API.
Fapilicious is about
Fapilicious is about hardcoded validators that are handy and can be used in lots of modules or validators that are relatively hard to create, like phone numbers, ISBNs, etc. Though not necessarily for Validation API to function, it can be a great source of out-of-the-box validators that site admins can easily assign to CCK fields using The Validation API UI.
I don't know what demands Google makes for GSoC projects. Do you have to launch a final release of your module before the end of the GSoC? If not, I think (but that's just me, I don't know your code) it wouldn't be that hard to make Validation API and Fapilicious work together.
Validation API already
Validation API already validates on ANY field, be it core, custom form in module, added fields in hook_form_alter, or CCK fields. Not just CCK fields mentioned in the original post.
I have PHP code that you can write to validate a value, or you can use direct regex code that just gets popped into preg_match for the validations. So, the hard-to-create validators can be made in Validation API.
One of our aspirations with this project was to include a form when downloading the project that would have the user decide some of the basic validators (phone numbers, email, url, ISBN, etc.) that they want to use. Then, they would just import the given code straight into the Validation API module, and they would be usable on ANY field they want. This could be like a moderated library, where validators with errors can get filtered out by negative responses, and get appreciated by positive responses (so people can feel safe that a validator is correctly validating). So, this was our idea for minimizing admins/developers from recreating the same validators. Which seems similar to the library section you were mentioning about Fapilicious.
I think it needs to be known that Validation API is not just a UI, it has a structure that Fapilicious may be overlapping.
In the end, I see an idea where Validation API merges with Fapilicious to incorporate the idea of hardcoded validators (besides the hook_add_validator for importing module-driven validators used in Validation API). And, then the merged project will need to work closely with CCK to keep each project up-to-date with each other, so validations are always being run properly.
Replying to the comment: My mentors have a bigger effect on the demands of a project than Google (cYu is one of my mentors). And Yes, I need to have a stable version that is completing the requirements. I believe there is some leeway, but changing the project is not an option for my submission to GSoC. The idea can (and possibly should) be worked with after my work for GSoC is complete.
Kick. Are you still
Kick. Are you still enthusiastic about this?