-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Configure a handler to subscribe to messages by their interface/parent class #27076
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
Comments
Maybe related to #27034 ? |
In theory you could decorate the bus and dispatch e.g. an |
Yes, this is how I handle this situation with simple-bus. Alternatively, a middleware could be used. However, I feel like placing the logic in the handler would make understanding/debugging/refactoring easier. |
I think that this is the right one. But I'd do this when registering the handlers within the FrameworkBundle when the message is an interface or abstract class :) |
Right, that's when I could easily make a helper trait: class MySubscriber implements MessageSubscriberInterface
{
use MyMessageSubscriberHelper;
public function __invoke(MyInterface $event)
{
// ...
}
protected function getHandledInterface(): string // abstract method in MyMessageSubscriberHelper
{
return MyInterface::class;
}
} |
Or, if public static function getHandledMessages(): iterable
{
return new MessageImplements(MyInterface::class);
} |
static function configureHandledMessages(Configurator $config)
{
$config->handleMessageClass(MyMessage::class):
$config->handleMessageInterface(MyInterface::class):
}
|
Now that |
for the record, this proposal has been rejected, see #27034 (comment) @kbond could be worth giving it a try. The iterable should yield only basic arrays of course. |
Can we try to find a smaller scope for this discussion? "Determine handled messages dynamically" is too broad. Is it about "Configure a handler to subscribe to messages by their interface/parent class"? 🤔 |
Sure, I changed the title. What about an alternative |
… (sroze) This PR was merged into the 4.2-dev branch. Discussion ---------- [Messenger] Allow interfaces to be type-hinted as well | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #27076 | License | MIT | Doc PR | ø Interfaces can be type-hinted as well for the message handlers. Commits ------- 2dbbfbd Allow interfaces to be type-hinted as well
Well great, but how do I avoid sending the message to multiple handlers now if one message extends from another? |
@kojidev Please consider opening a new issue with enough details to reproduce, comments on closed tickets are likely to be lost. |
With
MessageSubscriberInterface::getHandledMessages()
we can return an array of classes that should be handled but this requires knowing the exact classes before hand. What if we wanted all messages that implement an interface to be handled by a handler?One solution I came up with was to loop through
get_declared_classes()
inMessageSubscriberInterface::getHandledMessages()
and return the classes that implement an interface but this seems clunky (and perhaps error prone).Any thoughts on how we can handle this?
The text was updated successfully, but these errors were encountered: