[Zope3-dev] proposal to extend meta.zcml files with documentation strings

[Shane Hathaway]

R. David Murray wrote:
> On Mon, 23 Sep 2002, Shane Hathaway wrote:
> 
>>R. David Murray wrote:
>>The main trouble I've had with ZCML is that it's hard to find the Python
>>code it supposedly invokes.  In fact, it seems to try to hide the
>>association.  I realize there need to be multiple passes over the
>>configuration (Jim and I came up with the multiple pass idea together,
>>after all!) but the current coupling between directives and executable
>>code is much too loose.  Figuring out exactly what code will be executed
>>as the result of an active directive is too difficult.
> 
> 
> There might be a way to use the parser to at least build a map
> between the directives and the generated actions.  I'll look into
> that if I get the time.

Ok, if that's the best we can do for now.

>>should be represented as an object.  A configuration file should be an
>>object.  An active configuration should be an object.  I think it could
>>lift a lot of the complexity of Zope 3 configuration.  I've been
>>drafting rough interfaces, if anyone is interested.
> 
> 
> This sounds very reminicent of a long thought dump Philip Eby posted
> to the transwarp mailing list a couple months or so ago.  If you didn't
> see it, Maybe you and he should talk <grin>.

Braindumps are pretty hard to search. :-)  Could you point me to a 
specific message/thread?

>>Also, I think configuration in XML has great benefits, but coding
>>"meta-configuration" in XML adds to the complexity burden without a
>>benefit that I'm aware of.  We envision site developers changing the
>>software configuration, but do we envision them changing the software
>>configuration configuration?  Imagine you're designing a home through a
>>contractor.  You'd want to specify the layout of the rooms, but you
>>wouldn't want to specify the format of the blueprints.  That's up to the
>>contractor.
> 
> 
> This is true.  However, I will note that I built my prototype
> doc-generator by reprograming the meta configuration directives.
> The "default" zcml binds routines to the meta-configuration
> directives that simply ignore the docstrings.  A special
> "docgenerator" zcml file, used only by the doc generator
> program (that I have yet to write <grin>) binds the directives
> to routines that do something useful with the doc strings.
> This may be a very specialized use case, but it seems to me
> that in principle it might be useful for a product developer
> to be able to modify the configuration directives of another
> package without touching that package, just like we can now
> modify the actual directives without touching the other
> package.

AFAIK you can't modify the meta-directives for another package, you can 
only provide meta-directives that apply to the entire system.  Isn't 
that right?

> Phil's system sounded pretty sweet, though, and I imagine yours
> would share many of the nice characteristics.  I certainly
> wouldn't mind doing away with zcml metaconfiguration myself.
> 
> On the final hand, I've got this thing 70% working, so it sounds
> like it's probably worth deploying until/if something is done to
> improve the basic design of the configuration system.  I did some,
> um...small underhanded things in meta.py that I'd best check out
> with Jim, though <grin>.

Sure, maybe you have some insights that will make the current system 
comprehensible.

Shane