On 08.11.2010, at 11:36, Fabien Potencier wrote:
> On 11/8/10 5:26 PM, Lukas Kahwe Smith wrote:
>>
>> On 08.11.2010, at 11:22, Fabien Potencier wrote:
>>
>>> On 10/29/10 6:07 PM, Benjamin Eberlei wrote:
>>>> Problem 1: One Service Id only has one static implementing class
>>>>
>>>> Say we have a Templating Service id "templating" and a class
>>>> "MyTemplateEngine". This is used throughout your project whenever
>>>> a controller needs a template engine. Now someday you have a need
>>>> for a second "MyNewTemplateEngine", but you don't want to replace
>>>> the old one for all the old controllers.
>>>>
>>>> The DIC Factory option is a possible solution here, but the DIC
>>>> container is a pattern to avoid having to write factory classes.
>>>> Why starting again?
>>>
>>> If you need a second template engine, you need another service,
>>> with a *different* name:
>>>
>>> templating templating.smarty
>>>
>>> Problem solved.
>>
>>
>> yes. the idea of "context" doesnt propose anything else. its about
>> how to select the right service dynamically. aka if the request wants
>> a json response that you pick the right view to generate a json
>> response.
>
> My point was that we don't need "context". That adds a new layer of
> complexity for no added benefit.
the idea of context builds on top of what is there to make it easier to manage
dynamic selection of services:
- DIC uses the context as a post/prefix when doing look-ups, f.e.:
->get('templating') with context 'json' looks for a service 'templating.json'
- there is a defined list of possible context's, enabling the DIC to
automatically generate the fallback's if there is no explicit service to
prevent any additional overhead to the lookup of services at runtime, f.e.: i
define that there are 3 possible context 'html', 'pdf', 'json' and i only
define a 'templating.json' and a 'templating.pdf', then 'templating.html' will
automatically be aliased to 'templating'
- the context can be set in the route (and constructor, though the later this
is done in the request the higher the risk of some confusion as the DIC becomes
seemingly "non deterministic")
Of course when injecting the container rather than actual services into a
controller, it could be possible to add such a layer as well inside the
controller that adds a postfix to service looks ups. However it would mean that
it would be up to the user of said controller to ensure that all variations of
services are defined explicitly. With such a layer the controller would
optionally expect the user of the controller to define optional service names
and the controller author could also explicitly support post/prefixing service
names with some dynamic value (for example the output format) along the lines
of:
https://github.com/lsmith77/symfony/commit/ac9e5a7a9fe050ae0c3ae1397fae1f4287e1a6a8
However this means that DIC look-ups get a tiny bit of overhead, that the
burden of ensuring that all services are properly configured for all variations
is in the hands of the user of the controller and that this would be
incompatible with injecting services explicitly.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
