Re: [Zope-dev] ZCML conflict resolution
On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough wrote: > I'm trying to decide whether to repurpose the conflict detection in > zope.configuration for non-XML configuration. Cool. ... > Unfortunately, the documentation in the code tends to explains the > mechanics of conflict resolution, but not the intent. I'll take a guess > though: > > - the "rootmost" directive that participates in a conflict is meant to > "win". > > - 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. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCML conflict resolution
I'm trying to decide whether to repurpose the conflict detection in zope.configuration for non-XML configuration. zope.configuration has the following resolveConflicts function, which attempts to resolve action discriminator conflicts. def resolveConflicts(actions): """Resolve conflicting actions Given an actions list, identify and try to resolve conflicting actions. Actions conflict if they have the same non-null discriminator. Conflicting actions can be resolved if the include path of one of the actions is a prefix of the includepaths of the other conflicting actions and is unequal to the include paths in the other conflicting actions. ... """ The code in resolveConflicts indeed matches the docstring description. In the "test_simple.py" test file, a little more light is shed on conflict resolution: """Conflicting actions can be resolved if one of the conflicting actions is from a configuration file that directly or indirectly includes the files containing the other conflicting actions.""" There's also a test in test_xmlconfig.py that goes into details about includeOverrides and conflict detection. (Note that I don't care about includeOverrides here. I think I understand it, after some wrangling with it.) Unfortunately, the documentation in the code tends to explains the mechanics of conflict resolution, but not the intent. I'll take a guess though: - the "rootmost" directive that participates in a conflict is meant to "win". - if there is more than one "rootmost" directive that participates in a conflict, the conflict cannot be resolved. Does my summary sound about right? Does anyone have any insight as to why this particular conflict resolution strategy was chosen? I'm really just trying to understand the intent. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
