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

[Tres Seaver]

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.

> 
> 2.  On line 107-108, z_bases and z_tool_bases are setup, but then they're
> used inside initialize().  Why not assign them in closer proximity to where
> they're used (inside initialize())?
> 
>     z_bases = utils.initializeBasesPhase1( bases, this_module )
>     z_tool_bases = utils.initializeBasesPhase1( tools, this_module )

This initialization *must* be done during import, as there may be other
products which depend on being able to find the generated base classes
before 'initialize' is run.  Python's dependency management is based
purely around the 'import' keyword;  anything which must be exported to
other packages must be available at module scope, else you are
vulnerable to "order of import" issues.

> 3.  The contentClasses, contentConstructors, bases, and tools variables are
> currently module-level variables--why?  Are these things used at
> module-initialization AND product initialization?

Again, the names declared at module scope are "exported";  names
declared inside the 'initialize' function are not.

> [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!).

> [hazmat]
> > if your interested in initialization as a matter of writing your own
> > products, i would take a look at some of the other cmf products.
> 
> I'm more interested currently in customizing a CMF portal.  I can't use
> CMFDefault out of the box because I want to use DCWorkflow.  When I add the
> portal to the Root Zope site, I don't want to have to manually delete the
> default workflow and step-by-step recreate the one I want in the ZMI.
> Instead, I'd like to have that packaged.  You suggested using an External
> Method, which I appreciate.  I like the CustomizationPolicy idea that Plone
> has and I'm trying to understand how to add that to CMFDefault.  Which is
> why I'm trying to understand __init__.py.  Perhaps it was only intended as a
> black box, though?

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).

  - 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>

  - 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.

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