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.
Problem/Motivation
See the parent issue for problem motivation. This issue covers the following elements:
- Checkbox
- Checkboxes
- LanguageSelect
- Select
- TableSelect
- Radios
- Radio
- Weight
Proposed resolution
The idea here is to add more documentation to render/form elements, basically what is currently in the old Form API reference, or similar to that. No docs standards are changing right now; just trying to get more information into each form/render element class.
This patch covers a group of related form elements; other issues on the parent cover other groups of elements.
Beta eval: This is just API docs improvements, so not frozen.
Comment | File | Size | Author |
---|---|---|---|
#34 | interdiff-2486979-32-34.txt | 501 bytes | ashutoshsngh |
#34 | 2486979-34.patch | 6.51 KB | ashutoshsngh |
#32 | interdiff-2486979-30-32.txt | 809 bytes | ashutoshsngh |
#32 | 2486979-32.patch | 6.51 KB | ashutoshsngh |
#30 | 2486979-30.patch | 6.51 KB | metzlerd |
Comments
Comment #1
metzlerd CreditAttribution: metzlerd commentedComment #2
metzlerd CreditAttribution: metzlerd commentedComment #3
metzlerd CreditAttribution: metzlerd commentedComment #4
metzlerd CreditAttribution: metzlerd commentedComment #5
metzlerd CreditAttribution: metzlerd commentedQuick stab at first for feedback.
Comment #6
jhodgdonI took a quick look at the initial patch. Some thoughts:
I think maybe this needs some additional text. Like before that #return_value line, maybe something saying "Here are some notes on the properties:" or something like that... if that line is even needed. Probably it's useful.
And before the @code section, something like "Usage example:"
Also that usage example doesn't use #type = 'checkbox' so ... somewhat suspicious ;)
Comment #7
metzlerd CreditAttribution: metzlerd commentedLooking at existing FAPI description seems redundant, but I'm thinking yes to reinstating headings such as....
Properties:
Usage example:
Comment #8
jhodgdonYeah. I think I'd avoid listing all the properties for now though, since we still need to figure out what to do to document them. Mostly they're all the same, like '#title" for instance, and we really really really don't want to have to list them all on each element. Very difficult and tedious to maintain, not to mention tedious to do in the first place. So that is why I suggest a heading here conveying "some special notes on properties" at least for the time being.
Comment #9
metzlerd CreditAttribution: metzlerd commentedAgreed, I thought about calling them Important Properties or Relevant Properties or something like that but when documenting API classes, I wasn't really sure that it would make sense.
Ideally the general ones would be documented on the inheritance chain, (for example in FormElement) and/or with see also links, but maybe we should have this discussion on the standards thread rather than this one. I was a bit surprised to not see the expected inheritance chain in all elements such as the "Color" element.
It seems like Tel, Color, Date and others are all special cases of Textfield, but they aren't in the chain that way. That means we'd have to put a lot of property documentation in FormElement, but maybe that's ok. I could't really see documentation of the "visual" properties like "#size" and such. These may be in theme functions, but the source isn't obvious from looking at the classes.
Comment #10
jhodgdonYeah. Well, for now let's just make sure we have notes about the special properties, and you can just make a bullet list with a line before it something like:
Property notes:
Maybe we'll end up putting the documentation about the generic properties on the defgroup topic, or on the base class, but we definitely don't want it repeated on every element class.
Comment #11
metzlerd CreditAttribution: metzlerd commentedHere's the first file containing all the listed files. There's a little redundancy with #options, but given that it actually has different restrictions between select and checkboxes this seems sane to me. Thoughts?
Comment #12
jhodgdonLooks great, thanks! I think the things you've repeated make good sense.
A few small suggestions and formatting errors:
I think the Properties sections would be better formatted as bullet lists. See https://www.drupal.org/node/1354#lists
Applies to all the classes in the patch.
Should be a blank line between these two lines.
Let's be consistent and either always call it Properties or always Property notes. Either is OK with me.
The first line of any doc block should be a one-line description ending in .
Added docs should go in a new paragraph.
Also these lines go over 80 characters. There are numerous places in the patch that do this, please check it over.
And Drupal should be capitalized... although probably best to reword this so it doesn't actually say "Drupal" at all, like saying it's used in the Form API?
What is a "radios control" anyway? Probably should stick to standard terminology and call it an "element"?
Over 80 characters.
Probably should say "radio button" at the end not just "radio"?
This should end in . Is it possible to put some explanation in here too, rather than referring to a drupal.org page that may not be available to someone who has the Drupal source code?
This looks unfinished?
Comment #13
metzlerd CreditAttribution: metzlerd as a volunteer commentedHere's another patch to evaluate. I struggled a bit with rewording the tableselect descriptions to make it conform to buttons, so let me know if that sounds awkward. I think I tackled most of the other issues.
Comment #14
jhodgdonThis is looking much better!
Probably one more iteration and we'll have it... A few suggestions:
Much better here!
In the second line:
radios form element => elements
Then... Don't say "Please". See https://www.drupal.org/node/604342 (search for the word "please" there) for some reasoning on this.
And any class name needs a namespace.
So we would like it to say something like:
See \Drupal\Core\Render\Element\Radios documentation for more information.
No blank lines between list items.
Rather than making them into nice prose sentences like "#options is an associative...".
Comment #15
metzlerd CreditAttribution: metzlerd as a volunteer and commentedNext pass. Thank you for the prompt reviews.
Comment #16
metzlerd CreditAttribution: metzlerd as a volunteer and commentedComment #17
jhodgdonThis all looks excellent to me now. Thanks very much for the patches!
Comment #20
alexpottNot using the full 80 characters width.
I think this example is problematic because using a t()'d string as the key means the value would change if the translated value is changed.
Comment #21
metzlerd CreditAttribution: metzlerd as a volunteer and commentedThat will teach me to copy existing examples. Here's the patch taking into account these changes. Out of curiosity is there a known way in PHPStorm to auto wrap these things for the future?
Comment #22
metzlerd CreditAttribution: metzlerd as a volunteer and commentedComment #23
jhodgdonHm, I gave this latest patch a review and found a few more things to fix... which either I missed in my last few reviews or things changed in this last patch?
This still doesn't go out to 80 characters.
"the value is label displayed" ... hm, a bit awkward? Sorry didn't notice this in the last review.
What's a "selection element"?
What's a "selection table"?
select -> selects
Needs to end in .
Still not up to 80 characters.
Comment #24
metzlerd CreditAttribution: metzlerd as a volunteer and commentedAnother try.
Comment #25
jhodgdonThis is much better! I think we could still improve the wording and consistency of wording between the various #options descriptions:
This is still a bit difficult to read, I think...
Suggestion:
... where the keys are the returned values for each radio button, and the values are the labels next to each radio button.
Looking at this vs. Radios, I think maybe we shouldn't say #return_value here. We should make it like my suggestion for Radios above.
I guess I'm not sure what this means, and we shouldn't use #return_value or #default_value in this text. It isn't a #default_value for sure. It's just a value.
This is better written than the others. ;) But it should probably say "associative array".
Comment #26
ashutoshsngh CreditAttribution: ashutoshsngh at Srijan | A Material+ Company commentedAddressed #25 changes.
Comment #27
jhodgdonWhen you make a new patch on an issue, it is normal/helpful to make an Interdiff file. Next time, please do so; don't bother now on this issue since I've reviewed the patch provided. Thanks for the new patch, anyway!
So this is getting better... still not quite there:
Can we revise this similar to what was suggested in #25?
Specifically I would suggest since this is a Checkboxes element:
An associative array whose keys are the values returned for each checkbox, and whose values are the labels next to each checkbox.
Actually they aren't "select elements", they are options, and the labels are not "next to" the options, they are what's shown in the drop-down list.
So this needs a rewrite.
In the #empty_value property just below here, also don't call it "select element"
take out "of key value pairs". That is what an associative array is, so it's redundant.
Also it should be the "keys are" not "key is". Same for "values" not "value".
Comment #28
deepakaryan1988re-rolling the patch with the modification in #2486979: Document Select/list elements
Comment #29
jhodgdonGood, still a few things to fix:
This section still could be wrapped better -- should be closer to 80 character lines. I wouldn't have mentioned it at all but there is something else to fix in the patch anyway...
each options -> each option
select element -> option
key -> keys
hm... Well given the rest of the sentence, you either need to make it keys are / values are or each key is / each value is. I don't care which, but make it consistent/parallel wording.
As long as we're fixing things, maybe make this -10 and 10?
Comment #30
metzlerd CreditAttribution: metzlerd as a volunteer and commentedComment #31
jhodgdonAlmost!
One typo: should be "each key is the value [no s] returned"
Another typo: should be "an example".
Whoops. Also I just checked this link and I think it should be https://www.drupal.org/node/945102 [2 missing at end of URL]
Comment #32
ashutoshsngh CreditAttribution: ashutoshsngh at Srijan | A Material+ Company commentedComment #33
jhodgdonThanks! But see comment #31 item 2 - patch still says "a example".
Comment #34
ashutoshsngh CreditAttribution: ashutoshsngh at Srijan | A Material+ Company commentedComment #35
jhodgdonGreat! I think it's all good now.
Comment #38
jhodgdonComment #39
alexpottThis looks like a really nice improvement. Committed 1403239 and pushed to 8.0.x. Thanks!