On 5/26/09 1:50 AM, Malthe Borch wrote:
> 2009/5/25 Chris McDonough<chr...@plope.com>:
>> So to the end of breaking them apart, I just wrote up a bit of science
>> fiction
>> in code form. Could you take a look at the below and let me know what you
>> think?
>
> It's very clear.
Cool. I've implemented most of it on the "authchanges" branch (with slight
modifications). Some more tests need writing, but it's about done. I'm not
sure if this will land in 0.8.2 or if I'll start a new 0.9 series or what.
I actually bagged the ISecurityPolicy adapter I described in the first email
entirely, and instead you register an effective security policy using a ZCML
directive like so:
<securitypolicy
authentication="repoze.who.authentication.RemoteUserAuthenticationPolicy"
authorization="repoze.who.authorization.ACLAuthorizationPolicy"
/>
Both authentication and authorization above are adapters (the authentication
one
adapts on both context and request, while the authorization one just adapts on
context).
As a result, "mortal" users will not be expected to need to use any ZCA stuff
to
work with the authentication or authorization APIs; instead they use stuff like
"authenticated_userid", "has_permission", etc (which under the hood consult
both
effective authentication and authorization adapters as necessary). While doing
testing, they can use the repoze.bfg.testing API to prevent needing to register
adapters against the authorization and authentication interfaces directly.
> In terms of style, for interfaces that represent would-be adapters,
> how do you feel about something like:
>
> def __init__(context):
> """Adapter. ``context`` is ..."""
>
> Perhaps less ZCA-savvy users will find this style more informative in
> terms of what's really going on.
If I haven't hidden the presence of interfaces (and other ZCA abstractions)
deeply enough that no one will ever need to know they're there, I've kinda
failed, because they really are an implementation detail. I don't use them for
docs in repoze.bfg, so folks who don't know ZCA won't be reading them much
anyway.
Thanks!
- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
