Roger Ineichen wrote:
> pluggableauthentication utility
>
>
> Hi Garrett
>
> From: Garrett Smith [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, June 18, 2005 7:52 PM
>> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Cc: zope3-users@zope.org; zope3-dev@zope.org
>> Subject: RE: [Zope3-dev] Utility Registration was:RE:
>> [Zope3-Users] pluggableauthentication utility
>>
> [...]
>>>
>>> What do yo think about that? Any other ideas?
>>
>> It looks like you've identified a common enough use case: PAUs are
>> typically used with a common set of plugins. The current PAU design
>> accommodates all sorts of use cases that most users would never face.
>>
>> Rather than add more complexity to the registration process with
>> "utilityPolicy" (even though it's an attempt to make things easier
>> for the user), I'd suggest creating a
>> SimplePluggubleAuthenticationUtility that supported the most common
>> use cases.
>>
>> Something like this perhaps:
>>
>> class ISimplePAU(Interface):
>> authentication = Choice(values=('HTTP-Auth', 'Session'))
>> allowUserChangeOnUnauthorized = Bool()
>> principals = Attribute("A PrincipalsFolder plugin.")
>>
>> This would be far easier to deal with than the current PAU for those
>> that don't need PAU's flexibility.
>
> I think this isn't a solution, because of three things:
>
> - You need to do this for every other utility simplification.
I guess I'm not aware of anything that has anywhere near the
configuration complexity of the PAU.
> - I dont' like to have more then one implementation if not
> absolutly needed only for configuration reason.
I don't see this as a configuration issue. For most applications, the
PAU is too flexible/powerful and I think this is source of lots of
usability questions. A SimplePAU could be implemented using adaptation
so that a new PAU type wouldn't be necessary.
> - The activation part on the registration process is still
> the same. The most problem is that we implement components
> where using the utility and lookup this utilities by a special
> name or unnamed. But nobody tells you what name should be used
> during registration.
I think the delineation is named vs. unnamed. I agree with Stephan and
Jim that utilities that are used without names should not ask for names
-- those that use names should require them. I would add (this has
probably already been added, don't recall) a utility should have some
way of communicating that interface or interfaces that it could be
registered for. E.g. it doesn't make much sense to register the PAU for
IAnnotations.
But to reiterate -- the PAU registration does *not* accept a name value
and does *not* let the user register for anything other than
IAuthentication. I haven't heard anyone complain about the registration
issues of PAU since that change.
> I still think a policy (somthing like a add wizard) whould solve
> the problem. Developers can develope the registration process in
> a pytho class and register tehm as a "utilityPolicy". Then
> administrators or scripters can add the utility witha simple klick
> on a "add predefined utility" button.
This sounds like a lot of work for the developer.
> On nice sideeffect whould be,
> You could also add a policy "Add all utility I need for a site".
> Or even call this policy during makeSite on your special
> implementation of IPossibleSite.
I do like this idea. This is in the spirit of the server bootstrap
module that ensures that a particular set of utilties are available and
configured on startup.
I definitely think something likethis is needed for the "Make a Site"
action.
So, perhaps something like this:
<siteconfig
name="foo.bar.mysite"
title="My Site"
description="Create my cool new site."
configurator=".configMySite" />
This would setup a menu and register an adapter to something like
ISiteConfig that would be used to configure a newly created site.
> I think this is what we need at the enduser level and should be
> possible to implement. Of corse the way we register utilites whould
> be still available.
-- Garrett
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
