-
Notifications
You must be signed in to change notification settings - Fork 42
Extend example of $eventSubscribersByEventName #46
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
Conversation
@holtkamp Awesome. I remember I came across the same question. I would add space after comment start: Otherwise fine 👍 |
doc/event_bus.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that is how I got it configured now:
- the FQCN is a string, which will be instantiated by the serviceLocator
- then the function is ran again, the acquired object will be used and the notify method is executed (ok, when it exists...)
What part is not true do you think?. Maybe the text should be
.. and invoke $instance->notify() if the notify() function exists
@holtkamp Thanks for adding this useful piece of information to the docs! If you could fix my comment please and also add a space after the "//" as @TomasVotruba mentioned, then I can merge and publish this. |
@matthiasnoback, just added the spaces and commented on your note. Additionally, what do you think of the suggestion to leave out the mandatory ServiceLocator. Only 2 out of the 5 identified ways to configure the EventHandlers depend on it. For beginners on this topic a ServiceLocator might confuse users... Just my 2 cents 😉 |
@holtkamp Thanks. It turns out I was wrong - the service locator accepts a string argument. I just didn't think about using it like this (i.e. instantiating the class in the service locator callable) :) Could you please rebase this branch on the latest master? It seems that this branch is outdated. Leaving out the service locator was indeed an option in one of the earlier designs. However, I feel that every application using a command bus should use lazy-loading for command handlers, since otherwise the application would have to instantiate all handlers and all dependencies upon boot time. So, I'd like to just leave it as it currently is. |
Conflicts: doc/event_bus.md
Still learning about git, seems my GitHub Desktop automatically pushed an incomplete merge. Hope it is ok now... |
Hi there, I decided to dive into the code myself and make the description a little bit more complete and to also copy the same description of these "callables" to the command bus section. |
Great! Thank you for sharing this flexible tool, your knowledge and
|
@holtkamp :) |
When trying to configure an EventBus, the part of registering event subscribers was not totally clear to me. Some questions I had:
The it struck my that my approach was using:
Which is a valid callable, passing the
is_callable()
check, and therefore the method was invoked statically. Eventually I went for the $fqcn approach, which then uses the ServiceLocator to instantiate the classname.Not sure whether the suggested approach improves readability, just want to underline that it can be clarified a bit... I also think the ServiceLocator overcomplicates the example, maybe introduce a simpler plain CallableResolver that does not require / use a ServiceLocator? When handing over callables, this seems a more obvious approach opposed to requiring a ServiceLocator that is never used.