Stop using listeners for data extraction

[lcobucci]

Fix #15

This simplifies the deserialisation engine by moving away from events and allowing users to append data via object decoration.

We should remove the deprecated components on the next release.

@dsantang @rdohms can you please help me ensure that we don't break all your apps?

[dsantang]

Hey @lcobucci, thanks for looking into this, the change you made does indeed fix the issue.

I also think this solution is really nice in terms of extendibility.

The change you introduced shouldn't affect our existing Clients since it's done in a BC way.

If I'm not mistaken, as an upgrade path, the existing Clients should start removing the:

@Serializer\SerializedName(IdGenerator::GENERATED_ID)

From the id property to be compatible with the next major release.

[lcobucci]

Hey @lcobucci, thanks for looking into this, the change you made does indeed fix the issue.

I also think this solution is really nice in terms of extensibility.

🎉

The change you introduced shouldn't affect our existing Clients since it's done in a BC way.

If I'm not mistaken, as an upgrade path, the existing Clients should start removing the:

Correct! There's also the possibility of decorating the decorator (if needed):

$extractor = new AppendGeneratedIdentifier(
    new AppendGeneratedIdentifier(
        new UseInputData()
    ),
    '_input.id'
);

That would send both id and _input.id down to the serialiser - which can be kept until annotations are removed from everywhere.

It's important to remember that, if I'm not mistaken, you had some other event listeners which will need to be migrated to the new way of extracting data - they shouldn't be affected until the removal of the deprecated components, though.

[lcobucci]

I'm just thinking about moving the interface and these extractors to chimera/foundation since they can be reused by another serialiser if we want.

[rdohms]

@lcobucci do you have an example of replacing an injector with this decorator? Just to help migration path, maybe add this to an Upgrade.md?

Use case: a injector that uses $context->getInput()->getAttribute('some-req-data'); and injects it into $event->setData

Or is this not affected?

[lcobucci]

That injector doesn't need to be changed immediately after this release, only when we remove the deprecated components.

IMHO this is a good example:

https://github.com/chimeraphp/foundation/blob/master/src/MessageCreator/InputExtractor/AppendGeneratedIdentifier.php#L24-L34

I'll be documenting stuff soon but I'm terrible at that so any help is appreciated.

[rdohms]

We can help with the docs, also this PR then becomes a bit more self-documenting.

How do we hook up a InputExtractor? is there a new tag?

[lcobucci]

The idea is to rely on the SF DI decorator feature (using the interface as decorated service).

Something like:

<service id="MyCustomExtractor" decorates="Chimera\MessageCreator\InputExtractor">
    <argument type="service" id=".inner"/>
</service>

[rdohms]

Aaah, interesting, did not know that. Nice.