Tactician v2

[simPod]

I started working on v2

• How to do debug command? With v2 the command handler map is not known in advance, mapping is done in runtime through locators. We would need inverse locator for this.
• Tests
• Update readme
• Tag based mapping/handling stuff
• should DoctrineMiddlewarePass, SecurityMiddlewarePass, ValidatorMiddlewarePass be part of this?
• Let's only support modern versions of Symfony
• Maybe we can move more of this out of the config.yml and more into the services.yml. Most of the work around the config.yml is just doing multiple command buses and adding middleware to them. These are tasks that I think would be better off in the services.yml where it's much simpler for folks to manage and work with them, instead of guessing at the autogenerated names (which are a repeatedly filed bug). The only services we need to auto generate then are the command locators, so maybe there's no need for the config.yml work at all.

[rosstuck]

Hey, thanks for getting the jump on this. I confess I'm not using Symfony anymore so I was dreading this a bit. 😅

To answer some of your questions:

• My thought with the debug command is to use MapByStaticList instead. As I recall (and it's been a bit), the compiler passes built a static list of all the mappings ahead of time and then built it into a a ContainerBasedHandlerLocator. So, the MapByStaticList does basically the same.

• The compiler passes for Doctrine, Validator and Security middleware could all be split out into separate packages (splitting out the Validator stuff into a separate package has been requested a few times). That said, I honestly didn't have the energy or patience for the additional package management work that would entail.

• I see the tag based mapping/handling stuff was deleted in this PR but I think it might still be needed. Don't forget, the bundle has some other features base tactician doesn't have (yet) like detecting mapping based on typehints.

Also because I haven't written these down anywhere, here's my paper sketch ideas for Bundle 2.0

• Let's only support modern versions of Symfony

• Maybe we can move more of this out of the config.yml and more into the services.yml. Most of the work around the config.yml is just doing multiple command buses and adding middleware to them. These are tasks that I think would be better off in the services.yml where it's much simpler for folks to manage and work with them, instead of guessing at the autogenerated names (which are a repeatedly filed bug). The only services we need to auto generate then are the command locators, so maybe there's no need for the config.yml work at all.

Anyways, none of that second part is a hard contract, just something to keep in mind. :)

[simPod]

@rosstuck The problem with debug command is, that we know only handlers on container build.

The mapping happens in CommandHandlerMiddleware by running $this->mapping->getClassName($commandClassName).

We would have to implement reverse mapping and run handlers through it to generate mapping up front. Currently, I don't see a way to do it 🤔

[simPod]

I see the tag based mapping/handling stuff was deleted in this PR but I think it might still be needed. Don't forget, the bundle has some other features base tactician doesn't have (yet) like detecting mapping based on typehints.

I decided to revisit it when the rest is done. After looking into it for a while, does not seem that trivial.

[simPod]

Just to be sure, it's correct to drop service locator, amirite?