CMF_in_CMF

CMF within a CMF

I want to access skins from a central area while keeping content independent

thanks Shane Hathaway for the improved procedure (feb 11, 2002)

thanks Gary Poster for CMFVirtualFolder which replaces the need for this procedure (fev 16, 2002)

Notes

• There are 4 places for skin preference:
  • portal_skin (as a REQUEST variable) seems to take priority (or with DTML
  • portal_skin as an attibute of a user
  • portal_skin cookie
  • default_skin as a property of portal_skins
• working with cookies is tricky; may require zope reboot and/or browser restart or deletion of cookies
• I found that the DTML version of personalize works better for CMF in CMF than the later python re-write (I got it from the Deutch skin): the problem is related to portal_resgistration.setProperties(REQUEST) not updating any change in choice of skin
• If the same user is in CMF root and a sub-CMF, this can cause problems with skin selection; perhaps better to recreate the user in each CMF

My Procedure

• Make a CMF within a CMF
• put a siteroot object (and update any VHF and apache directives)
• remove portal_skins folder entirely (it will acquire skins from the root CMF)
• Optional and Untested: Recreate a portal_skin folder with CMF Core tool and put a single empty folder called custom. add custom in the property list for portal_skins and choose an appropriate default
• create a skin for this CMF in the root CMF (let's say Someskin)
• in Apache, make all connections to the sub-CMF add the following to the URL: ?portal_skin=Someskin and add QSA to the directive's flagset Otherwise search results will be wrong; it shows all objects regardless of the keyword:

   ReWrite *blahblah* *blahblah*?portal_skin=Someskin [P,L,QSA] 
  
   - Otherwise, the default skin of the root CMF takes over (since there is no place to store **portal_skin** attribute in the sub-CMF  *or change the personalize method in all skins (see notes above)*
  

Shane Hathaway added:

That way users will be able to choose between skins in the subsites but not the main site. If you want it the other way around, you rename the REQUEST variable in the subsites instead (perhaps calling it "local_skin"). If you want both, you customize the preferences UI, which might be a little more complex.

• Issues: either the default skin is the same for every subportal or we can force a single portal_skin for subportals ... Other more elaborate techniques have been discussed on the zope mailing list that can solve this issue with Access Rules or ZClasses? or whatnot.

Questions

• How to allow subportal users to choose their skins?
• How to control which skins are available in the sub CMF?

References

• http://aspn.activestate.com/ASPN/Mail/Message/Zope-CMF/941848
• Example to see what is going on:

   default_skin: <font color=red><dtml-var default_skin> </font>
  
   portal_skin attribute: <font color=red><dtml-var portal_skin></font>
  
   REQUEST variable: <font color=red><dtml-var "REQUEST.portal_skin"></font>
  
   cookie: <font color=red><dtml-var "REQUEST.cookies['portal_skin']"></font>
  

• Zope Mailing List:

   From: "Meilicke, Scott" <[email protected]> 
   To: 'Babu' <[email protected]>, [email protected]
   Subject: RE: [Zope-CMF] CMF for intranets, CMF inside CMF etc
   Date: Thu, 7 Feb 2002 22:06:26 -0800
  
   Regarding how to share My Stuff and skins, you should be able to have my.org
   be a CMF instance, and within all lower level CMF instances, delete out the
   skins folders and member folders.  zope will traverse up until it fines the
   files, which would live in the top level.  Hmm, actually, doing that for My
   Stuff would hose the individual catalogs (I think).  Maybe not a good idea.
  

• Python Conference 10 (search for CMF within CMF and subportals in mailing lists):

    Paper: http://www.smoking-gnomes.org/python10.pdf
    Presentation: http://www.smoking-gnomes.org/python10
    Demonstration: http://www.smoking-gnomes.org/intranet
    Website (as if you couldn't guess): http://www.smoking-gnomes.org