[Zope3-dev] site.zcml (ftesting.zcml) extension

[Roger Ineichen]

Hi Shane

From: zope3-dev-bounces+dev=projekt01.ch at zope.org 
> [mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On 
> Behalf Of Shane Hathaway
> Sent: Monday, April 25, 2005 3:38 PM
> To: Dominik Huber
> Cc: zope3-dev at zope.org
> Subject: Re: [Zope3-dev] site.zcml (ftesting.zcml) extension
> 
> Dominik Huber wrote:
> > We should have an application/framework-level hook within 
> the site.zcml
> > that is processed before *-configure.zcml are invoked.
> > 
> > Problem: A framework package 'b.x' registers a dedicated 
> menu 'b_views'.
> > A package 'a.x' using 'b.x' should be able to register menu items
> > refering 'b_views'. The initialisation will fail because 
> 'a.x' is loaded
> > before 'b.x' and therefore  'a.x' cant register any view to 
> 'b_views'
> > because the menu does not exists yet.
> > 
> > Proposed solution: package includes named *-app.zcml will be invoked
> > before the regular *-configure.zcml package includes 
> (Compare example
> > site.zcml below)
> > 
> > Any objections?
> 
> That might be a reasonable band-aid.  However, directives 
> ought to have
> no load-time dependencies on other directives.  The configuration
> directives should defer any interconnections and registration 
> until the
> whole configuration is loaded.
> 
> In your specific example, a.x should be able to register views on any
> menu, regardless of whether b_views has been loaded yet.

This would be nice. But it isn't.

The addMenuItem directiv has dependency to the menu directive
if you use a own Adding view.

That's the only reason where we see right now. 

The alphabtice order of configure.zcml like Stephan proposed
is one solution. But I like a more explicit solution for this
like Dominik proposed with a additional application level
for 3rd party packages.

Regards
Roger Ineichen