Closed codeguy closed 6 years ago
I'm not a fan of this as the PHP ecosystem has no standard way for registering services. 👎
Having written a PHP-DI integration I'm interested by this change, but I think that users should not be left by themselves to use a container.
For what it's worth here is what I did with Silly's documentation:
Slim could have a documentation for DIC + list of supported containers (like Zend Expressive). Whether those would be external links or internal docs is a detail, I'm 👍 to write some documentation for PHP-DI if that's of any interest.
And by "supported containers" I mean what @geggleto means: containers that have the default services registered.
I'm not a fan of this as the PHP ecosystem has no standard way for registering services.
Maybe you could have a look at https://github.com/container-interop/service-provider ? It has been WIP for some time but it's getting more and more stable. With a final push we could make a 1.0 and it could benefit Slim, just like with container-interop? Also that solution is so simple it is extremely easy to support in any DIC so it would be an improvement from the current DefaultServicesProvider
.
And by "supported containers" I mean what @geggleto means: containers that have the default services registered.
+1 for this. Especially since I just released Slimbox.
Maybe you could have a look at https://github.com/container-interop/service-provider ? It has been WIP for some time but it's getting more and more stable. With a final push we could make a 1.0 and it could benefit Slim, just like with container-interop?
Completely agree with @mnapoli . What Slim needs is a way to put its services into any container. As long as this is not possible, Slim will have to provide packages with pre-configured containers (like Slimbox). You should definitely have a look at https://github.com/container-interop/service-provider since this will solve this issue for all containers. This is still work in progress. We are currently working on passing PSR-11. As soon as this is done, work on container-interop/service-provider will start again and we are quite close to a 1.0. Also, any help is welcome :)
Theory Code
$dic = \Some\Container(); //implements ContainerInterop
$app = new \Slim\App(); //Slim maintains all of its own components
$app->setDIC($dic); //DIC required for Class:method route calls, otherwise slim calls it with a no-argument constructor
$app->setResponseFactory(new ResponseFactory());
$request = (new RequestFactory())->buildFromGlobals();
$response = $app->run($request);
print (new Render())->output($response);
Not totally sure about the factories, but theory code doesn't look too far out of left field.
@akrabat as I mentioned in another issue, w/o the factories I am not sure how we can fully decouple from our own PSR-7 implementation. The factory approach was the only one I could come up with.
Where would Slim use a Response object? The new ErrorMiddleware?
Ah. Are you thinking about helping users create Response-independent middleware?
@akrabat Yes :)
Why not using an automatic dependency injection, auto dependency resolution instantiation ? like https://github.com/rdlowrey/auryn
@0x13a Slim will continue to support third-party containers that implement the container-interop
interface. But Slim will not provide it's own built-in container.
Fixed by #2290
It seems that Silex (and probably Pimple as well) will reach its EOL in 2018; so this is a good news Slim no longer rely on it :)
Hi @trasher Pimple is not dead and still alive.
Here is a statement from fabpot: https://github.com/silexphp/Pimple/issues/243
Ha ok :) I've read the project was looking for a new maintainer some months ago... Did not know they've find one.
Anyways, not relying on pimple is still a good thing ;)
The DIC will become 100% optional. Slim will no longer provide its own default container, and we can remove the dependency on Pimple.
We'll need to migrate the built-in object dependencies elsewhere, perhaps the built-in HTTP decorator classes.