[dev] [commits] Horde branch master updated. 104e3198ce8b82e1a469dce43420d2d6fa7e2a7d

[Michael Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>>>
>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>
>>>>>
>>>>> commit e433901b802136256a094ae1f870853e7f512e02
>>>>> Author: Michael M Slusarz <slusarz at curecanti.org>
>>>>> Date:   Wed May 26 11:34:06 2010 -0600
>>>>>
>>>>> Refactor Horde_Db injectors.
>>>>>
>>>>> Forgot that individual subsystems could potentially define a custom SQL
>>>>> configuration.  Therefore, we need a Horde_Db injector with a
>>>>> factory/singleton to override the base DB for these subsystems (and
>>>>> reuse the base DB object if no custom config is given).
>>>>>
>>>>> Rename Horde_Db_Adapter_Base to Horde_Db_Base and change to a shortcut
>>>>> to return the base Horde DB object.
>>>>>
>>>>
>>>> This breaks being able to find other objects' Horde_Db dependency  
>>>> automatically using type hints. e.g., The various Content_Type_*  
>>>> classes depend on Horde_Db_Adapter_Base, but now the injector's  
>>>> dependency finder can no longer locate the binder since it has  
>>>> been renamed to Horde_Db_Base.
>>>
>>> In other words Horde_Db_Adapter_Base just needs to be changed to  
>>> Horde_Db_Base there (?)
>>
>> No, because that's not the name of the class that it depends on.  
>> The injector can automatically resolve an object's dependencies by  
>> looking the type hints in that object's constructor - it then,as I  
>> understand it, looks for a binder that matches the name of the  
>> class that it depends on. Changing the name of the binder from  
>> Horde_Db_Adapter_Base to Horde_Db_Base messes this up, as the class  
>> we are looking for is not Horde_Db_Base.
>
> As mentioned in the post to Chuck, the problem is that this assumes  
> that Horde_Db_Adapter_Base will always be a single object in any one  
> Horde installation.  But there can be a bunch of different  
> Horde_Db_Adapter_Base objects that will be used based on the local  
> configuration.

This is a good point.

>
> I changed the name as such simply because 'Horde_Db_Adapter_Base'  
> was confusing in that regard - that there was one DB object to rule  
> them all.  However, I see the need to have that name defined as such  
> for these type hinting binding cases.  I have no problem renaming  
> the Horde_Db_Base binder back to Horde_Db_Adapter_Base to provide an  
> easy injector to the default horde DB setup.

This would save us from having to inject the db object explicitly  
and/or create binders for those classes where the dependencies can  
otherwise be automatically resolved, and the default horde db is  
desired. Though I do agree that the name could seem a bit confusing...

-- 
Mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Reality is merely an illusion, albeit a very persistent one." - A. Einstein