Dieter - Thank you for clarifying Mirrowing Folders and your guidance. Perhaps you can suggest an organizational approach that is more optimal in the Zope context for the following: The goal is to create a rather simple theme or skin framework without adopting more complex environments such as Plone that has skinning built in. In essence, screen elements, images and css stylesheets, are organized in a hierarchy to take advantage of acquisition. The organization has two dimensions - the theme itself and the resolution of the browser. The elements fall into the following categories: sitewide generic - used in all themes and all resolutions. - bullets and icons resolution generic - used in all themes of the selected resolution - logos and buttons sized for 800 and 1024 resolution theme generic - used in all resolutions of the selected theme - background tiles that are stretched or repeated to fit resolution and are theme specific - images that are sized for 800 or 1024 and involve the selected theme. Between the two dimensions, I prefer to organize with the resolution being primary and the theme secondary. To me, this suggests the following structure: relativeroot/common/images - the sitewide generic bullets and icons relativeroot/common - the sitewide business logic elements relativeroot/common - css and page elements that get their dimensions from the acquired images, (dtml-var imagename style) relativeroot/common/800res - css and page elements with layouts and dimensions sized for an 800 screen relativeroot/common/800res/images - the logos and buttons sized for an 800 screen relativeroot/common/1024res/images - the logos and buttons sized for a 1024 screen adding the themes dimension ... relativeroot/common/800res/themes/red - "Red" theme page elements/images sized for an 800 screen relativeroot/common/800res/themes/blue - "Blue" theme page elements/images sized for an 800 screen relativeroot/common/1024res/themes/red - "Red" theme page elements/images sized for an 1024 screen relativeroot/common/1024res/themes/blue - "Blue" theme page elements/images sized for an 1024 screen relativeroot/common/themes/red - "Red" theme page elements/images that are not sized, like a red background tile relativeroot/common/themes/blue - "Blue" theme non-sized page elements/images By operation of the selected resolution and theme, the desired page configuration is accessed via URL such as: http://www.mysite.com/common/1024res/themes/blue/page.html By acquisition the file is obtained from: relativeroot/common/page.html it has references to image elements like bullet.gif that is generic and will not be found anywhere except .../common/images/bullet.gif photo.jpg that is sized and will not be found anywhere except .../common/1024res/images/photo.jpg background.jpg that is theme-specific (it's blue) and will not be found anywhere except .../common/themes/blue/images/background.jpg fancygraphic.gif that is sized to match the screen and is in the theme color and will not be found anywhere except .../common/1024res/themes/blue/images/fancygraphic.gif the tag <img src="images/fancygraphic.gif> works directly. Acquiring the other elements with a tag such as <img src="images/photo.jpg> doesn't work because acquisition will stop with the first successful attempt to find "images". All images could be moved up one level, out of an images folder and into the acquisition path, but this bloats every folder and to simplify site management, this is what we are trying to avoid. Further, it doesn't locate the common theme elements. So, the resulting question, with this schema, is how to get acquisition routed through the generic folders without using a complex URL like the following: http://www.mysite.com/common/images/common/themes/blue/images/common/1024res... I tried the product approach - Portable Hole came to mind, but it requires absolute URLs and I need to use relative ones for portability/maintainability. Mirrow Folder also seemed to fit because themes were like languages. Symlink was tried and found to be highly risky as once created it is hard to change/remove/manage. Reference is a candidate but is a bit unweildy as it cannot be copied - we could not create a theme 'green' by copying the theme red as the references from red to the common folders have to be created by hand and will interrupt the copy. LinkedFolder just didn't seem to work. In short, I do not see an easy way to programatically append the contents of a more generic images subfolder to a more specific one. So now I am back to redesigning the schema to best use native acquisition and I want to take your suggestion into account but do not understand how to apply it in this context. My impression, to make acquisition work, is to not reuse the images folder name. In other words, design the pages with elements that know what level of the hierarcy to find the images. Use folders called: relativeroot/common/commonimages - the sitewide generic bullets and icons relativeroot/common/800res/resimages - the logos and buttons sized for an 800 screen relativeroot/common/themes/blue/themeimages - non-sized theme images and relativeroot/common/800res/themes/blue/images - sized theme images With this schema, the images folder will not defeat the acquisition of <img src="commonimages/bullet.gif'> or of <img src="resimages/photo.jpg"> but there is still no way to acquire <img src="themeimages/background.jpg"> without programmaticatically specifying the common/themes/blue path. At least with this approach the non-linear URL can be simplified to http://www.mysite.com/common/themes/blue/images/1024res/themes/blue/page.htm... Can you suggest a more appropriate "Zopelike" way to organize or access the files? Many thanks, Gary