After #626354: Remove #process pattern from number field and #628188: Remove #process pattern from taxo autocomplete widget, last but definitely not least - option widgets.
Wow, that one neeeded a good cleanup.
- Workaround for the fact that #179932: Required radios/checkboxes are not validated just made option '0' not work in checkboxes anymore. We switch in a '_0' placeholder before turning the options to FAPI, and replace it back out. We can remove that if/when that issue gets sorted out, but for now this unbreaks optionwidgets.
- Comes with an extensive series of tests. Those widgets are incredibly touchy and painful to debug.
- Adds a few missing tools to drupal_web_test_case:
assertOptionSelected(), assertNoOptionSelected() : same as assertFieldChecked() / assertNoFieldChecked(), but for options within select boxes.
allows drupalPost() to unselect options in a multiple select box (previously impossible)
Still fighting to figure out a line seemingly needed only for tests (left as a @todo), but I'm posting this for review meanwhile.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | field_options_simplify.patch | 54.47 KB | yched |
| #7 | field_options_simplify.patch | 54.37 KB | yched |
| #4 | field_options_simplify.patch | 50.11 KB | yched |
| field_options_simplify.patch | 47.4 KB | yched |
Comments
Comment #2
sunAWESOME.
This should only happen for radios, not for checkboxes.
This should be:
Form element validation handler for options element.
ugh. ;)
Can't we name this options_allowed_values() or will Field API freak out then?
We can remove the trailing colon/white-space here. And, list items like these should not have punctuation.
Strange wrapping here?
"in the database"? That isn't necessarily true, right? So how about:
Transform stored values into the format the widget needs.
I wonder:
1) Why these are private?
2) What data means?
3) What the number does in there? ;)
So how about:
options_transform_storage_form()
options_transform_form_storage()
Transform submitted form values into field storage format.
erm. 8)
If the tests break without, then we can be sure that some code will break, too.
oh - we have a similarly named function already? Nice. :)
I guess this one flips rows to columns and vice-versa?
How about renaming to:
options_array_flip() ?
Or something else, so developers aren't confused by those function names like me currently :P
uh oh
Can we move this inline comment above the condition, and also add similar ones to the other conditions?
I'm on crack. Are you, too?
Comment #3
moshe weitzman commentedLovely. Thanks for the test coverage too. Subscribe.
Comment #4
yched commentedI'm not sure I agree, but I'm not sure I agree with this feature to begin with. The current code does this for both radios and checkboxes, I'd rather keep it as is in this patch and have this discussed in #569542: Button Option Field is Required, has One Option - Select that Option where this was introduced.
This is different. This gathers allowed values frm list_allowed_values() or taxonomy_allowed_values(), and does some extra 'option widgets'-specific massaging.
I went for options_get_options().
Well, those are helper functions for internal massaging, really. I'm not sure where we draw the line between public and private, but I don't want to make those part of an 'API'.
I went for _options_storage_to_form() / _options_form_to_storage().
Yes, I left that here for now because I'd like to find out why exactly. Besides, I'm unable to phrase a code comment explaining why we do this at this point ;-)
This does more than array_flip(): Flip rows and columns in a 2D array. That's transposition ;-)
I went for options_array_transpose().
Well, commenting if () {...} else {...} blocks is not easy above the 'if'...
I kept comments inside the blocks but tried to streamline this code a bit.
Fixed the other remarks.
+ there is still a forum test failure that beats me.
fails, while I *see* that code in the debug page HTML source.
Comment #6
yched commentedHeh, the forum test failure was only on my localhost, it seems. Strange. Would that be because of the newline in the asserted text (I'm on windows) ?
Anyway. I forgot about the 'List field' tests. Will fix those tomorrow.
Comment #7
yched commentedShould fix the remaining failures.
Comment #8
sunLovely.
Only remaining issue: This PHPDoc summary is a bit short ;) Also not sure whether the original description wasn't helpful, too.
This review is powered by Dreditor.
Comment #9
yched commentedOops, that PHPdoc was indeed not finished...
That comment was moved inside the function. That area is a WTF currently, we shouldn't hardcode anything on list_allowed_values(), and officially expose hook_options_allowed_values() but that's outside the scope of this patch. Added a @todo.
+ removed the
// @todo Apparently not needed IRL, but tests break without.mentioned above, beats me for now.Comment #10
sunGreat!
We can tackle any @todos in follow-up issues, if necessary.
Comment #11
webchickThis change looks consistent with others that Dries has committed recently, and comes with buckets of nice tests. That _0 thing is too bad; hopefully we can get that sorted out in #179932: Required radios/checkboxes are not validated once and for all.
Committed to HEAD.
Comment #12
yched commentedFollowup for the todo added in this patch: #639466: hook_options_list() + XSS filtering
Comment #13
bjaspan commentedWhy were the widget tests changed from using drupal_get_form() and drupal_render() to using drupalGet(), or in other words from being pure API unit tests to being page-request system tests?
Comment #14
yched commented@bjaspan: This allows full fledged tests, with form display + form submission - and form submission is a can of worms with option widgets.
It also makes the tests much simpler to write and maintain.
Besides, this tests 'test_entity' forms, that's what they're here for. That's also what text widget tests do.
The current tests include all the tests that were previously there.
Comment #15
bjaspan commentedIt also makes the tests much slower, less targeted, and impossible to run on the command line (at least for me). But okay.
BTW, you've done a ton of work recently while I've been MIA. Thanks!
Comment #16
yched commentedmuch slower: not really. We *need* to test form submission. So having separate API-only tests for form display and Get / Post tests for form submission would be even slower while we need the latter anyway and it allows us to make *both* tests in one pass ;-)
So yes, slower, but only because we test more stuff.
less targeted: kinda true for the 'form display' tests, but the extra layer of 'test_entity' forms is quite thin. So sure, if this layer is broken, tests are broken, but, it's a test layer, not 'node' or 'comment', that's what it's here for.
impossible to run on the command line: oh ? that needs to be fixed, but I'm not sure what might cause that. Do text tests run OK ?
BTW, I think I remember you reported something like that months ago when we started to have form submission based tests, and found a reason...
Comment #17
yched commentedGlad to have you back, BTW ;-) (typical welcome sentence between CCK / Field API maintainers)