[Zope-CMF] what method is called first when a CMF Site is viewed ?

[robert]

Hi Raphael,
thanks for your answer.
I see I have to explain why I can not do it the "right way".
I have a "intranet construction kit" which construct an intranet from a=20
excelsheet (where structure, rigths, workflows etc are defined) and a set o=
f =20
definition files where all the rest of zillion plone/cmf settings are=20
defined.
These definition files are stored together with all skin files for this=20
particular intanet somewhere in a data directory on the filesystem. This=20
directory is NOT part of any product.
New Plone sites are constructed by help of a CustomizationPolicy that locat=
e=20
the data directory by help of the new sites title.
While constructing the site the CMF's skin search is temporarily patched to=
=20
find the skins in the data directory.
This all works very well and is extremly flexible.

Some times however (and I have not discovered why yet) a site "looses" all=
=20
content of the "special" skins when restarting zope. I have to manually cal=
l=20
the setup routine from the construction kit to fix up the skins.

So what I want to do at startup is checking whether the skins are there, an=
d=20
call this routine if not.
Obviously this has to be done before anything tries to access them.

What I need is a hook, an __init__ or what ever that where I can add a call=
 to=20
the routine mentined.

thanks again
Robert

Am Dienstag, 15. April 2003 10:31 schrieb Raphael Ritz:
> Am Mon, 2003-04-14 um 19.22 schrieb robert:
> > Ausum
> > thank you very  much for your answer.
> > What I need is a method that sets up a "non standard" skins path that
> > should be called once when plone/cmf  starts up.
> > Since it fiddles with the skins path It can not be  in one of "my" skin=
s,
> > they will be found only after the method has been executed.
> > In fact the method needs to be run only once after zope has started up
> > but everytimes a site is started is fine.
>
> Not sure I understand your problem but why don't you do it
> the way skins are usually set up (from within a file system
> based product).
>
> First in __init__.py you register your skin directories
> e.g., like (examples taken from my Bibliography product)
> ...
> registerDirectory('cmf_skins', globals())
> registerDirectory('cmf_skins/bibliography', globals())
> registerDirectory('plone_skins', globals())
> registerDirectory('plone_skins/bibliography', globals())
> ...
>
> then in Extensions/Install.py you do
> ...
>
>
> def installSubSkin(self, out, skinFolder):
>     """ Install a subskin, i.e. a folder/directoryview.
>     """
>     skinsTool =3D getToolByName(self, 'portal_skins')
>
>     for skin in skinsTool.getSkinSelections():
>         path =3D skinsTool.getSkinPath(skin)
>         path =3D map( string.strip, string.split( path,',' ) )
>         if not skinFolder in path:
>             try:
>                 path.insert( path.index( 'custom')+1, skinFolder )
>             except ValueError:
>                 path.append(skinFolder)
>             path =3D string.join( path, ', ' )
>             skinsTool.addSkinSelection( skin, path )
>             out.write('Subskin successfully installed into %s.\n' %
> skin)
>         else:
>             out.write('*** Subskin was already installed into %s.\n' %
> skin)
>
>
> def setupTypesandSkins(self, out, isPlone):
>     typesTool =3D getToolByName(self, 'portal_types')
>     skinsTool =3D getToolByName(self, 'portal_skins')
>
>     # Former types deletion (added by PJG)
>     ...
>
>     # Install de chaque nouvelle subskin/layer
>
>     # are we in a Plone site?
>     if isPlone:
>         skin_folder =3D "plone_skins"
>     else:
>         skin_folder =3D "cmf_skins"
>
>     try:
>         addDirectoryViews(skinsTool, skin_folder, install_globals)
>         out.write( "Added directory views to portal_skins.\n" )
>     except:
>         out.write( '*** Unable to add directory views to
> portal_skins.\n')
>
>     # Param de chaque nouvelle subskin/layer
>     installSubSkin(self, out, skin_name)
> ...
>
> Look how the skin path is manipulated within the 'installSubSkin'
> call. You should be able to do similar things also on the fly
> (meaning from methods called when first viewed or whatever).
>
> HTH
>
> 	Raphael

=2D-=20
mit freundlichen Gr=FCssen

Robert Rottermann
www.redCOR.ch