Slim integration

[bas-i-nl]

Hi,

has anyone done any thinking on integrating php-di with the Slim web framework/thingie?

This is basically a Slim web app:

index.php:

$app = new \Slim\Slim();

$app->get('/orders(/:page)', function ($page = 1) use ($app) {
    $app->render('orders.twig', array( 'page' => $page ));
});

I could do it hardcoded of course but was wondering if someone came up with something better.

[mnapoli]

Not me at least. That's an interesting idea though, if I have some time I will even try to provide integration with container-interop which would allow to use any container (not just PHP-DI).

[bas-i-nl]

Read about container-interop, I'll look into it.

[marleyiam]

Also interested about I'll check it out. Cheers!

[juliangut]

Hi, I've created a bridge container to integrate PHP-DI into Slim3 that is currently under development, meaning the implementation might change and so the bridge container might too, but nevertheless it is working in current Slim 3.x-dev branch

Have a look at it juliangut/slim-php-di every comment is welcome

[mnapoli]

Hi @juliangut, this is really great to hear! I started working on such an integration a few weeks ago but didn't push anything online (because still WIP), so I'm happy to see it happen.

I have a few remarks: Slim 3 will support container interop, so maybe implementing ArrayAccess is not necessary. In order to provide the default Slim services, these could be registered in a config file that would be automatically included by the PHP-DI - Slim bridge.

Another idea that I wanted to implement (and I'd love to hear what you think of this) is to use the same mechanism as what's used in Silly i.e. dependency injection in closure parameters. This one was a bit trickier to implement because of Slim's architecture, that's why it's still not finished.

[juliangut]

Hi @mnapoli, it is true ArrayAccess might not be necessarry as I was commenting with @akrabat yesterday ContainerInterface doesn't provide a set interface, but when implementing juliangut/slim-controller I realized that in the end most of the people will use Slim's default container and never change to any other so they will expect to be able to set services with ArrayAccess, and so I coded the controller Registrator

About DI on Closure routes callback, Slim already has routing strategies such as \Slim\Handlers\Strategies\RequestResponseArgs and so it could be modified to include service extraction from Container which is actually a great idea as we'll have DI for Closures and both in classes construction AND method callback invocation so you can require dependencies just for a method and not the whole class

[mnapoli]

I guess what I want to do is a Slim version based on PHP-DI completely. So it would not just be a PHP-DI integration, but almost a different framework. This probably means that there's room for both: a PHP-DI integration for people who want to use Slim's default API + PHP-DI, and those who are rather interested in using a micro-framework built on PHP-DI and who don't care about Pimple and the Slim service providers.

[juliangut]

Well actually if ArrayAccess is what makes you think about forking Slim into a modified PHP-DI centric micro-framework, it really is a small change I already implemented on the bridge class, no big deal and no change into PHP-DI, is sort of what Acclimate does but small and focused.

[juliangut]

By the way, this weekend Pimple ServiceProviderInterface was dropped from Slim3 so this dependency that drew back from using Slim services into other DI containers is gone now

[mnapoli]

Well actually if ArrayAccess is what makes you think about forking Slim into a modified PHP-DI centric micro-framework

It's not really that but a combination of:

• no ArrayAccess, use PHP-DI config arrays instead + dependency injection to get services
• dependency injection in middlewares and in closures (both in callable parameters as well as constructor injection if controllers/middlewares are classes)
• different way of registering controllers: you can put any callable as well as anything supported in https://github.com/PHP-DI/Invoker#resolving-callables-from-a-container - Actually I want to replace the part in Slim that invokes controllers/middleware with this: https://github.com/PHP-DI/Invoker (so that 1) it's really generic and 2) it's super powerful and configurable)
• Slim modules might not all be compatible, so it might be necessary to write and provide "PHP-DI modules" (e.g. Twig, …)

Quite a big change in the end, and all this would require a whole dedicated documentation. That's why I mentioned that it's more like an extension of Slim rather than just using PHP-DI in Slim.

By the way, this weekend Pimple ServiceProviderInterface was dropped from Slim3 so this dependency that drew back from using Slim services into other DI containers is gone now

Interesting! Do you have more info? I just read this https://github.com/slimphp/Slim/issues/1438 but how do modules register services then?

[juliangut]

Services registration is now developer's duty

$container->set('flash', function () { return new \Slim\Flash\Message});
// or
$container[`flash`] = function () { return new \Slim\Flash\Message};

So now it is truly container independent, unless for any reason you need a helper to register the services for you, in which case you must use ArrayAccess ;(

And you can make your service depend on another thanks to ContainerInterface get method, nice

[mnapoli]

OK, I wonder how Slim's users will have to register the "modules"/service providers, e.g. Twig (if it's automated, how will it work if it's truly container agnostic). I'll dig into that later.

[bradynpoulsen]

I use PHP-DI with slim as my primary container. I did implement a super class that checks if a dependency is available in slim container first then the DI\Container. Granted, this is assuming you're looking into slim/slim ^3.0

$app = new Slim\App($myContainer);

class MyContainer implements ContainerInterface
{
    public function __construct(DI\Container $primary, Slim\Container $slim)
    {
        $this->primary = $primary;
        $this->slim = $slim;
    }

    public function get($id)
    {
        if ($this->slim->has($id)) {
            return $this->slim->get($id);
        }
        return $this->primary->get($id);
    }

    public function has($id)
    {
        return $this->slim->has($id) || $this->primary->has($id);
    }
}

[mnapoli]

FYI I've been working for a week on a bridge: https://github.com/PHP-DI/Slim-Bridge I'm planning to take this bridge a little further than the others (Silex, Symfony, etc.) and offer modules (like the Pimple service providers) using Puli and PHP-DI config files. Here is an example: TwigModule.

[akrabat]

👍

[mnapoli]

@akrabat I was planning on contacting you a bit later but since you are lurking if you have feedback it will be most welcome ;)

[akrabat]

The general path you're taking looks interesting for using PHP-DI with Slim. No particular feedback at the moment.