Problems with Transparent Folder and Zope 2.3.3
Transparent Folders are used very often at iuveno. And we would like to do so in the future because they really provide an easy way to structure objects in folders. But with Zope 2.3.3 we get errors like that when we start an instance that uses Transparent Folders: Traceback (innermost last): File /home/customers/Zope-2.3.3-linux2-x86/z2.py, line 566, in ? File <string>, line 1, in ? File /home/customers/Zope-2.3.3-linux2-x86/lib/python/Zope/__init__.py, line 95, in ? File /home/customers/Zope-2.3.3-linux2-x86/lib/python/OFS/Application.py, line 91, in ? File /home/customers/Zope-2.3.3-linux2-x86/lib/python/OFS/Folder.py, line 94, in ? File /home/customers/Zope-2.3.3-linux2-x86/lib/python/OFS/SimpleItem.py, line 96, in ? File /home/customers/Zope-2.3.3-linux2-x86/lib/python/AccessControl/Role.py, line 105, in ? AttributeError: RoleManager The system is Linux (SuSE 7.0) with a binary Zope distribution. Any hints? Joachim
On Fri, 22 Jun 2001, Joachim Werner wrote:
Transparent Folders are used very often at iuveno. And we would like to do so in the future because they really provide an easy way to structure objects in folders. But with Zope 2.3.3 we get errors like that when we start an instance that uses Transparent Folders:
I've been getting several messages about this and today finally had time to investigate. It turns out that Globals.py is a little fragile--the new InitializeClass alias gets initialized at the bottom of the file. The import of ImageFile causes a whole series of things to be imported before InitializeClass is set up. Transparent folders always changed the order of import somewhat, and the recent addition of InitializeClass() to AccessControl/Role.py is what finally pushed Zope "over the edge", so to speak. The "right" solution is to patch Globals.py the same way I patched it today (on the CVS trunk). I moved the "InitializeClass = default__class_init__" statement to the line after the default__class_init__ import. This will be in effect in the beta release of Zope 2.4.0, but since I don't think we'll see a Zope 2.3.4, I didn't bother updating the Zope 2.3 branch. Tomorrow I hope to release a version of TransparentFolders that works around the problem, so you can wait for that instead if you like. I'm glad to know the product is being used. I don't think it will be in the core distribution since it causes a performance hit. Shane
Tomorrow I hope to release a version of TransparentFolders that works around the problem, so you can wait for that instead if you like.
Cool! Could you maybe put the patch that currently is applied in OFS/__init.py__ into a Hotfix? This would make it easier to use Transparent Folders together with INSTANCE_HOME installations where people just symlink to the product folders ...
I'm glad to know the product is being used. I don't think it will be in the core distribution since it causes a performance hit.
We know about the performance hit. But is it a big one? Joachim
On Fri, 22 Jun 2001, Joachim Werner wrote:
Tomorrow I hope to release a version of TransparentFolders that works around the problem, so you can wait for that instead if you like.
Cool! Could you maybe put the patch that currently is applied in OFS/__init.py__ into a Hotfix? This would make it easier to use Transparent Folders together with INSTANCE_HOME installations where people just symlink to the product folders ...
No. The patch has to be invoked before product initilization because ExtensionClass won't acknowledge the __getattr__() if it's added to ObjectManager too late. You can just put the patch in your SOFTWARE_HOME, though, and instances that don't have the product installed won't complain and won't have the performance hit.
I'm glad to know the product is being used. I don't think it will be in the core distribution since it causes a performance hit.
We know about the performance hit. But is it a big one?
I can't say. I haven't done any measurements. Shane
Shane,
I'm glad to know the product is being used. I don't think it will be in the core distribution since it causes a performance hit.
Shane
I use Transparent Folders "HEAVILY" in my site designs. There are some "Gotchas' that I have learned to deal with regards to acquisition, but I find their function indispensable. I am curious what the performance hit is that you mentioned?? Eric
On Friday 22 June 2001 06:55, Eric Roby wrote:
I'm glad to know the product is being used. I don't think it will be in the core distribution since it causes a performance hit.
I use Transparent Folders "HEAVILY" in my site designs. There are some "Gotchas' that I have learned to deal with regards to acquisition, but I find their function indispensable. I am curious what the performance hit is that you mentioned??
With transparent folders installed, every attribute lookup has to invoke a Python method (instead of staying at the C level). When you use implicit acquisition, this Python method is invoked very often. Depending on how much you use acquisition, this could be a significant hit, though I imagine on most sites it won't be a concern. CMF skins use a concept similar to transparent folders, but the CMF gets the problem under control by only allowing transparence in one folder (the portal root). If we're willing to start changing things at the C level, however, there are more options. Shane
Shane Hathaway wrote:
If we're willing to start changing things at the C level, however, there are more options.
Well, given how extremely useful skins seem as a concept (rather than just in their CMF context), along with Transparent Folders I'd love to help out here or vote for this in any way I can. It's been a while (2 years :-S) since I last did any C stuff and I've never done any with python so it could be a fun learning experience... ;-) BTW, would the stuff being talked about here allow CMF skins to come from locations other than the portal_skins tool? I know I've managed to solve my sharing-skin-layers-between-portal-instances problem but I aslo know that sooner or later, I'm going to hear "but I don't want to edit that skin on the file system" (especially if the server is in production mode) or, similarly, "I need to edit that skin TTW from another continent" cheers, Chris
On Friday 22 June 2001 10:59, Chris Withers wrote:
Shane Hathaway wrote:
If we're willing to start changing things at the C level, however, there are more options.
Well, given how extremely useful skins seem as a concept (rather than just in their CMF context), along with Transparent Folders I'd love to help out here or vote for this in any way I can. It's been a while (2 years :-S) since I last did any C stuff and I've never done any with python so it could be a fun learning experience... ;-)
Well, if the getattr function in TransparentFolderPatch were in C, I think it would be fast enough.
BTW, would the stuff being talked about here allow CMF skins to come from locations other than the portal_skins tool? I know I've managed to solve my sharing-skin-layers-between-portal-instances problem but I aslo know that sooner or later, I'm going to hear "but I don't want to edit that skin on the file system" (especially if the server is in production mode) or, similarly, "I need to edit that skin TTW from another continent"
Again, it doesn't allow layers from outside the portal_skins tool because of security considerations, not performance considerations. You could use LocalFS. Or you could use transparent folders in place of skins. Shane
Shane Hathaway wrote:
Well, if the getattr function in TransparentFolderPatch were in C, I think it would be fast enough.
Cool :-)
Again, it doesn't allow layers from outside the portal_skins tool because of security considerations, not performance considerations.
Erm... I know I'm being dense, but coudl you explain these again? cheers, Chris
On Monday 25 June 2001 04:47, Chris Withers wrote:
Shane Hathaway wrote:
Again, it doesn't allow layers from outside the portal_skins tool because of security considerations, not performance considerations.
Erm... I know I'm being dense, but coudl you explain these again?
That's alright. Skins are chosen before authentication. If we allowed skins outside the skins tool, people would expect security to apply (so that, for example, only certain users get to use certain skins). But since skins are chosen before authentication, you can either ignore security or only allow anonymously accessible folders. We chose to avoid the need for security checks in skin paths, since the other route would have yielded unexpected behavior (only anonymously accessible folders) and would have been slower. BTW skins can't be chosen after authentication in the general sense so don't ask. :-) You could make your own skins tool that chooses the path after auth, but either ZPublisher or your user folder would have to be patched to make it happen, but that's not an option for a release version of CMF. All of this may change in future versions. Shane
Shane Hathaway wrote:
If we're willing to start changing things at the C level, however, there are more options.
Is this an effort that would ultimately move Transparent Folders into the Zope "Core" ??? Eric
participants (4)
-
Chris Withers -
Eric Roby -
Joachim Werner -
Shane Hathaway