When creating a computed field and overriding FieldItemList, you must compute values when ::get is called and when ::getIterator is called. Failing to do so for either case leads to bugs that can be very difficult to track down.
Initially I ran into this here: #2817565: Bugs in ModerationStateFieldItemList mean it can never be used with a field formatter but I also ran into this again writing a test for #2852067: Add support for rendering computed fields to the "field" views field handler.
Introduce an abstract class which ensures values are calculated correctly for all of the required FieldItemList methods.
Discuss.
None.
API additions only.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2857301-computed-field-item-list-3.patch | 807 bytes | sam152 |
Comments
Comment #2
sam152 commentedComment #3
sam152 commentedThis is a possible implementation. It's a bit iffy in the sense it's not driven by an interface, but doing so would require exposing a public method, which I don't think is desirable here.
Comment #4
dawehnerThis sounds interesting! Do you have an plans to let some of the core computed fields extends this class? I guess having a concrete example of this class could be helpful, even if it is just for documentation reasons.
Comment #5
berdirSee #2846554: Make the PathItem field type actually computed and auto-load stored aliases, what I suggested there is to use #2392845: Add a trait to standardize handling of computed item lists for this, the pathauto issue also shows that this is needed on field item list and field item classes, and also the magic methods.
Comment #6
amateescu commentedLet's do this in the existing issue for "fixing" computed fields: #2392845: Add a trait to standardize handling of computed item lists