[Zope-dev] refactoring site functionality
chrism at plope.com
Thu May 28 11:45:57 EDT 2009
On 5/28/09 11:00 AM, Martijn Faassen wrote:
> 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
> * 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
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.
More information about the Zope-Dev