Project information
http://drupal.org/project/validation_api
Project description
Creating a validation system, that will add additional validations to any form field (core or contrib) with a UI in the admin section. Plus, I will add AJAX to forms that will allow forms to be validated and return errors without loading a page (if there are not errors, then it will run drupal's normal submitting system).
GSoC Page
Project schedule
Now - May 26th: Get ready to begin coding (including: get comfortable with CVS/patches, set-up a rough framework of hooks and functions, etc.)
May 26th - July 15th: Have the database-driven Validation API system set up with admin UI and fields being validated properly
July 15st - July 31st: Set up the AJAX validation system with fields being highlighted and messages of the errors being visible, or submitting through Drupal's normal process. And, if Javascript is turned off, the functionality will (in no way) affect forms.
August 1st - August 10th: Finish up all features to release a beta version of the module.
August 11th - August 20th: Clean up, Optimize, Document, and start releasing candidates.
August 21st - End: Get feedback on bugs and requests, and get ready to release the final version for the end.
Status updates
2008-08-11
Done:
- BETA version released. No known bugs remaining, so feel free to give it a beating.
- You can manage field types for your validations, now.
- Fixed bug when validators were not being listed if they had no arguments.
- Got rid of some of my testing code.
- Fixed bug with listing an argument for a field when a validator did not have an argument.
- Restructured how fields get named, by not allowing automatic validating for everything in a tree, and using placeholders that can be used to declare everything in a certain step of a tree to be validated.
- Separated the AJAX Validation into it's own module, but is still apart of the Validation API project.
- In AJAX Validation, it now appends messages to fields with errors, and does not use a message box.
- Revamped the README and help sections to get it caught up to all the changes.
- Fixed some of the bugs with updating validators, and now admins can disconnect the validator and the hook it was imported from (it helps keep the update link off the admin page, if that is annoying to you).
Next week: Update the documentation in my code. AJAX Validation might be merged with another project.
Holding me up: STILL, the most important thing is testing/feedback as the project is now in the BETA stage.
2008-08-04
Sorry, I spaced to put up an update last week. So, this will be a two-week update.
Done:
- Got rid of abbreviations in my code.
- AJAX can be turned on and off.
- Change the UI for creating the relationship between fields and validators. Two-part add system.
- Field's can either use the default validator message, or create a custom validator message for each field.
- Validator arguments are now unlimited, and have names and descriptions associated with them for help inputting on the field UI.
- Now fields can be traversed through unlimited amount of #trees.
- Lastly, I have branched out the code into DRUPAL-6--1 for organization.
Next week: Will continue working on issues, cleaning up the unlimited argument code, cleaning up anything else for the BETA release.
Holding me up: STILL, the most important thing is testing/feedback as I got most of the key components ready for people to try and break.
2008-07-22
Done:
- You can make AJAX validations now.
- Added Help System
- Been able to trim the issue queue to 5
- Also, added a dev-snapshot to my Project
Next week: Finish up the issue queue. Some more features need to be implemented like on/off AJAX, message overwriting on the field-level, updating some admin UI to make it better to work with, etc.
Holding me up: Probably the most important thing is testing/feedback as I got some of the key components ready for people to try and break.
2008-07-17
Done:
- Got the main problem fixed. You should be able to validate CCK fields now.
- If you use #tree for a form, you can use the base name (e.g. field_name), or you can choose one of the fields in the tree (e.g. field_name[1]).
- The same 'add_validator' hook being imported will choose a different name.
- You can clone validators.
- If an add_validator gets updated on any module, it will give you an 'update' link on the admin screen. The link will lead to a page showing the differences and asking if you want to update.
- Started implementing jQuery AJAX. However, there are a couple problems holding it up. You can uncomment line 15 on validation_api.module (Revision 1.16) to test it out.
Next week: Working on jQuery AJAX, and going through the issues.
Holding me up: The form does not seem to be validating properly. So, it is showing successes when it shouldn't be a success. And, on my test page ('validation_api_test'), if you put anything in the textfield, it does not get posted properly in the AJAX.
2008-07-09
Done:
- Made several adjustments to the validation process
- Now able to recognize CCK fields, however a conflict with the names keeps this from being fully functional
- Got rid of 'add validator to field' link, as several things are changing this is causing a problem
- Made the Alpha release, however I have made a new commit since then
Next week: Finish up the functionality of the validator, so every field will be validating independent of module. Then, start moving towards the AJAX functionality of the module.
Holding me up: Still been trying to work through the problems with validating different types of fields. CCK uses 'field_name[0]' as the #name in validating. However, the name is only grabbed as 'field_name' during form traversing.
2008-06-30
Sorry for the lack of updating last week... :(
Done:
- It can now find CCK fields.
- Wrote up a tutorial on how to use the module.
- Wrote up an example, as well.
- Fixed some minor problems that came up while I was doing the documentation.
- I made some adjustments to the schedule above as the field problem has been a little more difficult than first expected.
Next week: I will be out of town this upcoming week. I will be making final touch-ups for the alpha release, and completing whatever Google needs for the mid-terms before I am gone.
Holding me up: Been testing alot to figure out how to solve the problem with some fields not being traversed properly. I have figured the problems out somewhat (#tree and CCK use a different FAPI structure), but I have not been able to put together a solution as of yet.
2008-06-17
Done:
- Form Element's #suffix to add a quick-link for each field to add a
validator to. - Adding arguments to regex and PHP validators.
- Export/Import functionality.
Next week: Still working on getting all form fields, that are passed through the FAPI, to be validated properly.
Holding me up: Fields created in CCK are not being passed through the validator.
2008-06-10
Done: I had a lack of time this week. However, I was looked through workflow-ng's code as a recommendation from one of my mentors (Chris). Also, I was able to run through a couple issues that was submitted, and respond to them.
Next week: Changing a couple things to increase the extendability with the system. Finish getting the functionality working.
Holding me up: Well, I just didn't have enough time this week. However, the coming weekend looks free for me to get plenty done.
2008-06-03
Got Done: I have been deleting my previous updates, so I will just compile it all in this one. Set up the database for the validators and fields being validated, and set up the admin UI.
Working on throughout the next week: Getting the functionality to work of the validation to work properly.
Holding me up: Figuring out how to run PHP Code in validator with the value as an argument.
Comments
May 15 meeting transcript
Summary:
- code was uploaded and can be read at http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/validation_...
- storing validations in a dynamic way through the database instead of a new .module function for each one is a good thing
- meetings every Thursday at 2pm EST on freenode.
Suggestions for a channel welcome. #validation_api and #deekayen seem unnecessarily private. Maybe #drupal-dev?
1:59:53 PM David Norman: you there?
1:59:59 PM David Norman: we're setting up for you here
2:00:24 PM Craig Jackson: Yeah
2:00:51 PM Craig Jackson: Im going to grab me a sandwich for lunch, I will be back in less than 5
2:07:09 PM David Norman: http://www.mebeam.com/validation_api
2:07:10 PM Craig Jackson: Alright, Im ready
2:07:38 PM David Norman: so what else have you done since we talked last?
2:08:09 PM Craig Jackson: Well, I started working with form_alter and some javascript.
2:08:33 PM Craig Jackson: and, also learning regular expressions for the api
2:08:42 PM David Norman: anything you could put in cvs?
2:10:04 PM Craig Jackson: Yeah, I have got it to run the validation and submission by just using drupal_get_form on the asynchronous request. However, I am unsure if it is working correctly.
2:11:26 PM David Norman: which is why I'll be happy to look at it in cvs
2:12:14 PM Craig Jackson: Do I just do the same thing with the folder as I did with the README.txt?
2:12:30 PM David Norman: don't need a folder
2:12:38 PM David Norman: just put the files alongside readme
2:12:55 PM Craig Jackson: sorry, thats what I meant.
2:15:30 PM David Norman: oh, and if you don't comment here, angie is going to be after both of us http://groups.drupal.org/node/11417
2:16:24 PM Craig Jackson: K, I committed the changes
2:16:35 PM David Norman: ah, I see
2:16:39 PM David Norman: excellent
2:16:51 PM Craig Jackson: I have not used coder, devel, or anything
2:17:15 PM Craig Jackson: Plus, I have not documented it at all
2:17:19 PM David Norman: yeah, coder would have blown up on you
2:17:35 PM David Norman: for example, the drupal indent is 2 spaces, not tabs
2:18:16 PM Craig Jackson: oh, I use tabs, because I am used of that, then in Notepad I have a convert tabs to spaces.
2:18:28 PM Craig Jackson: Programmer's Notepad that is
2:20:57 PM Craig Jackson: I have a couple questions for you, after you review the files.
2:21:08 PM David Norman: just start asking
2:21:28 PM David Norman: i won't really be able to review them till I plug them in my drupal6 sandbox
2:21:58 PM David Norman: and don't wait till thursdays to ask, just ask, or ask in IRC or... something
2:22:01 PM Craig Jackson: Should Validation API and Asynchronous Requests be in separate modules? They seem to be two separate features
2:22:51 PM David Norman: are you on IRC?
2:23:29 PM Craig Jackson: no, while at work I was not able to connect to IRC. I am thinking it is some firewall issue.
2:24:33 PM David Norman: http://mibbit.com/ join #deekayen
2:24:35 PM Craig Jackson: Hopefully, my english isn't too bad. Sometimes, I type too fast that my sentences seem bizarre.
2:24:36 PM David Norman: on freenode.net
2:24:57 PM David Norman: cYu would like to join us
2:25:02 PM David Norman: and bryan is coming too
2:25:42 PM Craig Jackson: which channel?
2:25:55 PM David Norman: #deekayen
[2:26pm] tapocol: 'ello gov'nah
[2:27pm] cYu: hi
[2:27pm] deekayen: ah, now we're all here
[2:27pm] TapocoL: Whats everyone's names?
[2:27pm] deekayen: craig was just saying he uploaded some code to http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/validation_...
[2:27pm] cYu: my name is chris
[2:28pm] tecto: bryan
[2:28pm] deekayen: and I was reminding to go make a comment on http://groups.drupal.org/node/11417
[2:28pm] TapocoL: I've just heard David mention several names, so I am trying to remember whos who
[2:28pm] deekayen: and there's a mebeam going on at http://www.mebeam.com/validation_api
[2:28pm] TapocoL: My first question was... Should Validation API and Asynchronous Requests be in separate modules?
[2:29pm] deekayen: are these ar something you coded already?
[2:31pm] TapocoL: Yes, I put together some quick code in what I think would be the structure for it
[2:32pm] cYu: i hadn't pictured those as separate modules, but i don't think i had been thinking of validation api as strictly an api either
[2:32pm] TapocoL: BTW, I don't have a mic at work, so I cannot really do anything on mebeam
[2:32pm] cYu: if it is done that way, then i can see how ar would be a separate module that takes advantage of the api
[2:33pm] TapocoL: Well, I had set up the validation_api as a new function for '#element_validate'
[2:33pm] TapocoL: nm, Im sure you can see what I am doing in the code
[2:34pm] deekayen: I can see you're excited about getting the javascript part going, but I think you're going at it backwards
[2:35pm] tecto: i would start with database
[2:35pm] deekayen: you're getting the submission interface completed without an underlying structure to deal with it
[2:35pm] tecto: you need a table that stores a field reference (what field am i validating)
[2:36pm] tecto: one for validation type
[2:36pm] tecto: (php or regex)
[2:37pm] tecto: and one field for the actual validation rule (again, php code or a regex)
[2:37pm] deekayen: which means setting up the configuration area for which fields you want to validate and how
[2:37pm] TapocoL: So, instead of the validators being functions, they should be stored in the database?
[2:37pm] tecto: yes
[2:38pm] deekayen: that way you don't have to hire a coder to modify the module everytime you want a new validator
[2:39pm] TapocoL: Sorry, I am having a hard time seeing the benefit to storing in the database as compared to the functions.
[2:40pm] TapocoL: Someone can only use the validation_api, if they are planning on using it in their own custom module, correct?
[2:40pm] cYu: right now people download a zipcode cck module or phone number cck module in order to get validation
[2:40pm] cYu: the idea would be to have a text field...and be able to simply have validation for a us zipcode or for different phone number formats
[2:40pm] tecto: advantage is moving validation into pure configuration
[2:41pm] cYu: and instead of download a module to do this or having to write custom code, you'd be able to paste a little snippet into a config screen
[2:41pm] tecto: or have a library of snippets
[2:41pm] TapocoL: oh, I see now.
[2:42pm] cYu: yeah, it could be powerful and a huge step up from what exists now
[2:42pm] tecto: one other field to store is a custom error message per validation
[2:42pm] TapocoL: People can add more validators, by adding it to the database by validation_api, instead of installing a new module.
[2:43pm] cYu: right, right...an xml import/export feature would be a nice feature to help with that
[2:44pm] tecto: yes, an xml import/export format could be added later
[2:44pm] deekayen: but that's a later thing to consider
[2:44pm] tecto: and named snippets be shared
[2:44pm] deekayen: so we're obviously enjoying some synergy in the thinking
[2:44pm] tecto: apparently
[2:45pm] cYu: indeed
[2:45pm] deekayen: indubidibly
[2:45pm] TapocoL: So, the element_validate is the right step. But, I will need to change the functionality of that to search the database.
[2:45pm] tecto: well, i would start with a settings screen
[2:45pm] tecto: for storing
[2:45pm] tecto: the validations
[2:46pm] deekayen: that'll make creating new test cases easier if you're not manually inserting them in the db too
[2:48pm] tecto: you will also need to nail down how to reference fields
[2:48pm] TapocoL: This question will probably be more applicable later on, but I will ask it now anyways... Any preference in using JSON, XML or other technology as the communication means?
[2:48pm] tecto: build a list of fields
[2:49pm] tecto: json
[2:49pm] tecto: speed
[2:49pm] cYu: json is a dandy way to go between php and javascript
[2:49pm] cYu: and speedy
[2:49pm] deekayen: get the basic form submission validation to work first
[2:49pm] TapocoL: id, name, type, code, min, max
[2:49pm] deekayen: the javascript is the lesser
[2:51pm] tecto: yes, the validations need to be working well on submit before you focus on the ajax side
[2:51pm] TapocoL: those seem like the basic fields we will need
[2:51pm] deekayen: by fields I think tecto means the form field names
[2:52pm] tecto: id, field reference, type, rule, error
[2:52pm] deekayen: the relationship of form content type and name with the specific field to validate
[2:55pm] TapocoL: Just to be clear, I should start working on getting the database to work with the element_validate.
[2:56pm] tecto: no, don't start there
[2:56pm] tecto: start with the .install file
[2:57pm] tecto: creating your database table
[2:57pm] TapocoL: sorry I am generalizing too much.
[2:57pm] tecto: and an admin screen for defining your validations
[2:57pm] tecto: then make some
[2:58pm] tecto: and work on getting them running using element_validate
[3:00pm] deekayen: i think craig has at least been introduced to the light of doing config in the db instead of a new function for each validator
[3:00pm] deekayen: which made this meeting worthwhile
[3:00pm] deekayen: thanks for uploading the code
[3:01pm] deekayen: it was helpful with helping us understand what's going on
[3:01pm] TapocoL: meet every week on Thursday?
[3:01pm] deekayen: that's my plan
[3:01pm] TapocoL: sounds good
[3:02pm] cYu: that works for me, feel free to e-mail us or hunt us down on irc if anything comes up in between though
[3:02pm] TapocoL: I will for sure get the database schema done, and hopefully get the admin functionality ready over the weekend
[3:02pm] • deekayen goes to find a place to brag about TapocoL uploading code
[3:06pm] TapocoL: bye, thanks for the help
[3:07pm] cYu: later
#drupal-dev sounds great...
I'd like to see these projects in the lime-light and getting community feedback as much as possible. It'd be great for all correspondence to take place in one of the public channels (ideally, #drupal since it's much busier, so more people to chime in), rather than in some sub-channel like #validation_api or #deekayen. Remember that a big part of SoC is getting students integrated into the rest of the community, too. :)
Btw, THANK YOU for posting this! That's great.
Took a quick spin through this module today...
I left some issues at http://drupal.org/project/issues/validation_api to document things I saw.