RE: [Zope] How slow are Transparent folders?
I don't think they are slow, in that they just patch the way that namespace traversal is done and add a few namespaces... but they are definitely buggy; they will break CoreSessionTracking if you want to use more than one session id manager, among other things... Sean -----Original Message----- From: Dario Lopez-Kästen [mailto:dario@ita.chalmers.se] Sent: Tuesday, October 02, 2001 6:19 AM To: zope@zope.org Subject: [Zope] How slow are Transparent folders? Hello! I am wondering how slow transparent folders are. Anybody has exepreinced anything? /dario - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
I don't think they are slow, in that they just patch the way that namespace traversal is done and add a few namespaces... but they are definitely buggy; they will break CoreSessionTracking if you want to use more than one session id manager, among other things...
Hi! Transparent Folder ARE indeed slow. If you just use one or two and don't put much into them, it's fine. But we had sites with many nested TransparentFolders, and rendering the management screen (manage_main) sometimes took a couple of seconds instead of half a second or so with TransparentFolders removed. They make the system look up many more namespaces than necessary I guess. Stephan Richter wrote some "flatten" skript, so you can use TransparentFolders at design time and remove them all at once later. It's not a perfect solution however. We didn't have any problems with bugginess so far ... One solution I am personally working on is folders that just "register" or filter certain types of objects, so that you can have a folder (or tab) that shows all your SQL methods for example, though they actually are all in your root folder. Joachim
From: "Joachim Werner" <joe@iuveno-net.de>
One solution I am personally working on is folders that just "register" or filter certain types of objects, so that you can have a folder (or tab) that shows all your SQL methods for example, though they actually are all in your root folder.
What about having a folder which somehow 'registers' or concatenates the namespace of the enclosing folder with it's contents, perhaps only updating at certain times? Or... 'appearing' to it's enclosing folder not as one object but a list of stuff, everything inside it? I'll shut up now, since I'm not looking at the source :)
One solution I am personally working on is folders that just "register" or filter certain types of objects, so that you can have a folder (or tab) that shows all your SQL methods for example, though they actually are all in your root folder.
What about having a folder which somehow 'registers' or concatenates the namespace of the enclosing folder with it's contents, perhaps only updating at certain times? Or... 'appearing' to it's enclosing folder not as one object but a list of stuff, everything inside it? I'll shut up now, since I'm not looking at the source :)
You seem to think the other way around, but maybe that way the problem could be solved more easily. So we would have a parent folder that treats the contents of some of its children as if they were his own. This must be easy to do. The question is: Can we hide that in the management interface? Again, just overloading the main.dtml method with a version that uses, let's say an "myReallyOwnObjectValues()" instead of "objectValues()" should be straightforward. Just dreaming a bit ... Joachim
participants (3)
-
Joachim Werner -
marc lindahl -
sean.upton@uniontrib.com