On May 28, 2009, at 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)
> * writing tests that involve local utilities. (a more advanced case,
> still quite common)
>> 3. I think the right word here is "local registry". I think the
>> concept should be labeled as advanced and we should discourage people
>> from even pondering it unless they have a strong use case, like
>> wanting to host multiple web sites with different configs in the same
>> application. :)
> I don't think "hosting multiple web sites with different configs in
> same application" is the only use case.
> * the catalog. This can be done using a global component that somehow
> stuffs information in the ZODB, but there are no common patterns for
> this that people can follow, so local utilities are currently easier
> to use.
> * often it is nice to have application configuration to have a user
> interface, so that end users can configure aspects of the application.
> This may be filling in an email address or customizing a template or
> adding a user, etc. Local utilities are a nice solution for this, even
> if there is just a single application installed.
I think we're talking about 2 different things.
There is the registry that is "local" to the root object and that is
stored in the database. Having registration data in the database
makes sense for a number of reasons and I don't consider this
advanced. This is effectively a global registry. It doesn't really
matter that it is attached to the root folder.
Then there are registries sprinkled around the object tree below the
root. These are truly local, because they pertain to a subset of the
object tree. This is the usage that I think we should relegate to an
advanced feature and rethink the goals for. Most importantly, IMO, we
should avoid having this advanced usage complicate the lives of 98% of
developers who don't need it.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -