ServiceProviderInterface and Silex

[cilex]

ServiceProviderInterface and Silex

[mvriel]

Actually my intention was to allow Cilex to support both \Cilex\ServiceProviderInterface and \Silex\ServiceProviderInterface extensions. This way you do not have a hard dependency on Silex but you can re-use extensions.

The only problem is that a lot of extensions have \Silex\Application as a hardcoded dependency; to ally for compatibility should this be \Pimple (which both Silex and Cilex share as common ancestor)

[igorw]

I have tried to move the ServiceProviders from silex to pimple in the past, but it's not so easy to do, because many of them rely on $app->before and $app->after. I'm not sure if there's any easy way to move those out.

But I agree it would be cool to have pimple-only ServiceProviders that can be re-used without silex.

[henrikbjorn]

Couldnt it be possible to create a Cilex\SilexServiceProvider which takes a Silex\ServiceProvider and just calls register on it?

[lsmith77]

alternatively if there would be some interface like PimpleApplicationInterface, then the ServiceProviderInterface could maybe be moved to Pimple as well?

[jmikola]

What methods would PimpleApplicationInterface have? Are you thinking of register(ServiceProviderInterface $foo)?

Adding interfaces to Pimple just to support the common functionality of Silex and Cilex could be invasive. Pimple is beautiful as a one-file library, and this is a bit like turning it into Doctrine Silex Common.

[lsmith77]

@jmikola yes .. register() is what i was thinking .. but agreed that its kinda ugly dumping this into Pimple .. not sure if there is an alternative place where we could share this.

[jmikola]

In terms of extracting a common Silex ApplicationInterface, there are definitely parallels between Silex applications and Cilex. When you consider the Symfony Console component differentiates between commands and applications, matching command names is similar to Silex's routing. So before() and after() could be repurposed as setup and tear-down hooks for CLI commands. I think the term for this is middleware?

If we extracted that interface in Silex, we could depend on it (if only for the interface).

[jmikola]

This is a bit off topic, but a friend of mine just pointed me to Flask-Script, which seems very close to what we're doing here: extracting a CLI framework from a micro web framework, albeit in Python. Here's an example of it in action: https://github.com/jmoiron/jmoiron.net/blob/master/manage.py

[beberlei]

bump

[lsmith77]

@igorw what was the solution we discussed at phpday again? simply type hinting pimple and then checking if the relevant methods exist?

[igorw]

Yes, however we have done some work on the silex service providers to move non-service related calls into a separate boot() method. The register() method is still typehinted to Silex\Application though. Maybe we can change it to Pimple.

[mvriel]

I would need to review the new changes but using Pimple as base class could work well

[mvriel]

For the record: @igorw has submitted a PR at the Silex repository to attempt to make Cilex and Silex compatible on a ServiceProvider level. The PR and its discussion can be found here: https://github.com/fabpot/Silex/pull/352

[mvriel]

Is there some way we can move this forward? The more Cilex is being used the more I get the feeling people want shared ServiceProviders (for example @simensen). I know there are several PRs out there but discussion seems to stagnate around them

[gimler]

ping

[cordoval]

bump, wondering what is the resolution of this

[cleentfaar]

Same here, @mvriel I've done my own attempts at this, so far with equal results, any news on your side?

[mvriel]

Unfortunately not; I have lowered the priority for this myself as there are more pressing matters that need my attention. I do not see a lot of movement here

[mvriel]

It would seem that Pimple version 2 now has a common ServiceProviderInterface that is used by Silex. I think it is time for Cilex v2 that makes use of that functionality ;)