jonathanjfshaw

I was inspired by your work here to work on this for #157, now updated. But I ended up needing to take a much more complex tack similar to what...

Initial discussion about this happened a long time ago on the extension-side at https://github.com/jhedstrom/drupalextension/issues/337

Entity and field plugins should serve to remove about 12+ methods from the drivers, so they're a step on this process of taming the monolith. I have wondered if the...

I've completed initial development of an entity and field plugin/wrapper system, see PR #157. ## Benefits *Customisation*: users can add special handling for new field or entity types, or override...

I think label is used so that steps can reference existing entities by their label, rather than a numeric id which is less natural for step authors.

See also See also #117 and #133 for discussions addressing this problem

@pfrenssen > but in the scope of DrupalDriver it doesn't make sense to use labels. It seems that the whole point of the current field handlers is to convert from...

Not necessarily, there's a bigger architectural issue here about how responsibilities are divided.

Yeah, the handlers have got some nasty idiosyncratic variations in how they expect properties to come to them. I had to do some awkward dancing to maintain BC on some...

I've got an old PR for that on the extension: https://github.com/jhedstrom/drupalextension/pull/300 I'm using it as a composer patch, works OK. Doesn't use this new plugin goodness from the driver side,...