search

PHP-DI / Symfony-Bridge

PHP-DI integration with Symfony
http://php-di.org/doc/frameworks/symfony2.html
Other
17 stars 11 forks source link

better configuration options #11

Closed Rastusik closed 8 years ago

Rastusik commented 9 years ago

What about making the symfony bridge more configurable (similarly to the zf2 bridge)? People wouldn't need to write the whole container initialization. I suggest creating a proper PhpDiBundle for Symfony, with a Container factory and with support for the Symfony configuration files.

I already started with the implementation, you can see the work in progress in my fork: https://github.com/Rastusik/Symfony2-Bridge

Also I'd like to create a console command to be able to clear the php-di (similarly as in the zf2 bridge).

mnapoli commented 9 years ago

I'm not sure how it would work because currently we create the PHP-DI container when the Kernel is created. Maybe it's possible.

However I'm not a huge fan of the idea. Having to implement, document and (for users) learn a different API for configuring the container doesn't sound really useful. I hate when I have to use a Symfony bundle that integrates a library and I can't use the official library's documentation because the bundle offers custom configuration keys.

For example a problem with the ZF2 bridge is that I can't use all the features of PHP-DI. E.g. I can't use all the caches available.

Rastusik commented 9 years ago

well, all the features can be implemented (also in zf2 bridge) if somebody requests them.

I didn't want to change the process of the PHP-DI container creation, I just wanted to wrap the code into a factory and create configuration options for it. It works perfectly by the way, I have a demo. My point is that the container creation process messes up the AppKernel class and there might be use cases, where you can't configure your cache in the AppKernel because of various dev and prod environments. Also cache clearing would be united in the console command and would be able to use the cache configuration for the given environment.

I think that when some basic work is done, it would be really easy to implement all the possible configuration options afterwards, after people request them.

It's just an idea, I can maintain my own fork, I just wanted to let you know.

In the worst case, nobody can force the user to use the factory, since it would be called from the extended appKernel, current way of integration would be still possible.

Rastusik commented 9 years ago

btw the same case is with the zf2 bridge, I can update the docs with the former info about the way of usage, which is still possible to apply

mnapoli commented 9 years ago

all the features can be implemented (also in zf2 bridge) if somebody requests them

(emphasis mine) That's the point. Users are dependent on the maintainer willing and having time to support such features. And they have to wait for it. It doesn't really matter if it's easy to add after all, if it's not there it's not there and users are stuck. Most users wouldn't bother opening an issue btw, they would just realize it's limited when they try out the project and drop it.

It also introduces coupling with a specific version. If some new options are added (e.g. php-di/php-di#299) then every framework bridge needs to be updated to support this new option (and it usually takes time). Same goes if some options are removed in major versions.

I'm not totally closed to it though, especially if you think there are benefits.

Rastusik commented 9 years ago

Well the decision is up to you :) I have mentioned the benefits (especially the clear cache command, and custom configuration for different environments).

Current usage can be applied as well, if it's always mentioned in the docs, so I think it's a win-win :)

Maybe some of the users will go with the current way and will find limitations and will open a feature request after all, since they won't find a better DI container elsewhere.

I think I would be able to implement such feature requests since most of them would be only about being able to configure the container. But even if not always, there will be ways to fallback to the current solution for some time.

mnapoli commented 8 years ago

I'll close this. I want bridges to be as simple as possible: users should be able to configure PHP-DI the same way whatever the framework is. It also avoids having to implement options and document everything twice.