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

[hazmat]

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


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

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?

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

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.

-haz