Currently 'multiple' widgets (one form widget accepts multiple values input) need to validate that the number of values does not exceed the field cardinality. Both option.module's widgets and the newly added "autocomplete widget for 'taxo term' field" have code to handle that.
This check should be hardcoded in a default validation step for all fields, whatever the widget.
That check should happen in a new field_default_validate() function in field.default.inc, invoked by a _field_invoke_default('validate') call in field_attach_validate().
Saves duplicated code, and also accounts for pure API, non-form saves, which we are supposed to support.
Kind of related to (but not duplicate of) #437604: Do not rely on FAPI for 'required' validation.
No API change involved, can happen post-freeze IMO.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | field_options_test_quickfix.patch | 686 bytes | yched |
| #14 | field_validate_cardinality-552436-14.patch | 24.83 KB | yched |
| #13 | field_validate_cardinality-552436-13.patch | 25.28 KB | yched |
| #10 | field_validate_cardinality-552436-10.patch | 22.39 KB | yched |
| #9 | field_validate_cardinality-552436-9.patch | 22.41 KB | yched |
Comments
Comment #1
yched commentedfix title, add tags
Comment #2
HeraChen commentedpls help me. thanks a lot
Comment #3
yched commented@HeraChen: you should try the regular places for support: http://drupal.org/forum, or irc://irc.freenode.net/drupal-support.
Please don't hijack existing issues.
Comment #4
yched commentedSee the OP for the rationale.
Patch summary:
- adds a field_default_validate() operation, called through _field_invoke_default() in field_attach_validate().
that's a generic equivalent to the field-type-specific validation done in hook_field_validate().
- copying the PHPdoc from hook_field_validate(), I removed comments about field_attach_query() that don't apply anymore.
- removes the specific cardinality checks that were done in options.module and taxonomy.module
+ test stuff:
- adds a test for API validation in FieldAttachOtherTestCase::testFieldAttachValidate()
- adds a test for form-based validation in FieldFormTestCase.
- this test uses the assertListValues() helper function, moved from from options.test into field.test. Quite handy to have it there.
- this test uses a 'multiple value' widget implemented in field_test.module (simple comma-separated input).
Note that actual code change is 7k, the rest is tests ;-)
Comment #5
yched commentedComment #7
yched commentedSmall error in test_field's hook_field_widget(). Attached patch should fix the failures.
The 'no_test' patch in #4 is unchanged.
Comment #8
dries commentedThis could do with a small code comment to explain the purpose of each call, and their order. Why do we need to have two layers of validation functions?
Comment #9
yched commentedComment added:
Comment #10
yched commentedReroll after #635094: Unify "language neutral" language codes and #628642: Taxonomy field 'column' should be 'tid' instead of 'value'.
See #9 for a 'no-test' patch.
Comment #11
yched commentedEasier tracking.
Comment #12
dries commentedA couple of points/questions:
This snippet didn't make sense to me. I had to look at field_set_empty() to actually make sense of it, which is not a good sign. Either the code comment needs to be improved, or the function field_set_empty() needs to be renamed to be more self-explanatory. In fact, field_set_empty() has a todo
* TODO D7: poorly named...-- it wouldn't hurt to rename the function.Does this test make sense? What if
$field['cardinality'] == 1butcount($items) != 1... we wouldn't trigger an error. If this is a generic validation handler, we might want to make it 100% generic?Only needs one point.
Comment #13
yched commented1) OK, renamed field_set_empty() to _field_filter_items() to keep symmetry with the sister helper func _field_sort_items(). Also refreshed the PHPdoc a bit.
2) You're right of course. I copied the structure of this code from option widgets, which didn't need to care for "cardinality = 1", because this case was ensured by form structure and FAPI. Fixed.
3) Fixed.
Comment #14
yched commentedRerolled.
+ tentatively setting to RTBC, since Dries remarks were adressed.
Comment #15
dries commentedLooks good now. Committed to CVS HEAD. Thanks!
Comment #16
carlos8f commentedThis patch broke OptionsWidgetsTestCase, since it uses methods which are undefined in the class inheritance. This is another fire we have to put out before #560646: Fatal PHP errors don't cause tests to fail can land, so we can fix the test bot which is currently totally blind to these errors. The first one is:
Most of the field tests extend DrupalWebTestCase, which isn't logical since there is already a parent class for them to use, FieldTestCase. I tried to create a patch, but I could not get OptionsWidgetsTestCase to extend FieldTestCase (which has the methods in question), because I am getting some random crash:
Which I think is related to my installation of PDO. Anyhow, we need to fix OptionsWidgetsTestCase fatal errors. Then I want to create an issue examining the class inheritance in our tests.
Also, I just noticed this, list.test (a required module) implementing:
which inherits from field_ui.test (an optional module), this is totally whacked out :P
Comment #17
yched commentedclass ListFieldUITestCase extends FieldUITestCase {was introduced in #653940: Clean-up: Tests do not report all errors:http://drupalcode.org/viewvc/drupal/drupal/modules/field/modules/list/li...
Attached patch should fix the "undefined method OptionsWidgetsTestCase::assertFieldValues" fails.
Comment #18
carlos8f commentedyched: thanks.
Comment #19
webchickCommitted to HEAD. Thanks!
Comment #20
yched commented@carlos8f :
class ListFieldUITestCase extends FieldUITestCaseis fixed in #639466-23: hook_options_list() + XSS filtering