Making Magic with Mirrowing Folders
I have been trying to configure Dieter's Mirrowing Folders Product. Using both direct _dtml-var_ links and Shane's AquisitionUnderstander I cannot see the product having any effect. I suspect it is because I do not understand either the product's intention or how to properly setup the mirrow link. For the benefit of other newbies like me, if I am mis-stating the goal of the product or any aspect of it, please say so. My understanding of the intention of the product is that it will insert a distant folder into the acquision path as if the URL routed through that folder, and it does so only when there is exact alignment of the two relative paths. For background, my objective is to have a portable-hole style solution but using only relative urls due to using virtual hosting and other reasons. relative to the site's root folder, there are two primary directory trees - common content files and objects and context-specific files. a simplistic example: .../mysite/ (relative root) .../mysite/common (branch of common content to be mirrowed into other contexts) .../mysite/common/images (folder of site-wide images) .../mysite/common/images/logos/sitelogo.gif (an image to acquire) .../mysite/englishpages (branch of context-specific content) .../mysite/englishpages/page.html (the page trying to access both specific and common content) .../mysite/englishpages/images (folder of context-specific - english language - images) .../mysite/englishpages/images/logos/sitename.gif (an image of the site name written in english) .../mysite/germanpages (branch with identical sub-structure to englishpages and to common) My impression is that .../mysite/englishpages/images is the folder that should be created as a mirrow folder and it should point to the matching common folder. That it's ID is images and it's mirrowid__ property should be set to ../common/images meaning include content that is located up one level from my containing folder, englishpages in a folder called common and in a subfolder called images. The complete magic, compared to transparent folder is that links inside page.html to the logos folder will acquire objects from both logos folders. In other words, a relative link to images/logos/sitename.gif works because the path directly accesses the file. A link to images/logos/sitelogo.gif triggers acquisition because it is not found in the .../mysite/englishpages/images/logos/ folder, so acquisition checks the .../mysite/englishpages/images/ folder, again not found. By operation of the mirrowlink acquisition checks the same subpath of the target, namely .../mysite/common/images/logos/ and should find it. If not, since mirrow is described as subpath specific, aquisition skips checking .../mysite/common/images/ and proceeds to check .../mysite/ .../ and so on up to the Zope root. In short, the mirrow is largely functionally equivalent to using the URL: ../mysite/englishpages/common/images/logos/englishpages/images/logos except that common/images is skipped over. I have tried several variations, including a link to .../mysite/englishpages/images/testimage.jpg in the hopes of returning .../mysite/common/images/testimage.jpg but no luck and .../mysite/common/images/logos/showaq does not look anywhere except each folder of the path. (During this testing VHM is off, tried on both Zope 2.6.1 and 2.7.0 to see if there was a change in the way.) Sorry this is lengthy, but I'm hoping to get my conceptual understanding improved better than I have so far by Googling the archives of this group. Maybe the result will lead to a how-to comparing LinkedFolder, TransparentFolder, PortableHole, Reference, Mirrow Folder, and the toxic Symlink product. Thank you, Duke
Gary Duke Speer wrote at 2004-6-11 12:19 -0600:
I have been trying to configure Dieter's Mirrowing Folders Product. Using both direct _dtml-var_ links and Shane's AquisitionUnderstander I cannot see the product having any effect. I suspect it is because I do not understand either the product's intention or how to properly setup the mirrow link.
"Mirroring Folder" supports the following use case: A multilingual site with multiple applications/subapplications/subsubapplications... Each application (subapplication ...) contains language independent resources (business logic, common infrastructure, gluing scripts, ...) and language dependent resources (presentation, content). All resources for an application are directly associated with this application; there is no further organisation based on e.g. type. For these kinds of use cases, you would set up "MirroringFolder" as follows: MirroringFolder/ common/ # mirrored by the mirroring folder application1/ subapplication1/ ... application2/ ... language1/ application 1/ ... language2/ ... Note that Zope does not support optimally an organisation based on types (like "Images", "SQL", ...). Do not organize your resources like this for Zope. Organize, instead by applications (subapplications, ...). This lets take you optimal advandage from acquisition. MirrowingFolder does not (or very limited) support organisation by type. Note further that MirroringFolder does its magic during URL traversal. Do not expect any effect unless you traverse through the folder. -- Dieter
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
Hi Dieter - Sorry, I'm still slightly unclear. Using the schema you described ... The mirrowing folder is obviously set in the acquisition path of application 1 in the context of language 1. Is it's target supposed to be set to be one of it's child folders .. MirrowTarget__ = "common" and this places any child of common with a folder name matching any folder that is a parent of application1 into the acuisition path or does this place only the target, just common iteslf, into the path as if it's contents were directly in the mirrowing folder? Thank you for clarifying, Gary ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Gary Duke Speer" <gspeer@cortech.org> Cc: <zope@zope.org> Sent: Sunday, June 13, 2004 4:40 AM Subject: Re: [Zope] Making Magic with Mirrowing Folders
Gary Duke Speer wrote at 2004-6-11 12:19 -0600:
I have been trying to configure Dieter's Mirrowing Folders Product. Using both direct _dtml-var_ links and Shane's AquisitionUnderstander I cannot see the product having any effect. I suspect it is because I do not understand either the product's intention or how to properly setup the mirrow link.
"Mirroring Folder" supports the following use case:
A multilingual site with multiple applications/subapplications/subsubapplications...
Each application (subapplication ...) contains language independent resources (business logic, common infrastructure, gluing scripts, ...) and language dependent resources (presentation, content).
All resources for an application are directly associated with this application; there is no further organisation based on e.g. type.
For these kinds of use cases, you would set up "MirroringFolder" as follows:
MirroringFolder/ common/ # mirrored by the mirroring folder application1/ subapplication1/ ... application2/ ... language1/ application 1/ ... language2/ ...
Note that Zope does not support optimally an organisation based on types (like "Images", "SQL", ...). Do not organize your resources like this for Zope. Organize, instead by applications (subapplications, ...). This lets take you optimal advandage from acquisition.
MirrowingFolder does not (or very limited) support organisation by type.
Note further that MirroringFolder does its magic during URL traversal. Do not expect any effect unless you traverse through the folder.
-- Dieter
Gary Duke Speer wrote at 2004-6-15 12:36 -0600:
Sorry, I'm still slightly unclear. Using the schema you described ... The mirrowing folder is obviously set in the acquisition path of application 1 in the context of language 1. ...
Assume you have set up "MirroringFolder" "MF" to mirror "common". When you then traverse to "MF/language/App/Subapp/.../Suu---ubapp/object" and arrive at "O", then the object determined by the longest existing subpath of "MF/common/App/Subapp/.../Suu---ubapp/object" is in the acquisition context of "O". -- Dieter
participants (2)
-
Dieter Maurer -
Gary Duke Speer