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

[Gunnar Wrobel]

Quoting Jan Schneider <jan at horde.org>:

> 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.

Ah, now I get it. Sorry for being slow. Will fix ASAP.

Cheers,

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
>
> -- 
> 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
>