[dev] Injector musings
Gunnar Wrobel
p at rdus.de
Sun Aug 1 07:55:04 UTC 2010
Hi Micheal,
Quoting Michael M Slusarz <slusarz at horde.org>:
> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> Thus, the need for something like:
>>> $contents = $injector->getInstance('IMP_Contents', 1 .
>>> IMP::IDX_SEP . 'INBOX');
>>> $contents2 = $injector->getInstance('IMP_Contents', 2 .
>>> IMP::IDX_SEP . 'INBOX');
>>>
>>> Then later on, when I call
>>> $injector->getInstance('IMP_Contents', 1 . IMP::IDX_SEP . 'INBOX');
>>>
>>> I will get the $contents object that was previously instantiated.
>>
>> Ah, okay. So I think what's called here for is a factory. Something like:
>>
>> $contentsFactory = $injector->getInstance('IMP_Contents_Factory');
>> $contents1 = $contentsFactory->getContents(1, 'INBOX');
>> $contents2 = $contentsFactory->getContents(2, 'INBOX');
>>
>> ... etc. The factory can internally manage whether or not a
>> contents object has been created before.
>
> If someone could check out what I just did re: Horde_Editor, that
> would be great. Seems a bit of overkill in that I had to create a
> binder to point to a factory which, in turn, creates the Editor
> object. But I can't figure out another way to do it given the
> current injector API (injector factories do not provide any help
> here).
I think what you did was exactly in the direction of what Chuck
suggested. And I also believe this is how it should be done.
I don't think we can replace every singleton pattern we had before
with a simple Injector binder. This is only possible in case the
singleton always delivered the same instance (e.g. we used static
private $instance = new Something()). What you were referring to are
the singletons that delivered a number of different instances and were
using something like
static private $instances[md5(serialize($params))] = new Something($params)
In these cases the injector can only return a generic factory (like
you did with Horde_Editor). At that point the Injector becomes
irrelevant. It only holds the factory and that is all.
Any instances delivered by the factory are the job of the factory. So
the factory instance should keep them in a private array that may be
named $instances and that is not static anymore.
The important point is that instances such as IMP_Contents are not
(cannot be) managed by the injector.
Concerning the Horde_Editor factory: The only thing I'd tend to change
would be to modify the binder so that it is bound to
'Horde_Editor_Factory' (as it does not directly deliver a
'Horde_Editor' object). You could create a Horde_Editor_Factory class
in the Horde_Editor package though that might make things more
complicated as this probably should not have knowledge of
Horde_Browser and the Horde configuration (which
Horde_Core_Factory_Editor currently has). Maybe Horde_Editor_Factory
should just be an interface that is being implemented by
Horde_Core_Factory_Editor.
Cheers,
Gunnar
>
> As mentioned previously, the current injector API seems to have a
> limitation when it comes to run-time configuration. In other words,
> objects that require the same standardized setup but may contain
> different data depending on the run-time environment.
>
> michael
>
> --
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>
More information about the dev
mailing list