[Zope-CMF] dev question on CMFDefault.__init__.py

[Tres Seaver]

On Mon, 2002-10-21 at 19:57, hazmat wrote:
> On Monday 21 October 2002 07:22 am, Tres Seaver wrote:
> > On Mon, 2002-10-21 at 09:02, Mark McEahern wrote:
> > > [Florent Guillaume]
> > >
> > > > As one datapoint, the main body of __init__ is called at module
> > > > initialization, which is very early. initialize() is called by Product
> > > > initialization, which is done later by Zope.
> > > >
> > > > But I don't know the precise details of ZClasses initialization (and
> > > > frankly the less I hear about ZClasses, the happier I am).
> > >
> > > Here are a couple of concrete questions I have:
> > >
> > > 1.  On line 110, a module level variable is created to store globals, but
> > > then it's not used:
> > >
> > >     cmfdefault_globals=globals()
> > >
> > >     Why is that assignment even there?
> >
> > So that other modules can import it, and use it to find where on the
> > filesystem the CMFDefault product lives.
> 
> i've always wondered why this doesn't use package_home to leave the actual 
> path, instead of saving a reference to the globals... any particular reason?
> all the things that take globals, take a path prefix as well.
> 
> at this point its probably moot, as its already been sacrificed on the alter 
> of backwards compatiblity.
> 
> <snip>
> 
> >
> > > [hazmat]
> > >
> > > > many things are non obvious when your using talking about zclasses,
> > > > imo. i'd imagine the placement of the initialziation stuff is either
> > > > chance, or because of ordering requirements.
> > >
> > > This seems very fragile, then, insofar as CMFDefault is intended to be a
> > > demonstration of CMF.  I would love to help improve it, but I'm trying to
> > > understand it first.  <wink>
> >
> > Some of the cruft there comes from working around problems with
> > order-of-initialization issues for ZClass-based development.  "Fixing"
> > it is problematic, as the symptoms are tough to reproduce (they can
> > depend, for instance, on the physical order of directory entries in the
> > 'Products' directory!).
> 
> i think by physical order, you really meant lexographical sort order of 
> directory name strings as according to python :-)

Nope, I mean the order that the names come back when iterating over
and opened directory, which varies based in the underlying C libraries;
for instance, I have beaten my head against a problem where a fresh
checkout had different behavior than an old sandbox, because the old
sandbox was created before a particular directory was added to CVS; 
that product was then processed last, rather than in any "natural"
order.

> >
> > There are several ideas kicking around for managing the "site setup"
> > problem:
> >
> >   - In your own product, write a "Portal Generator" and register it as
> >     a ZMI-addable object (this is how Plone's stuff works, I think).
> 
> yup.
> 
> >   - Add ExternalMethods to register new, add-on products (this is how
> >     the CMFCalendar product is added to a site, by default).
> >
> >   - Add a tool which manages the add-on products.  Adrian Hungate has a
> >     proposal for such a beast, and a working implementation:
> >
> >     <http://www.haqa.co.uk/Software/cvs/Products/CMFInstaller>
> 
> cool, this is on the add list for the core in cmf1.4 i believe?

It is in the draft which Alan posted.

> >   - We are working on a tool for a current consulting gig which
> >     synchronizes tool configurations between the filesystem and the
> >     ZODB, using XML files to represent the serialized configurations.
> >     The tool also manages other "setup steps" as callables, and keeps
> >     track of "last run" times, as well as dependencies.  We probably
> >     won't have time to release this tool in the near term, but I think
> >     that (perhaps in conjunction with Adrian's tool) it would go a
> >     long way toward solving the "site configuration management" issue.
> 
> sounds very cool, part of the this is in public cvs
> http://cvs.zope.org/Packages/ZConfig/

Nope;  that would be *another* customer gig. :)  From a distance,
ZConfig seems aimed more at "server" configuration, and less on "site"
configuration (I could be wrong. :)

> 
> whats more interesting (as least to me ;-) is that i wrote something very 
> similiar for a client to solve the same problem (perhaps for different 
> reasons). i'll open source it latter today. i've been holding off because i 
> haven't made the time to document it, but as there is a real need i think for 
> this type of software, i'm just going to release it. i eschewed xml (as it 
> appears zconfig does), and focused generically on assembling functions into 
> structures (graphs, trees, sets) with logging, dependencies, and structure 
> nesting.

Cool.

Tres
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com