Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Workflow] Undeprecate Registry::get #51400

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

Closed
ro0NL opened this issue Aug 16, 2023 · 8 comments · Fixed by #51976
Closed

[Workflow] Undeprecate Registry::get #51400

ro0NL opened this issue Aug 16, 2023 · 8 comments · Fixed by #51976
Labels

Comments

@ro0NL
Copy link
Contributor

ro0NL commented Aug 16, 2023

Description

Hi,

Our system relies heavily on getting a workflow from a object, aka Registry::get()

It was deprecated in #46000

But this seems to defeat dealing with many workflows that have a different support strategy, aka framework.workflows.N.supports, aka WorkflowSupportStrategyInterface

At this point im wondering what the alternative way is, or why supports configuration still exists?

Example

No response

@derrabus
Copy link
Member

cc @lyrixx

@ro0NL
Copy link
Contributor Author

ro0NL commented Aug 16, 2023

note, im not recommending registry usage per se, but getting a workflow dynamicly was in fact a 1st class feature

@lyrixx
Copy link
Member

lyrixx commented Aug 16, 2023

@ro0NL what kind of implementation of WorkflowSupportStrategyInterface do you have?

Can you inject all services tagged workflow and pick the right one directly?

@ro0NL
Copy link
Contributor Author

ro0NL commented Aug 16, 2023

we use default InstanceOfSupportStrategy thru supports: [classA, B] in semantic config

i can resolve it in userland, but then i agree one needs #51227, or maybe leverage the service locator keys

however, it feels weird to let users deal with supports configuration, whereas Registry::get, did and can do it for us

IMHO, if we take this route, both framework.workflows.N.supports and WorkflowSupportStrategyInterface should be deprecated as well

overall i just dont think it's really worth it 😅

@lyrixx
Copy link
Member

lyrixx commented Aug 16, 2023

IMHO, if we take this route, both framework.workflows.N.supports and WorkflowSupportStrategyInterface should be deprecated as well

I would like to do that indeed. But twig need it. But we could simplify too.

Since there are many report about this deprecation, I'm really thinking about reverting it!

But honestly, this is sub-optimal IMHO. There is no lazy loading :(

@ro0NL
Copy link
Contributor Author

ro0NL commented Aug 16, 2023

right, it seems WorkflowExtension needs the registry for the same reasons

what about injecting the workflows as a service locator in the registry, and a 2nd locator with only the corrresponding WorkflowSupportStrategyInterface

@ro0NL
Copy link
Contributor Author

ro0NL commented Aug 22, 2023

happy to see deprecation dissappear, or crash 🍿

@lyrixx
Copy link
Member

lyrixx commented Oct 10, 2023

see #51976

fabpot added a commit that referenced this issue Oct 10, 2023
This PR was merged into the 6.4 branch.

Discussion
----------

[Workflow] Revert deprecation about Registry

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | Fix #51662, fix #49199, fix #51400
| License       | MIT

Commits
-------

56757f3 [workflow] Revert deprecation about Registry
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants