Use DI container to load global middleware classes

[clue]

This changeset makes sure we use the same DI container instance to also load global middleware classes. This allows us to take advantage of autowiring for global middleware classes the same way it can be done for route request handlers as implemented in #92. This does not otherwise break existing APIs, so this is a pure feature addition.

Builds on top of #92 and #89

[HLeithner]

What's the benefit not directly use the PSR container interface?

[clue]

@HLeithner One step at a time 👍 We love standards and we'll definitely add PSR-11 support in a future PR 💯

We've already added an outlook on a future integration with #92 here: https://framework-x.org/docs/best-practices/controllers/#container-configuration

[HLeithner]

I have seen it but I'm not sure what's the benefit to create an own interface that you want to replace or glue to the PSR-11 afterwards but maybe I don't see the complete picture yet.

[clue]

@HLeithner Very good points, there are of course pros and cons to everything!

We've tried to lay out our philosophy in the documentation (https://framework-x.org/docs/getting-started/philosophy/), in particular:

• make easy things easy & hard things possible
• Batteries included, but swappable
• Reuse where applicable, but accept some duplication

In the current version, the Container class is entirely internal (see @internal annotation), this targets points 1 and 2. In a future version, you'll be able to swap it out using your own container, this targets points 1 to 3.

You're right that it's hard to see the full picture with the current PR. Let's continue this discussion in the follow-up PR when the container API will be made public?

I very much appreciate your input and we're actively looking into ways to get the community more involved. Let's set up a discussion thread to see if another meetup etc. would be an idea? 👍

[HLeithner]

Ok thanks for the answer and it makes sense based on the philosophy.

Sure meetup is always welcome.