who has implemented the service container?
Lukas Kahwe Smith
We are currently in the process of updating our company internal framework [1] to use several of the symfony components. The service container component seems to be the one that poses the biggest challenges since there are several conceptual issues to address. As such I am looking for other implementations of the service container to see how things work there.
Here is a short list of issues we have faced:
1) Where to keep the SC instance?
First up we were unsure how to deal with optional dependencies and also how to deal with services that load other services. So the first approach that came to mind is that we basically inject the service container with everything. But that seemed ugly and magical. Upon further consideration it became clear that this wasnt needed at all. We now make an instance of the SC container inside the front controller and we pass it into the controller and store it there. Thats all.
There is now a syntax for optional dependencies [2]. If a service really needs to load additional services (say for example various modules who's names are pulled out of the database during the request), then that service should simply create a new service container instance.
2) How to deal with shared instances that need to be reloaded
We have faced this situation in our unit testing framework [3]. Since we are faking a request we need to effectively be able to reload a clean version with new parameters. Obviously we could add some method to do this cleanup, but it seems error prone and adding this feature seems trivial
3) Service container caching
We have run into a few issues when caching the service container config into a PHP file. For one there seem to be some issues in regards to handling of parameters [4]. There is also the issue that if you want to automatically want to update the cache when underlying files have changed, that there is no easy way to find out which files were read (this is how symfony 1.3 works in development mode). For example an extension (aka plugin) could define a few services. These config files are bundled with the extension and therefore do not reside in the global configuration directory and imported inside the yaml files via the "imports" directive. Therefore its no sufficient to just scan that directory for the last updated file. Therefore we asked to get the list of files read during a call to load() so that we can cache this information for later reference when determining if the cached file needs to be updated [5].
4) who will maintain the pre 5.3 versions?
I noticed that the support for optional dependencies was only added to the 5.3 version of the service container. Who will ensure that such features also get added to the pre 5.3 version? How important will be compatibility between the two versions? Obviously the 5.3 version uses namespaces and I assume we will also see the use of closures etc.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
[1] http://svn.liip.ch/repos/public/okapi/core/branches/symfony2/
[2] http://trac.symfony-project.org/ticket/7648
[3] http://trac.symfony-project.org/ticket/7569
[4] http://trac.symfony-project.org/ticket/7677
[5] http://trac.symfony-project.org/ticket/7645
Lukas Kahwe Smith
On 30.11.2009, at 13:16, Lukas Kahwe Smith wrote:
> 4) who will maintain the pre 5.3 versions?
>
> I noticed that the support for optional dependencies was only added to the 5.3 version of the service container. Who will ensure that such features also get added to the pre 5.3 version? How important will be compatibility between the two versions? Obviously the 5.3 version uses namespaces and I assume we will also see the use of closures etc.
I didnt get an answer to any of my questions, but I guess the key one is the above. Would love to hear an answer. IMHO the API should be as similar as possible, so while I could raise my hand to take this over, it would be kind of weird to maintain something where the entire job would be to back port someone elses code. However at this point it seems I need to consider a fork as key features are missing for me in the ServiceContainer, some of which have been fixed in the 2.x version.
Fabien Potencier
I have not enough time to do everything by myself. It should be pretty
easy to backport things from the 2.0 branch to the 1.0 one. If you are
willing to help me on this side, that would be wonderful.
Fabien
>
> regards,
> Lukas Kahwe Smith
> m...@pooteeweet.org
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Symfony Components" group.
> To post to this group, send email to symfony-c...@googlegroups.com.
> To unsubscribe from this group, send email to symfony-compone...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/symfony-components?hl=en.
>
>
>
Lukas Kahwe Smith
On 28.12.2009, at 22:04, Fabien Potencier wrote:
> On 12/28/09 3:20 AM, Lukas Kahwe Smith wrote:
>>
>> On 30.11.2009, at 13:16, Lukas Kahwe Smith wrote:
>>
>>> 4) who will maintain the pre 5.3 versions?
>>>
>>> I noticed that the support for optional dependencies was only added to the 5.3 version of the service container. Who will ensure that such features also get added to the pre 5.3 version? How important will be compatibility between the two versions? Obviously the 5.3 version uses namespaces and I assume we will also see the use of closures etc.
>>
>> I didnt get an answer to any of my questions, but I guess the key one is the above. Would love to hear an answer. IMHO the API should be as similar as possible, so while I could raise my hand to take this over, it would be kind of weird to maintain something where the entire job would be to back port someone elses code. However at this point it seems I need to consider a fork as key features are missing for me in the ServiceContainer, some of which have been fixed in the 2.x version.
>
> I have not enough time to do everything by myself. It should be pretty
> easy to backport things from the 2.0 branch to the 1.0 one. If you are
> willing to help me on this side, that would be wonderful.
ok ..
i should try and look to get started on this early next year.
i will then also propose a few patches to get the issues fixed that i filed.
Fred Grott
might be using DI at some point pre5.3..
Later on I might be able to get some free time to lend a hand once
things settle down into a more less frazzled state..