[dev] [commits] Horde branch master updated. 549a1a57841717f032d1d95e86d10679297356e1

[Jan Schneider]

Zitat von Gunnar Wrobel <p at rdus.de>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Gunnar Wrobel <p at rdus.de>:
>>
>>> commit 549a1a57841717f032d1d95e86d10679297356e1
>>> Author: Gunnar Wrobel <p at rdus.de>
>>> Date:   Mon Aug 30 09:12:59 2010 +0200
>>>
>>>   Added the Interfaces package.
>>>
>>>   Rationale:
>>>
>>>   When looking at the Kolab_Session package I realized that
>>>   "Horde_Auth::getAuth()" calls have been converted to
>>>   "$GLOBALS['registry']->getAuth()". While this may be fine on the
>>>   application level I don't think it is acceptable on the level of a
>>>   framework package.
>>>
>>>   "$GLOBALS['registry']->getAuth()" does pretty much the same as
>>>   "Horde_Auth::getAuth()" did before and the move of the functionality
>>>   into the registry is absolutely fine.
>>>
>>>   For Kolab_Session this does however mean that the dependency on that
>>>   functionality gets further obscured. Something has to setup
>>>   $GLOBALS['registry'] before Kolab_Session is called into the mix.
>>>
>>>   At the same time I think the package would now need to pull in Core as
>>>   a dependency which I wouldn't like much either.
>>>
>>>   I think it is a cleaner solution to provide the Interfaces package. It
>>>   can be used to clearly define the communications between Core and the
>>>   other framework packages. This also allows to declare the dependencies
>>>   in an obvious manner and decouples low level libraries from the BIG
>>>   Core thing.
>>
>> I still don't get the rationale, because you add yet another  
>> interface level - the registry and injector objects already are  
>> interface between packages and between applications and packages.
>>
>> In this certain case, you shouldn't access getAuth() in your  
>> package at all, but get the authenticated user injected at some  
>> point.
>>
>
> "the authenticated user" seems to be represented by Horde_Registry  
> though. If it would be represented by Horde_Auth then I could inject  
> it without adding the Core dependency. I'm currently not deep enough  
> in the authentication layer to determine what would be needed to  
> move getAuth() back to the Auth package.
>
> What I could however do would be to check if the functionality I  
> need the getAuth() information for couldn't be replaced/removed.  
> This is only a sanity check after all and it might not be necessary  
> anymore. Will look into that.

The point is that you shouldn't *pull* in the user name through  
getAuth() at all, no matter which interface defines this method. If a  
user name is required for a package, it should be *injected*, e.g.  
into the constructor from the consumer code.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/