field_behaviors_widget() is a thing from CCK D6, it is mostly stale now.
Code currently calling it to check the 'default_value' or 'multiple_values' properties of the widgets need to
- call $options = entity_get_form_display()->getComponent($field_name)
- then call WidgetPluginManager::getDefinition($options['type'])
This should probably move to a getRendererDefinition() method on the EntityDisplay class ?
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | constants-2047997.patch | 1.06 KB | asimmonds |
| #19 | 2047997-19.patch | 1.97 KB | swentel |
| #19 | interdiff.txt | 670 bytes | swentel |
| #17 | 2047997-17.patch | 1.92 KB | swentel |
| #14 | field-behaviors-widget-2047997-14.patch | 4.2 KB | jlindsey15 |
Comments
Comment #1
yched commentedtagging
Comment #2
yched commentedand tagging
Comment #3
jlindsey15 commentedI'll take this.
Comment #4
jlindsey15 commentedHere's my first try. I put it in the EntityFormDisplay class instead - that seemed to make more sense.
Comment #6
yched commentedThe first line of functions/methods phpdoc should fit in 80 chars if possible.
Maybe "Returns the definition of the renderer plugin used for a component" ?
Then the @return section could be:
"The definition of the renderer plugin (e.g. widget, formatter), or NULL if the component is not set."
As a replacement of field_behaviors_widget(), we need the method to exist on EntityFormDisplay, true.
But generally speaking, the method would also make sense on EntityDisplay objects.
So I'd suggest adding it to EntityDisplayBaseInterface & EntityDisplayBase
Should be $this->getComponent($field_name) :-)
(probably explains that patch fails to install)
Also, it should be wrapped in an if() because the field might be hidden, in which case getComponent() will return NULL:
Comment #7
jlindsey15 commentedThanks for the comments - good point about putting it in EntityDisplayBase. When I'm flip-flopping between coding in PHP and java, I always forget to do this->function() instead of just function()... I'll have the reworked patch in a bit.
Comment #8
jlindsey15 commentedComment #10
webchickSo granted I've been out of the loop awhile, but I'm a bit confused why we are ripping functions out in
"normal" tasks when we're past API freeze..?
At the very least, we should keep the old function there with a @deprecated thing, no?
Comment #11
yched commentedI'm fine with keeping the function around as @deprecated, but:
- This function makes very very little sense in D8. "Give me this property from the plugin definition of the widget used by this field".
But now that we have "form modes", there is no such thing as "the (one and only) widget used by this field". Just like "what's the formatter used by this field" makes no sense - in which view mode ?
The function currently uses the widget used in the 'default' form mode, but this makes no special sense.
- It's really a remnant from CCK D6 where widget info definitions had a 'behaviors' entry, which doesn't exist anymore. Its only possible remaining use is for "default values", and it's a sick use, that we need to get rid of anyway : #2056405: Let field types provide their support for "default values" and associated input UI
Comment #12
jlindsey15 commentedAdded it back as @deprecated, still haven't fixed the bug in the patch though. @deprecated doc may change depending on how it gets fixed.
Comment #14
jlindsey15 commentedSee comment 12 description
Comment #16
yched commentedNow that #2056405: Let field types provide their support for "default values" and associated input UI is in and the 'default_value' entry in widget plugin definitions is not supported anymore, we have no reason whatsoever to keep field_behaviors_widget().
We should really just remove it.
Comment #17
swentel commentedLet's see
Comment #18
yched commentedThis looks like this might be useless now ?
Comment #19
swentel commentedYeah, probably, let's see.
Comment #20
yched commentedLooks good if green
Comment #21
catchCommitted/pushed to 8.x.
Could use a short change notice - not much more than the image summary.
Comment #22
yched commentedCreated https://drupal.org/node/2102175
Comment #23
asimmonds commentedShould the three FIELD_BEHAVIOR_* constant definitions in field.module be removed as well?
I can't find anything in core that still uses them.
Comment #24
swentel commentedRight, duh, good catch, thanks! :)
Comment #25
webchickCommitted and pushed to 8.x. Thanks!