Opinions sought on acquisition issue
Hello folks. I encountered an issue whilst site-tweaking last night and solved it immediately, but it has me intrigued as to how more experienced Zopists than I might approach it. Any wisdom you'd care to share on the matter would be appreciated. I have a site which includes a "weblog" type arrangement, and I keep the log entries in a folder called "log". There's a subfolder called "images" for pictures that I might want to include in log entries. There's also an "images" folder in the root directory for site-wide graphics such as the site logo. Thus, in the context of the "log" folder, "images" means the log-specific images only. This means I can't address the site-wide image objects in this context without reference to PARENTS[-1] or similar. {Side issue: wouldn't it make sense to have "ROOT" or similar as an alias for PARENTS[-1]?} Specifically, I can't say "images['site-logo.jpg']" in a Python expression, since it will look in the wrong "images" container. I resolved this issue by renaming "images" in the "log" directory to "log_images", thus ensuring that they have distinct names. I was planning on making this distinct-naming my general approach in future. The "images" name makes more sense from a URL perspective, but the "log_images" name makes more sense from an acquisition perspective. The reason that this is an issue at all, however, is because identically-named container objects to not acquire the contents of the containers they mask, if any. The "images" folder in the "log" folder masks the "images" folder at the root, thus *hiding* the contents of that folder rather than *acquiring* the contents of that folder. What would the implications be for Zope if acquisition meant that a failed method invocation resulted in further traversal of the namespace stack instead of immediate failure? Thus, if I try to reference "images['site-logo.jpg']", and the first "images" object found does not contain 'site-logo.jpg', would it be a good, bad, or ugly thing for Zope to *continue* the search for "images" objects containing a 'site-logo.jpg'? A container's contents might not be the only thing one could acquire in this manner: perhaps other methods could also perform some kind of continued search for success if they encounter an exception early on? This might get very confusing. I await with interest your pontifications on this matter. Regards, TFBW
The reason that this is an issue at all, however, is because identically-named container objects to not acquire the contents of the containers they mask, if any. The "images" folder in the "log" folder masks the "images" folder at the root, thus *hiding* the contents of that folder rather than *acquiring* the contents of that folder. What would the implications be for Zope if acquisition meant that a failed method invocation resulted in further traversal of the namespace stack instead of immediate failure? Thus, if I try to reference "images['site-logo.jpg']", and the first "images" object found does not contain 'site-logo.jpg', would it be a good, bad, or ugly thing for Zope to *continue* the search for "images" objects containing a 'site-logo.jpg'?
It would probably be not so good. It's my belief that we're trying to move to more explicitness, and this magic is hard to document. That's not to say that you can't make a container like this and hook __getattr__ and keep going!
I think it's a good thing for organizing the image elements of webpages, such that the site can start off with stock templates, and subsections can be progressively modified without re-coding the DTML (e.g. by graphic non-programmer types), by (e.g.) putting same-named .gif's in subdirectories.... sort of like, inheritance for .gif's. But... probably would be better to have a special foldertype to make that clear.
From: "Chris McDonough" <chrism@digicool.com>
it be a good, bad, or ugly thing for Zope to *continue* the search for "images" objects containing a 'site-logo.jpg'?
It would probably be not so good. It's my belief that we're trying to move to more explicitness, and this magic is hard to document. That's not to say that you can't make a container like this and hook __getattr__ and keep going!
I think it's a good thing for organizing the image elements of webpages, such that the site can start off with stock templates, and subsections can be progressively modified without re-coding the DTML (e.g. by graphic non-programmer types), by (e.g.) putting same-named .gif's in subdirectories.... sort of like, inheritance for .gif's. But... probably would be better to have a special foldertype to make that clear.
i agree, some type of generic folder wich would maybe stick to the top or bottom of the object list which would inherit from its parent too and would contain all generic stuff which is for the moment clurttering the root folder. lets say i have this folder1 / images folder1 / folder2 / images i'd like to call the images always as "images/xxx.gif" whether i'm in folder1 or folder2 that would greatly clean the code imho, $ven
Sven Fischer wrote:
I think it's a good thing for organizing the image elements of webpages, such that the site can start off with stock templates, and subsections can be progressively modified without re-coding the DTML (e.g. by graphic non-programmer types), by (e.g.) putting same-named .gif's in subdirectories.... sort of like, inheritance for .gif's. But... probably would be better to have a special foldertype to make that clear.
i agree, some type of generic folder wich would maybe stick to the top or bottom of the object list which would inherit from its parent too and would contain all generic stuff which is for the moment clurttering the root folder.
lets say i have this
folder1 / images folder1 / folder2 / images
i'd like to call the images always as "images/xxx.gif" whether i'm in folder1 or folder2
that would greatly clean the code imho,
Sorry, but if you're overriding same named graphics whose URL will appear to be identical, the browser cache will start playing hob with your site design. If you call all images with a relative URL, then even images that are acquired in this way will be reloaded, even though the browser has it already, since it'll be accessing the same image via a different URL. HTH, Michael Bernstein.
Wouldn't the (pre-rendered) path names be in DTML-var type statements?
From: "Michael R. Bernstein" <webmaven@lvcm.com>
Sorry, but if you're overriding same named graphics whose URL will appear to be identical, the browser cache will start playing hob with your site design.
If you call all images with a relative URL, then even images that are acquired in this way will be reloaded, even though the browser has it already, since it'll be accessing the same image via a different URL.
participants (5)
-
Chris McDonough -
marc lindahl -
Michael R. Bernstein -
Sven Fischer -
The Famous Brett Watson