Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The attached patch does the following:
1) Eliminates the need for #validate_arguments by expanding the syntax of #validate. What used to be:
'#validate' => 'max_length',
'#validate_arguments' => 60,
is now:
'#validate' => array('max_length' => 60),
Note that the old #validate syntax (a string or array of strings) will continue to work and multiple arguments can be specified with, for example "array(60, false)" instead of "60" above. See the comments for _form_parse_callbacks() for details.
2) Registers an error message returned by a validator.
Benefits:
- more readable function/argument format
- same format can also be used for '#filter' property (and others, potentially) which I will soon implement
- simplifies validators (and increases modularity) by not requiring them to report an error, just return a message
Comment | File | Size | Author |
---|---|---|---|
#14 | filter_39155.diff | 716 bytes | Richard Archer |
#10 | form_api_consistency_0.patch | 7.53 KB | chx |
#3 | form_api_consistency.patch | 8.2 KB | chx |
form.inc_3.patch | 3.42 KB | Alex Reisner | |
Comments
Comment #1
adrian CreditAttribution: adrian commentedI absolutely love this ..
+10
For the uninformed, Alex did some great work on the formproc module (alexreisner.com/drupal/modules/formproc), which
was developed for Drupal completely separately from the Forms API (lack of communication, d'oh).
Alex has tons of experience in writing form processing code, and I convinced him to try and get as many of his features for formproc in
before the 4.7 release.
This is a clear boon to the API, making it more readable, and lessening the amount of properties we need.
This mechanism could also be used for menu arguments.
Comment #2
adrian CreditAttribution: adrian commentedCould you port the other callbacks too (specifically execute and process/ after_build).
Comment #3
chx CreditAttribution: chx commentedAs happened with hook_node_info so should happen with these: we allow only
array('functionname' => array(arg1, arg2, arg3))
syntax. Note that this adds #process_arguments functionaility, makes form.inc execute less code and makes form.inc shorter.Comment #4
adrian CreditAttribution: adrian commentedI'm not fond of standardising on one format, as having an => array() always hanging around when a vast vast minority of callbacks ever use parameters (but enough to not just drop the arguments entirely). This reminds me of all the null, null, null, $variable stuff in the old form api.
Comment #5
eaton CreditAttribution: eaton commentedIn those normal cases, though, the array() is a default and the user doesn't need to set it. Transparent from the perspective of someone making a simple form. Am I misunderstanding the code?
Comment #6
chx CreditAttribution: chx commentedIf it's simple, all is dandy. Look at filter_form, there you see what Adrian's problem is. However, I think consistency and speed worths an extra
=>
on _very_ rare occasions.Comment #7
chx CreditAttribution: chx commentedI meant: an
extra => array()
on _very_ rare occasions.Comment #8
Alex Reisner CreditAttribution: Alex Reisner commentedGiven the wide variety of situations in which callbacks can be used I don't think it's wise to generalize about the frequency of argument-passing. Especially if this is about establishing a global syntax, I vote for the format that results in the most readable code as long as it doesn't impose a tremendous speed penalty. In my judgment my proposed solution is this, but I accept that it's a judgment call and defer to those more familiar with Drupal core than I.
Comment #9
chx CreditAttribution: chx commentedHere is the discussion that lead to hook_node_info as of now:
And here is the sentence that lead to this patch:
Same train of thought IMO.
Comment #10
chx CreditAttribution: chx commentedReroll to keep up with head
Comment #11
webchickOk, tested this patch:
Create account/login: both are working fine
Node submit: tried both a page (basic) and a poll (more advanced), and both are working fine.
Checkboxes/Radios: Futzed with the themes in admin/theme and settings saved fine.
Date element: this did NOT work, but a clean HEAD does the same thing: I entered a profile field of "birthdate" and put in a date (Apr 7, 1987 -- and no that's not my birthdate :P) and it got reset to "01/01/1".
So overall, it doesn't seem to break anything that wasn't already broken, and does create consistency among the various form-related things. +1.
Comment #12
chx CreditAttribution: chx commentedComment #13
Dries CreditAttribution: Dries commentedCommitted. Thanks.
Comment #14
Richard Archer CreditAttribution: Richard Archer commentedThis patch backed out part of Patch #39605 and filters no longer work.
Here's a patch that fixes it.
Comment #15
chx CreditAttribution: chx commentedAlso fixed in http://drupal.org/node/39778
Comment #16
Jaza CreditAttribution: Jaza commentedBefore I applied this patch, the 'input formats' fieldset on the node add/edit form shows up empty. After applying it, the fieldset shows up with all options displaying, and when the node is saved, the filtering system functions correctly depending on the selected format, and the selected format is remembered and re-populated on editing.
So in short.. this 1-line patch is ready for core, and should go in ASAP.
Comment #17
Jaza CreditAttribution: Jaza commentedComment #18
Dries CreditAttribution: Dries commentedI committed 39778. This is fixed now? Please mark this issue 'fixed' after testing. Thanks.
Comment #19
Richard Archer CreditAttribution: Richard Archer commentedYes, this has been fixed.
Comment #20
(not verified) CreditAttribution: commented