field_attach_view() docs have some accuracy and other issues [#2009092]

Comment	File	Size	Author
#14	field_attach_view_doc-2009092-13.patch	2.33 KB	smiletrl

#14	interdiff-8-13.txt	677 bytes	smiletrl
#8	field_attach_view_doc-2009092-6.patch	2.33 KB	smiletrl

#8	interdiff-4-6.txt	1.35 KB	smiletrl
#4	field_attach_view_doc-2009092-3.patch	1.46 KB	smiletrl

Comment #1

she/her

English

CreditAttribution: jhodgdon commented 3 June 2013 at 19:43

Thanks for reporting this!

I didn't understand your suggested wording, so I think it must need a little bit of work. :) It should probably either give some more details of the process, or link to a topic/function/class that contains those details.

Log in or register to post comments

Comment #2

smiletrl CreditAttribution: smiletrl commented 4 June 2013 at 00:58

lol...

See Introduced EntityDisplay config entities

Display options for a field are not specified in the $instance definition structure anymore.
The $instance['display'] entry no longer exists, $field and $instance definitions structures are purely about data, not about how render it.

and

Display options need to be explicitly assigned to the EntityDisplay objects :

See class EntityDisplay

    // Instantiate the formatter object from the stored display properties.
    if ($configuration = $this->getComponent($field_name)) {

So, there're no display options in instance definiton. Instead, EntityDisplay $display associated with this entity will store all attached fields' display options, that's how field_attach_view going to render each field.

Log in or register to post comments

Comment #3

jhodgdon

she/her

English

CreditAttribution: jhodgdon commented 4 June 2013 at 01:36

Title:

Field is displayed according to the display options specified in the EntityDisplay object

» field_attach_view() docs have some accuracy and other issues

Ah, OK. Then we can probably just say:

Each field is displayed according to the display options in the $display parameter.

Right?

Anyway, if we're in there let's fix up that whole documentation block:
- There's at least one namespace reference that does not start with a backslash (in the $entity parameter; perhaps others as well).
- What is this "sample structure" thing supposed to be? I bet that's just left over from a previous version of Drupal?
- $options says to see field_invoke_method() for details, but it doesn't mention that $options['langcode'] is set in the function and would override any value passed in.

Log in or register to post comments

Comment #4

smiletrl CreditAttribution: smiletrl commented 4 June 2013 at 09:00

File	Size
field_attach_view_doc-2009092-3.patch	1.46 KB

Yeah, $display parameter makes it clear.

Well, indeed, there's some other namespace reference that does not start with a backslash, but I'd like to cover this issue here:)
"sample structure" is an array result returned by this function, e.g., $result = field_attach_view($entity, $displays[$entity->bundle()], $langcode); "sample structure" tells what $result looks like.
Add a note for 'langcode'.

Patch attaced accroding to #2.

Log in or register to post comments

Comment #5

smiletrl CreditAttribution: smiletrl commented 4 June 2013 at 09:01

Status:

Active

» Needs review

Log in or register to post comments

Comment #6

jhodgdon

she/her

English

CreditAttribution: jhodgdon commented 5 June 2013 at 12:30

Status:

Needs review

» Needs work

If the "sample structure" is a sample return value, then it should be moved down so that it is part of the @return documentation. As it is, I couldn't figure out at a glance what it was supposed to be. I'm also not sure that we need to have a sample return value here, since it's returning a renderable array (at least according to the documentation). I'm also not sure we want to *maintain* a sample return value in this documentation. We don't do that for other functions that return renderable arrays.

So... maybe we should just get rid of that? If not, move it to @return.

Other than that, the changes look good to me, thanks!