Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workflow demonstration #3

Closed
wants to merge 5 commits into from
Closed

Workflow demonstration #3

wants to merge 5 commits into from

Conversation

Crell
Copy link
Owner

@Crell Crell commented Oct 31, 2018

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.)

@Crell Crell closed this Jan 16, 2019
@Crell Crell deleted the workflow branch January 16, 2019 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant