[Zope] Making Magic with Mirrowing Folders

[Gary Duke Speer]

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/images/1024res/themes/blue/page.html

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.html

Can you suggest a more appropriate "Zopelike" way to organize or access
the files?
Many thanks,
Gary