You are not logged in Log in Join
You are here: Home » Members » vernier » Debian » CMF_in_CMF

Log in
Name

Password

 
 

History for CMF_in_CMF

??changed:
-
**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":http://lists.zope.org/pipermail/zope-cmf/2001-December/010796.html

 - portal_skin as an attibute of a user

 - portal_skin "cookie":http://lists.zope.org/pipermail/zope-cmf/2001-May/006689.html

 - default_skin as a property of portal_skins

- working with cookies is tricky; may require "zope reboot":http://zope.nipltd.com/public/lists/ptk-archive.nsf/13efd285960dfebf802568c100635fee/43dc9896ecbeb63280256a620006fb58?OpenDocument
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)*

<font color=blue> Shane Hathaway added:

 - Don't remove portal_skins.  Instead, remove all folders and objects
in portal_skins and clear the properties of the tool.  (Remove all skin
definitions.)

 - Use a different REQUEST variable in the main site.  Instead of
"portal_skin", call it "global_skin".

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

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