Helper issue for "EntityDisplay"

Kickstarting again, we really really need this for field group, ds and let contrib go nuts! :)

Should fix the remaining tests.

This should be green

#45: entity_display-testbot-1848068-44.patch queued for re-testing.

#71: display-handlers-testbot-1848068-71.patch queued for re-testing.

Hi, I am looking for the @todo interface in the patch.
Just a question, could it be there is a left over in the patch: there are two abstract class DisplayComponentHandlerBase files. I think the "Drupal\entity" namespaced one is not used anymore?

Just keeping up with HEAD

Oh right, custom blocks and datetime field have landed too

reviving, branch opened in sandbox : entity-display-components-1875974 (I kind of lost the old one apparently)

Had to merge a lot, got notices on standard install, want to give this a roll though.

Fix discovery

More obvious fixes

Seriously

Messy merge with HEAD, let's see what the bot thinks.

#89: 1848068-89.patch queued for re-testing.

re-kickstarting (for the 4th time) on top of the new form modes patch, let's see how this works out.

- also - I switched branches - 1875974-entity-components

This should have a lot more fixes - a little too much code duplication, need to clean that up at some point.

Use 'type' again instead of formatter

Fix more tests, amateescu made the pluginmanager to modern times

Reverted some stuff and fixed the default config files.

Renamed the 'widget' handler type back to 'field'.

Fixed all getComponent() and setComponent() calls.

More fixes - should fix a lot of notices in the upgrade path

Even more fixes

Helping this forward, fixing some tests.

aspilicious, can you commit those fixes to the sandbox also ? 1875974-entity-components

I'm a good boy did that *before* posting this patch :D

New patch against latest HEAD

More fixes, getting close to green (again).

Fix tons of notices

Started to work on this but I got very confused when I got to DisplayComponentHandlerBase::getRenderer() because we also have a getRenderer() method in EntityDisplayBase. Was the original intention to move it from the config entity class to the new plugin type (component handler)?

Posting just an interdiff for now, nothing committed anywhere :/

Suppose $type should be optional for getComponent(), we already store handler_type in display so 123 could work
But for setComponent() we need to know the the type of component!

Merged current HEAD and made some clean-up, all pushed to 1875974-entity-components-andypost

..drop is moving

I could install and some of the field stuff worked, lets see

Now without upgrade path tests

Should fix most problems, I hope

More fixes! Less notices!

Lets try this one

Less notices on this one.

Fixed some minor issues

Another reroll

No configuration is prepared so a lot of tests fail

Another set of changes:
- fix for massageIn() that executed for non-existing field - needs some research
- field handler now injects needed services
- some doc blcok fixes
- added todos

Renamed massageOut() => onComponentGet()
Decoupled massageIn() => onComponentSet() and onComponentRemove()
Added doc-blocks

In the onComponentSet function you need to "change" the options and return the new options.
You're returning a new array overriding the past options.

==> test fails :)

should fix failed tests, Field handler needs better check for removed field

Merge after #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title

Let's test with interface

check merge

fix errors

EDIT open again #2210177: Use getSetting() in comment formatter

One more

Use core's pattern to get field definitions

render pipeline should change, this just a hack that not commited