[dev] [commits] Horde branch master updated. 549a1a57841717f032d1d95e86d10679297356e1
Gunnar Wrobel
p at rdus.de
Sun Sep 12 10:36:00 UTC 2010
Quoting Michael M Slusarz <slusarz at horde.org>:
> 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.
>
> This change was not meant to be permanent - it was only meant to
> allow the packages to continue to work while we move them over to an
> injectable framework.
Ah, good to know. So will this move back eventually?
>
> See, e.g., the Auth or Identity factories for examples on how to
> inject a username into a package.
>
As far as I can see both use the getAuth() call from the registry to
get the user information. Or did I misunderstand you?
> And if a certain library is so tied up in authentication related
> stuff, it should be living in Core (or, at worst, in a separate
> package that has a required dependency on Core).
Agreed. The getAuth() function is rather trivial though and if I
understood your comment from above correctly then it does not
necessarily need to live in Core. I would assume that it is sufficient
to define a package that knows how Horde authentication information is
being stored in the session storage. Which the "Auth" package did
before.
> For Kolab stuff, I would imagine this might be the best tactic - or
> is the expectation that the Kolab-Horde integration code will be
> used in areas outside of just installing Horde applications?
All the other components are being used in
non-Horde-application-context (which is why this PEAR packaging of the
framework is so important to me). The Kolab_Session package is the
only one I solely use on the application level at the moment. It
stores additional user information in the session so that I don't have
to call LDAP for this. So currently a dependency on Core might
actually be okay. But in the long run it could of course still happen
that I have to use this code in a non-Horde context if the Kolab
community decides to move away from Horde. Of course my job is to try
to avoid that :)
Anyhow: For now I can check if I actually need the sanity check that I
use the auth information for. If not, I can revert this.
Or - if you tell me the method will be moved out of Core soon - I
could revert then.
Cheers,
Gunnar
>
> 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