On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough <chr...@plope.com> wrote:
> I'm trying to decide whether to repurpose the conflict detection in
> zope.configuration for non-XML configuration.
> Unfortunately, the documentation in the code tends to explains the
> mechanics of conflict resolution, but not the intent. I'll take a guess
> - the "rootmost" directive that participates in a conflict is meant to
> - if there is more than one "rootmost" directive that participates in a
> conflict, the conflict cannot be resolved.
> Does my summary sound about right?
Yes, but ...
> Does anyone have any insight as to
> why this particular conflict resolution strategy was chosen? I'm really
> just trying to understand the intent.
The intent was to provide a way of overriding configuration in a way that
was unambiguous and understandable.
(Of course, it fails in the case of subscribers, but I think that's
beside your point. :)
Let's take this up a level, to user goals.
A user wants to reuse a high-level component (aka package aka
"project" in distutils
jargon aka "product" in distutils jargon). They want to customize
the high-level component without hacking its code.
*That* is really the intent.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -