[Zope3-dev] Re: ZCML

[Jeffrey P Shell]

On Monday, August 18, 2003, at 04:40  PM, Shane Hathaway wrote:

> Jeremy Hylton wrote:
>> If ZCML is a dividing issue, I wish there was a way to make the 
>> division
>> less prominent.  Perhaps more than one way to do it?  Is it just the
>> syntax that bothers you, Shane, or is it deeper than that?
>
> The first thing that bothers me is that overriding directives looks 
> problematic.  Take the following directive from onlinehelp.zcml:
>
>   <pages
>       for="zope.app.interfaces.onlinehelp.IOnlineHelpTopic"
>       permission="zope.Public"
>       class=".onlinehelp.OnlineHelpTopicView">
>
>       <page name="index.html" template="onlinehelptopic.pt"/>
>       <page name="getTopicTree" attribute="getTopicTree"/>
>   </pages>
>
> Let's say I'm preparing a semi-public site.  I don't want the help 
> system to be public, but I do want certain users to be able to see it. 
> I don't want to modify onlinehelp.zcml, so I proceed to add a 
> directive to my site.zcml.
>
> ...But wait a minute, what should I write?  Do I have to copy and 
> paste the entire <pages> tag?  If I do that, do I have to track 
> changes when I upgrade Zope?  This doesn't seem right.  I'd really 
> like to write just this:
>
>   <pages
>       permission="myapp.MyPermission"
>       class="zope.app.browser.onlinehelp.OnlineHelpTopicView" />
>
> The lack of "minimal override" capability has been quite painful for 
> Zope Corporation.  We write and maintain complex "buildout" scripts 
> that serve a similar function as site.zcml.  The buildout scripts have 
> to duplicate and keep in sync with other software.  I'm not sure that 
> ZCML, in its current form, will solve the complex buildout problem.

Arrr.  That's what I was afraid that one had to do.  And I didn't mind 
it, as it may be painful but still a lot more flexible than the 
initialize(context) code of Zope 2, where one has no say over the 
ordering of how products get imported.

I had a case recently where we did a custom version of a ticket selling 
site.  In the main ticket selling site code, most of the 
through-the-web Python Scripts and SQL Methods have been moved into 
file system based components.  The main business logic change that this 
customer had was a specialized registration process.  Fortunately, the 
'register.py' Python Script had not been moved down into these newer 
components, and I was able to modify that one in place for this 
particular customer.

But in the back of my mind, I was thinking "man, how would I have 
replaced the 'gateways.public.Registration' component with a new one?"  
I have a lot of simple little registries, but most of the classes 
register themselves in Python code, so I'd have to replace 
'gateways.public.Registration' in a product that got imported later, 
meaning I'd have to name that product 'ZZZOtherTicketSite' or something 
to ensure that it got loaded last, or make another Products directory 
that Zope would search through after loading my base framework on top 
of Zope's core.  I have this problem sometimes with products that 
define and register new Formulator fields.

I really like that in ZCML, I have much more control over this whole 
process.  But at the same time, I've been fearful of the problem that 
you describe - worried that I'd have to copy and paste ZCML into my own 
configuration file/tree, and then have to edit what was copied and 
pasted to ensure that references (ie '.interfaces.IFoo', and 
file="blammo.png") get expanded by hand.