Question regarding acquisition behaviour.
Hi List, It is my understanding that while acquisition will traverse up the directory tree, it will only do so until it finds a match, and then it will restart from that directory. So if I'm in script 'someScript' looking for 'container.HTML.pageX' and my hierarchy looks something like this: someSite -HTML --pageX -subSite1 --about ---HTML ----pageA ----pageX --contact ---HTML ----pageA if someScript is in 'someSite/subSite1/about' then I will get the result: 'someSite/subSite1/about/HTML/pageX' But if someScript is in 'someSite/subSite1/contact' I won't get anything. It will find the HTML folder, and give up when there's no 'pageX'. What I would like is the result: '/someSite/HTML/pageX' Is there a way around this, to force acquisition to continue traversing up the directory if it hits a dead end? Or some alternative? Or is this behaviour necessary? Thanks, Alec Munro
I don't think that I have burned the right incense and said the correct incantations. :) Previously, I would do this in Linux - copy a file to the Products directory, untar it, restart Zope and there it would be. Well, this time, I thought that I would try the process using the ZMI. I go to the Product folder and click the Add button, but am confronted with no facility to browse to upload a file. So, I go back to Root, Add a File, where I can browse on my local machine and upload it to the machine which is running Zope. Kewl. Now I have file.tgz file in the Root folder. Now, I click the check box and click the Copy button, go to the Product directory and click Paste. I get an error saying the the "The object file.tgz does not support this operation." OK, so then I think that I can export/import. So, I export and the file is plopped somewhere in /var/lib/zop and now it is called file.tgz.zexp and the file size has grown slightly. I move the file (really didn't want to jump back into Linux) to the import directory. Back to the Products folder in ZMI, I button import. I get the same error message. Am I trying the impossible? or...? dennis - have gudulka, will travel http://KafanaKlub.com
On Tue, 2003-11-25 at 09:15, Dennis Godfrey wrote:
I don't think that I have burned the right incense and said the correct incantations. :)
Previously, I would do this in Linux - copy a file to the Products directory, untar it, restart Zope and there it would be.
That is the correct way to install products... keep doing that.
Well, this time, I thought that I would try the process using the ZMI. I go to the Product folder and click the Add button, but am confronted with no facility to browse to upload a file.
That button doesn't do what you want it to do. A filesystem product may only be added via the filesystem. HTH, Dylan
On Tue, 2003-11-25 at 08:51, Alec Munro wrote:
Hi List,
It is my understanding that while acquisition will traverse up the directory tree, it will only do so until it finds a match, and then it will restart from that directory.
Sort of. It works fist by containment (physical path) then by context (how things are arranged in the URL). If it finds a match by containment, it won't look at context.
So if I'm in script 'someScript' looking for 'container.HTML.pageX' and my hierarchy looks something like this:
someSite -HTML --pageX -subSite1 --about ---HTML ----pageA ----pageX --contact ---HTML ----pageA
if someScript is in 'someSite/subSite1/about' then I will get the result: 'someSite/subSite1/about/HTML/pageX' But if someScript is in 'someSite/subSite1/contact' I won't get anything.
That seems correct.
It will find the HTML folder
The one *in* someSite/subSite1/contact
, and give up when there's no 'pageX'
There isn't one... not that can be found from the folders you're in and/or have acquired.
. What I would like is the result: '/someSite/HTML/pageX'
Then you should ask for that result. Try this: .../container/someSite/HTML/pageX A better answer, long-term is not to re-use folder names so liberally. The more unique they are, the easier it will be to know whether acquisition is working and why it isn't when it's not. HTH, Dylan
Thanks to Dylan for the response, and it is generally what I've been doing, though I had to get more complicated in most cases. The problem with it is that I don't always know the name of the root folder of the site I will be implementing this on. So including the root folder into the path is not feasible. As well, the suggestion for not reusing folder names might work, but I really prefer to be able to organize files by type. Otherwise I would have many folders that contained well over a hundred files. While that is not a technical challenge, it does present a usability one. Based on that, I see two things that could solve my problems, without me having to give up organizing with folders. ;) 1. A form of acquisition that allowed me hard-code as much of the path, starting at the right, as I wished. For example: container.acquire('HTML/pageX') 2. A type of folder that automatically acquired the files of it's subfolders. So I could still organize, but as far as acquisition was concerned, it would be as if everything was in a single folder. 2A. Make folder views filterable (perhaps via a drop-down). So I can view only page templates, or only python scripts, etc. When navigating the tree, you could have icons next to the folder names, that could be used to select the views. Perhaps some of this functionality already exists? Thanks for your time, Alec Munro Dylan Reinhardt wrote:
On Tue, 2003-11-25 at 08:51, Alec Munro wrote:
Hi List,
It is my understanding that while acquisition will traverse up the directory tree, it will only do so until it finds a match, and then it will restart from that directory.
Sort of. It works fist by containment (physical path) then by context (how things are arranged in the URL). If it finds a match by containment, it won't look at context.
So if I'm in script 'someScript' looking for 'container.HTML.pageX' and my hierarchy looks something like this:
someSite -HTML --pageX -subSite1 --about ---HTML ----pageA ----pageX --contact ---HTML ----pageA
if someScript is in 'someSite/subSite1/about' then I will get the result: 'someSite/subSite1/about/HTML/pageX' But if someScript is in 'someSite/subSite1/contact' I won't get anything.
That seems correct.
It will find the HTML folder
The one *in* someSite/subSite1/contact
, and give up when there's no 'pageX'
There isn't one... not that can be found from the folders you're in and/or have acquired.
. What I would like is the result: '/someSite/HTML/pageX'
Then you should ask for that result. Try this:
.../container/someSite/HTML/pageX
A better answer, long-term is not to re-use folder names so liberally. The more unique they are, the easier it will be to know whether acquisition is working and why it isn't when it's not.
HTH,
Dylan
On Tue, 2003-11-25 at 09:55, Alec Munro wrote:
The problem with it is that I don't always know the name of the root folder of the site I will be implementing this on. So including the root folder into the path is not feasible.
You can use another object as an anchor point instead. You could, for example, put an object in each site root folder called site_root. Now you can acquire anything else contained by your site root thus: .../some_container/site_root/path/to/method
1. A form of acquisition that allowed me hard-code as much of the path, starting at the right, as I wished. For example: container.acquire('HTML/pageX')
Take a look at restrictedTraverse().
2. A type of folder that automatically acquired the files of it's subfolders.
I'm not sure that would be helpful. How, for example, would this folder resolve the much-used name "HTML"? HTH, Dylan
On Tue, Nov 25, 2003 at 01:55:47PM -0400, Alec Munro wrote:
Thanks to Dylan for the response, and it is generally what I've been doing, though I had to get more complicated in most cases. The problem with it is that I don't always know the name of the root folder of the site I will be implementing this on. So including the root folder into the path is not feasible. As well, the suggestion for not reusing folder names might work, but I really prefer to be able to organize files by type. Otherwise I would have many folders that contained well over a hundred files. While that is not a technical challenge, it does present a usability one.
Based on that, I see two things that could solve my problems, without me having to give up organizing with folders. ;)
1. A form of acquisition that allowed me hard-code as much of the path, starting at the right, as I wished. For example: container.acquire('HTML/pageX')
You could implement this yourself, possibly as an External Method. It shouldn't be too tricky. However, zope's acquisition policy is not pluggable AFAIK, so you'd have to call your method explicitly. So your expression above would be something like: container.special_acquire('HTML/pageX') Or you could implement (or wrap) it with a traversable Python Script, which would allow you to visit things by path, like: container/special_acquire/HTML/pageX
2. A type of folder that automatically acquired the files of it's subfolders. So I could still organize, but as far as acquisition was concerned, it would be as if everything was in a single folder.
The CMF SkinsTool does something related to this. There is also TransparentFolder which may be closer to what you want.
2A. Make folder views filterable (perhaps via a drop-down). So I can view only page templates, or only python scripts, etc. When navigating the tree, you could have icons next to the folder names, that could be used to select the views.
That would be a nice, wouldn't it :-) CMF has filtered folder views, but the ZMI does not. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE APOCRYPHAL PICKLE! (random hero from isometric.spaceninja.com)
Alec Munro wrote at 2003-11-25 12:51 -0400:
It is my understanding that while acquisition will traverse up the directory tree, it will only do so until it finds a match, and then it will restart from that directory.
It looks up each name and commits as soon as it was successful. The next name will them be search from this place.
So if I'm in script 'someScript' looking for 'container.HTML.pageX'
This looks up "HTML" from "container" and then "pageX" from "container.HTML". There is no backtracking (choosing a different "HTML") when "pageX" cannot be found from "container.HTML".
... Is there a way around this, to force acquisition to continue traversing
You cannot use acquisition for this. But, when you know your paths, you can use "restrictedTraverse" to access any object -- maybe with a path from root. -- Dieter
participants (5)
-
Alec Munro -
Dennis Godfrey -
Dieter Maurer -
Dylan Reinhardt -
Paul Winkler