[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