[Zope-dev] refactoring site functionality

[Chris McDonough]

On 5/28/09 11:00 AM, Martijn Faassen wrote:
> Hey,
>
> Jim Fulton wrote:
>> 2. I think local configuration address use cases that most people
>> don't have but introduce complexity that I bet a lot of developers
>> trip over.
>
> I think there are two cases where people typically deal with local
> configuration:
>
> * setting up local utilities (for authentication, the catalog,
> application-specific configuration storage + UI)

I suppose the original reason authentication was made a local utility is for the 
management UI.  I've never actually seen the Zope 3 management UI for 
authentication data.  But FTR, as far as authentication goes, I very seldom 
require a context-sensitive "user folder" for an application, even if the 
"application" is actually several instances of the same application in multiple 
locations.

It's pretty hard to create a generally useful management UI for arbitrary 
authentication sources anyway.  They all have slightly different constraints: 
some are read/write, some are read-only, etc.  So I usually end up writing my 
own anyway or I just rely on an existing UI (direct SQL, ldap browser, etc).

It might be easier for developers to understand, at least if no management UI 
was required, if the authentication service was always just a global utility, 
and the utility accepted a context in each of its API definitions.  Then people 
who really do need context-sensitive authentication can register a utility that 
adapted the passed in context as necessary, but a simpler utility would just use 
global data.  The pattern is this: delegate the context adaptation to a global 
utility and let the developer do as he must in that global utility to return 
appropriate data based on the context.

I suspect a similar pattern would be useful for cataloging, etc.

- C