Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a simple demonstration of how listeners could be registered that care about more than just the event type. In this case we show off how to register a workflow name, which is an arbitrary string. I have omitted ordering for now as it's not relevant to this demonstration.
As shown in the test (see line 33 of WorkflowProviderTest), this allows us to register listeners for
A) A workflow event and name.
C) All workflow events for a given workflow name.
E) All workflow events of any type for any workflow.
The C and E cases would be difficult or impossible to do if the event were identified by a string only, unless the string were non-opaque and had to be parsed internally. (Say, a format like
workflow.start.bob
, and some provider knew to break it up at the periods and that each segment meant something specific.) That would require either defining a parsing algorithm that all implementers MUST follow (which sounds like a terrible idea) or allowing the string to be meaningful to only certain provider implementations. However, that opens the door for collision and confusion; if a workflow library used the string format defined above, and were run in the same environment as another library that had another, incompatible format... what happens? I don't know, but it's probably not pretty.It might be possible to sort out that confusion with careful string parsing and informal conventions, but 1) String parsing is slow and the devil and 2) Replacing informal conventions with formal ones is the whole point of PSRs.
The DelegatingProvider is included as a demonstration of how such a workflow-specific provider could be slotted into a larger workflow; register it as the provider for
WorkflowTaskInterface
, and it gets used instead for those while anything else falls through to the default provider. Then the DelegatingProvider can be passed to the TaskProcessor, and the entire system can sill have a single entry point to task processing, workflow or otherwise. (Or not; you can have a separate instance if TaskProcessor if you want, that's cool.)