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

[hazmat]

On Monday 21 October 2002 06:02 am, 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?

i imagine, its trying to save the globals so later it can be passed in 
(sometimes by other modules which import cmfdefault) to things like fs page 
templates, directory views, fs dtml files, to give them a loading context. 
imo, it would be better if this used
 cmf_default_location=package_home(globals())
as all the things its being used for can take path prefixes, afaik.

>
> 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())?

as florent stated, their is a difference between initialize which is during 
zope  product initialization, and import time when those module level 
statements will get executed... although now that i think about it, that 
difference is pretty minimal since they happen back to back, except for the 
case of intra product imports.  
/me punts.

>     z_bases = utils.initializeBasesPhase1( bases, this_module )
>     z_tool_bases = utils.initializeBasesPhase1( tools, this_module )

i'm also going to agree with florent about by desire to learn more about 
zclasses and what these do

> 3.  The contentClasses, contentConstructors, bases, and tools variables are
> currently module-level variables--why? 

convience mostly, and to persist them so other things can use them. for 
example i have a generic external method for my cmfy products thats uses 
those module level variables to install and register the product onto a cmf 
instace.  

> Are these things used at
> module-initialization AND product initialization?
>

i'm not sure how your defining these terms.

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

a has nothing to do with b.

all your questions have been about cmf portal *product* initialization and 
registration. this a totally different thing than what you want, which is cmf 
*portal instance* initialization.

you really should look at the portal factory for adding a portal site, if you 
want to do additonal customization. if your not using plone i would turn all 
your custmozations into an external method and use that on your new portal 
instances. if your using plone (worthwhile to take a look at anyways since 
its replacing default workflow with dcworkflow, which is one thing you want), 
take a look at the Portal.PloneGenerator in plone, which customizes a default 
cmf portal, to make a plone one. you could do something simliar to make the 
mark portals.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plone/CMFPlone/Portal.py?rev=1.52&content-type=text/vnd.viewcvs-markup

-haz