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

Skip to content

[Messenger] Document the ActivationMiddlewareDecorator #10035

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
ogizanagi opened this issue Jul 9, 2018 · 5 comments
Closed

[Messenger] Document the ActivationMiddlewareDecorator #10035

ogizanagi opened this issue Jul 9, 2018 · 5 comments

Comments

@ogizanagi
Copy link
Contributor

ogizanagi commented Jul 9, 2018

Relates to symfony/symfony#27320

This middleware is used to enable/disable a middleware based on an arbitrary condition. Main use-case is for maintaining a unique list of middleware across environments, but disabling/enabling some in test env for instance (but there are many others). It accepts either a simple boolean or a callable returning a boolean.

Usage when using the component standalone should be straightforward enough, but not as obvious when using within the framework.
When used with the framework, it leverages Symfony DI capabilities (using service decoration). It can uses a simple parameter value, the result of an expression, or even a callable injected in its constructor (by extending the decorator or by using DI):

TestOnlyMiddleware: ~

test.TestOnlyMiddleware:
    class: Symfony\Component\Messenger\Middleware\Enhancers\ActivationMiddlewareDecorator
    decorates: TestOnlyMiddleware
    arguments:
        - "@test.TestOnlyMiddleware.inner"
        - "@=parameter('kernel.environment') === 'test'"

using an invokable service:

TestOnlyMiddleware: ~
ActivationStrategyService: ~ # invokable service

test.TestOnlyMiddleware:
    class: Symfony\Component\Messenger\Middleware\Enhancers\ActivationMiddlewareDecorator
    decorates: TestOnlyMiddleware
    arguments:
        - "@test.TestOnlyMiddleware.inner"
        - "@StrategyService"

using a method of a service as a closure (dynamically executed, as previously):

TestOnlyMiddleware: ~
ActivationStrategyService: ~

test.TestOnlyMiddleware:
    class: Symfony\Component\Messenger\Middleware\Enhancers\ActivationMiddlewareDecorator
    decorates: TestOnlyMiddleware
    arguments:
        - "@test.TestOnlyMiddleware.inner"
        - ["@StrategyService", 'isEnabled']

Note: a more concise syntax can be used leveraging anonymous services:

TestOnlyMiddleware:
    class: Symfony\Component\Messenger\Middleware\Enhancers\ActivationMiddlewareDecorator
    arguments:
        - !service { class: TestOnlyMiddleware }
        - "@=parameter('kernel.environment') === 'test'"

[...]

@Koc
Copy link
Contributor

Koc commented Sep 16, 2018

I think would be nice use more real-life example. For example we are using DoctrineTransactionMiddleware but there are some long-running commands. This causes to very long transactions.

Solution: decorate DoctrineTransactionMiddleware with ActivationMiddlewareDecorator and pass some invokable service with blacklisted long running commands. WDYT?

@ogizanagi
Copy link
Contributor Author

ogizanagi commented Sep 16, 2018

@Koc : This seems to be very specific to me (but most of the use-cases of this feature are). I thought the env condition was one of the most straightforward ones to showcase and understand for readers. But I'm not against other suggestions :)

@carsonbot
Copy link
Collaborator

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link
Collaborator

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

@carsonbot
Copy link
Collaborator

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants