-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Description
Description
Proposition is to add a new #[AsMessage]
attribute for messenger messages, which could serve many purposes.
Simple use case
First one here: replace the framework.messenger.routing
section in configuration allowing the user to directly set the targetted transport on classes.
namespace App\Message;
use Symfony\Component\Messenger\Attribute\AsMessage;
#[AsMessage(transport: 'async')]
#[AsMessage(transport: 'other')]
#[AsMessage(transport: ['foo', 'bar'])]
class AddProduct
{
}
Easy one, using a bit of reflection to read the attribute in the Symfony\Component\Messenger\Transport\Sender\SendersLocator
class is enough.
Note: I also researched a way to put this introspection inside a middle, but routing seem to happen prior to that.
@stof mentionned that messages are not services in #33912 (comment) which makes the attribute non parseable during container compilation, in this use case, that's not a problem since we can read it at runtime in the senders locator.
I think that in order to allow user to override hardcoded attributes, the framework.messenger.routing
project configuration must override #[AsMessage]
the attribute: this also solves some testing related use cases as mentioned by @rela589n in #33912 (comment)
More complex use cases
It was mentionned in the same issue the need be able to alias messages, for example: App\Message\AddProduct
-> add_product
:
namespace App\Message;
use Symfony\Component\Messenger\Attribute\AsMessage;
// Names are here for the sake of example
#[AsMessage(alias: 'add_product', legacy_aliases: ['backward_compat_add_product'])]
class AddProduct
{
}
For this to work and in order to be able to map from an alias to a PHP class name, it is required that names are registered prior runtime, hence during container compilation.
This is a problem because it forces the messages to become services. Any ideas about that ?
Example
No response