On Tue, Dec 7, 2010 at 2:27 PM, Chris McDonough <chr...@plope.com> wrote: > On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: >> On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough <chr...@plope.com> wrote: >> > Independent of my previous call for discussion about ZCML conflict >> > resolution, I'm cutting and pasting my side of a discussion about the >> > ZCML "includeOverrides" directive from an IRC chat, because it may come >> > in useful for folks grappling with its behavior. There's not really any >> > human-consumable docs about it. >> > >> > If I've made any mistakes, please let me know. >> > >> > [13:42] <mcdonc> so ftr, i've found that ZCML's includeOverrides and >> > include to do (at least on one vector) exactly the opposite of what you >> > might expect them to do >> > [13:42] <mcdonc> "includeOverrides" is a poor name >> > [13:42] <mcdonc> what it does is to emulate the behavior of inlining >> > stuff into the file you use it from >> > [13:43] <mcdonc> when you use includeOverrides it's as if you typed all >> > the directives in the included file into the file you're including from >> > [13:43] <mcdonc> otoh, "include" doesnt behave like this >> > [13:44] <mcdonc> you can actually define the same directive in three >> > files >> > [13:44] <mcdonc> configure.zcml, one.zcml, and two.zcml >> > [13:44] <mcdonc> and if you use "include" from configure.zcml of one and >> > two >> > [13:44] <mcdonc> there will be no conflict >> > [13:45] <mcdonc> this is because non-conflicting "rootmost" directives >> > win >> > [13:45] <mcdonc> otoh, if you use includeOverrides of one and two from >> > configure.zcml >> > [13:45] <mcdonc> all three will conflict >> > [13:45] <mcdonc> because its as if you typed them all in configure.zcml >> > by hand >> > [13:45] <mcdonc> and that means there are three conflicting rootmost >> > directives >> > [13:46] <mcdonc> if you mentally substitute "inline" for >> > "includeOverrides" it makes a little more sense >> >> Maybe. It described the mechanism better, but includeOverrides conveys the >> intent. <shrug> > > Sorry, not a criticism, just a personal observation.
No problem. Your observation is valid. > I assume I'm not wrong about the behavior I describe above? I don't think so. >> > [13:48] <mcdonc> override is exactly the wrong phrase to use in the name >> > of this directive >> > [13:51] <mcdonc> what it boils down to is that you never, ever really >> > want to use includeOverrides except in your rootmost zcml file >> > [13:51] <mcdonc> and probably not even there >> > [13:51] <mcdonc> because you can get the same effect by typing the >> > directives there by hand >> >> Why would you want to type the directives by hand? > > I *think* I'm of the opinion that libraries (or even "reusable > applications") probably shouldn't need to use includeOverrides. You > might disagree. I'd actually like to hear your take on that, because > I'm only about 90% confident about that. ;-) By now you've probably seen my other post where I said I think we've taken comparability too far. :) I should have noted there that I was talking about "configrability" in terms of selective overriding. If something is going to be configurable, by which I mean overridable, then I think includeOverrides or something like it is pretty valuable. > I realize that not every > application knows whether it's going to be reused or not, Not only that, YAGNI says it should be written from the start as if it isn't, until it is. :) or more importantly, it shouldn't be written to have it's parts overridden until a compelling reason has been found to do so. > but, even so, > it's always an option to cutnpaste the topmost ZCML from that > application into a new file and disuse the old one. Yeah, just like you can reuse Python code by copying it. It's usually better to reuse by reference if possible. > But if you take for granted the idea that libraries shouldn't use > "includeOverrides", Unless the library is built on some other library. Even then, include may be a better option, but there is still overriding going on. > the place that it is actually potentially useful is > in the "deployment" ZCML file (the topmost ZCML file that includes other > ZCML from libraries and other application packages). In practice, I haven't found this to be a single file, but that's probably beside the point. > But in this > scenario, I already "own" the topmost ZCML file, and since it's > deployment-specific, there's no sense in breaking out the included stuff > into a separate file, because no one else will ever reuse it. It's all > deployment-specific policy. This is like saying that a main program that uses libraries shouldn't be broken into subprograms. 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 )
