Proposal: Add custom validating hook to CCK text.module
| Project: | Google Highly Open Participation Contest (GHOP) |
| Component: | Task idea |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
I am posting this here for thoughts first, especially from yched and KarenS, because it likely needs some refinement before we fully taskify it. In particular, I am interested in (a) if the task is too ambitious, (b) are we over-specifying the task (I don't want the student to have to go through a long architecture review process, as usually happens in Drupal), (c) could the feature added be done in some other, better way.
----------
This task is to add a support for user-configurable validators to the text.module that ships with CCK. text.module is a CCK field that offers single- or multi-line text fields, with or without filtering, to nodes without the site admin needing to write any code, and as part of CCK is one of the most widely used modules in all of contrib.
Currently, there are a number of CCK field modules that are simply a text field with some formatting logic applied to them, such as for a UK telephone number, a US social security number, an email address, etc. Sometimes there is additional functionality that those modules provide that is necessary. In many cases, however, a full CCK field module is unnecessary and all that is needed is extra validation capability. By allowing for configurable validation rules on the text.module itself, we can eliminate a lot of needless code.
For this task, write a patch for the "HEAD" version of CCK to add such functionality to text.module. It is already ported to Drupal 6, so should use Drupal 6 APIs. The patch must follow all relevant Drupal coding conventions and standard APIs. The patch must add the following functionality:
* When configuring a text field, as part of the field configuration (not widget configuration), allow the user to select an arbitrary number of validation rules from a list. Each validation rule must have a name/label and optionally a minimal configuration. Use of Drupal 6's new AHAH-add-fields functionality here is encouraged.
* The list of validation rules should be provided by a new hook, exposed by the text.module, called hook_textfield_validators(). Any module may define an arbitrary number of validators that it offers. Each validator should work by accepting the value of the text field and the configuration of the validator (if applicable) to a callback function and returning TRUE (indicating that it passes validation) or FALSE (indicating that it failed).
* When validating a submitted text field, the text.module should call each configured validator in turn with the submitted content. If any validator fails, the entire validation process fails and the field should fail validation with an appropriate error message.
* The text module itself should provide at least two validators of its own: A user-defined regular expression (PCRE) or user-supplied PHP code that will return TRUE or FALSE.
* Although it is not required for this task, a later task will include pushing a regular expression check out to the user-side where it can be validated with Javascript/jQuery as well. Do not implement that functionality here, but keep it in mind so that it is reasonable to add it later.
The task is completed when the patch has been posted to the CCK issue queue and reviewed and marked "Ready to be committed" by one of the CCK maintainers.
Resources:
* http://drupal.org/project/cck
* http://drupal.org/project/issues/cck
* http://api.drupal.org/
Mentors:
Karen "KarenS" Stevenson
Yves "yched" Chedmois
#1
only subcribing for now :-)
#2
I think this could even be abstracted a little more. I mean, number fields could use validators too, I guess. Date fields too, definitely And why not image fields (for the title/alt parts) ? Validators would be handled by the 'master' content.module, instead of specifically tied to text.module. Doesn't really add overhead to the task as described above, and definitely a better start. 'Allowed values' also started as a 'text and number' specific thing, resulting in code duplication and cruft. They have been generalized in CCK D6.
Fromatters become another 'entity', along with the ones that currently exist (fields, widgets, formatters), and the API can largely be derived from the widgets / formatters API :
- hook_validator_info() lets modules declare the validators they implement, along with the field type(s) they can operate on.
- hook_validator_settings() lets them declare the $form to use for settings (just like 'form' / 'save' ops for hook_widget_settings)
- hook_validator() performs the actual validation of the field values.
Most delicate part would probably be the UI.
We need to use the same sort of UI Imagecache currently uses :
- validator 1
setting 1 [_________]
setting 2 [x]
[Remove this validator]
- validator 2
setting 1 [x]
setting 2 [_________]
setting 3 [select box]
[Remove this validator]
- add new validator : [select box of available validators]
Which might be some non-beginners FAPI manipulation :-) But FAPI3 in D6 probably makes that a little easier ?
#3
Yched just pointed me to this issue. This is definitely something people have been asking for, so it's worth spending time on. It might be pretty ambitious for a GHOP project, but some of these guys are turning out great stuff, so who knows what they could do with it.
I totally agree with yched that the way to do this is in the content module so it can be used in the same way by any field, using the hook_xxx pattern he suggested. His post is a good outline of how it ought to work.
If someone is willing to take this on and it turns out to be an impossible task, is there a way we can scale the task back so they can get credit for doing something less than the original grand plan?
#4
It'd be good to have a "fallback" plan, definitely. I'm not sure who though other than the two of you would be able to come up with something suitable. :(
#5
What about moving the heavy UI part (a la imagecache) out of the task, and starting with a user experience like :
- edit field settings : open 'Validator' fieldset, pick a validator in a select dropdown, submit the form
- return on field settings : the validator fieldset now displays the settings form for the chosen validator, and a 'remove validator checkbox.
- you don't get to add a second validator for now.
Thus reduces the FAPI work to something quite classic, while allowing the task to still implement the feature.
After this is marked finished, we can add a new task for a full fledged UI, or tackle that ourselves.
#6
Scaling back the UI until later sounds good. But the interesting validators would still require configuration, wouldn't they? So it would be select a validator from a drop down, and specify its configuration options if necessary. Would that be scale-appropriate for GHOP?
#7
So it would be select a validator from a drop down, and specify its configuration options if necessary.
And you need to submit the form between those two steps, yes.
Would that be scale-appropriate for GHOP?
I'd say so. With that UI simplification, implementing validators means recycling existing api structure to a large extent.
#8
Here's another thought - this is pretty complex and undefined stuff, and to make this useful, we need both the hooks in the content module and one or more validators already set up and ready to choose from so you can try it out. So instead of creating the content module hook, we could make the GHOP project to identify some useful validators for CCK and describe what exactly they would do and what fields they would be used with. To avoid getting into FAPI issues, maybe have the GHOP student just create code snippets that would do the validation without trying to actually write the FAPI code itself.
If we had some pre-created validators and validation snippets ready to use, someone with CCK skills (might end up being me or yched) can add hooks and flesh out the FAPI implementation.
#9
OK, let's try before it's too late :-)
--------------------------------------
CCK is one of the most widely used contributed modules for Drupal. It allows site administrators to customize their content types by adding any number of additional fields (text, number, date, image...), without writing a single line of code.
One missing feature is user-configurable validation steps, that currently do require manual coding and trickery. This has lead to the proliferation of CCK field modules that are simply a text field with some formatting logic applied to them, such as for a UK telephone number, a US social security number, an email address... In many cases, however, a full CCK field module is unnecessary and all that is needed is extra validation capability, which would eliminate a lot of needless code and provide additional flexibility for site administrators.
The goal of this task is to add a support for user-configurable validators for any CCK field type. It should be targetted as a patch to the HEAD (for Drupal 6) version of CCK's content.module.
* When configuring a field, as part of the field configuration (not widget configuration), allow the user to select a validation rule from a list. Each validation rule must have a name/label and optionally a minimal configuration. Use of Drupal 6's new AHAH-add-fields functionality here is encouraged.
In order to simplify the form workflow management, the scope of this task is limited to 1 validation rule per field for now.
* The list of available validation rules will be provided by a new hook, exposed by the content.module. Any module may define an arbitrary number of validators that it offers for any field type. Each validator should work by accepting the value of the field and the configuration of the validator (if applicable) to a callback function and returning TRUE (indicating that it passes validation) or FALSE (indicating that it failed).
* When validating a submitted field, the content.module should call the configured validator with the submitted content. If the validator fails, the field should fail validation with an appropriate error message.
* At least two validators for text fields will be implemented in this task : A user-defined regular expression (PCRE) and user-supplied PHP code that will return TRUE or FALSE.
* Although it is not required for this task, a later task will include pushing a regular expression check out to the user-side where it can be validated with Javascript/jQuery as well. Do not implement that functionality here, but keep it in mind so that it is reasonable to add it later.
The API for validators can be largely derived from the existing API for widgets and formatters :
- hook_validator_info() lets modules declare the validators they implement, along with the field type(s) they can operate on.
- hook_validator_settings() lets them declare the $form to use for settings (just like 'form' / 'save' ops for hook_widget_settings)
- hook_validator() performs the actual validation of the field values.
The task is completed when the patch has been posted to the CCK issue queue and reviewed and marked "Ready to be committed" by one of the CCK maintainers.
Mentors :
yched, KarenS
Ressources :
- CCK HEAD for Drupal 6 : http://drupal.org/node/96064
- the sample fields provided in the 'examples' folder in CCK HEAD.
- 'CCK for developpers' handbook : http://drupal.org/node/101742
#10
After webchick's greenlight, I created the task at http://code.google.com/p/google-highly-open-participation-drupal/issues/...
Corresponding CCK issue on d.o is http://drupal.org/node/212665
So, closing this
#11
Aside from a misspelling of "developers" on the last line, I think this looks fine. My only concern is that building it for one validator only will make extending it to multiple later difficult, but I agree that would make the task too complex for even an advanced GHOP task. +1.
#12
This was already taskified, so closing again. Oops @ typo.