All I'm saying is there are other ways to cope, since I don't think TF can be 'fixed.' Eventually, I think it is likely that I will write a product that will do something to allow "views" of folder to be a native characteristic of the UI for the product, but I don't currently have time. Creating your own product and subclassing folder should pose no real issues, since the main thing you would be hacking would be just the UI (all the core functionality of ObjectManager derived classes would still be there via inheritance). You would add an extra DTML method on the filesystem within your product to provide a limited view of the folder, using some crieteria to filter (I don't think underscore is doable, so you will have to come up with another filter scheme, by substing in id, or meta_type, or something else). Some example code (not guaranteed to work, but a place to start) is below. It assumes that you subclass folder, and create a few methods to filter results of ObjectManager API calls, and use these filtered results in DTML replacing manage_main for your custom folder. Good Luck, and I hope this makes some sense. Sean ############################### import Globals from OFS import Folder, SimpleItem, ObjectManager, PropertyManager from Globals import Persistent, Acquisition import AccessControl class CustomFilteredFolder(Folder): """Custom Folder with Enhanced UI""" __ac_permissions__=( ('View management screens', ('manage_main', 'manage_viewall')), ('View', ('index_html')), ) manage_allcontents = Folder.manage_main #standard manage_main is now going to be another tab manage_main = Globals.HTMLFile('dtml/filteredContents', globals()) #file dtml/filteredContents.dtml #ZMI Tabs, customized: code copied from OFS.Folder and modified manage_options=( ({'label':'Filtered Contents', 'action':'manage_main'}, {'label':'All Contents', 'action':'manage_allcontents'}, {'label':'View', 'action':'index_html', 'help':('OFSP','Folder_View.stx')}, )+ PropertyManager.PropertyManager.manage_options+ AccessControl.Role.RoleManager.manage_options+ SimpleItem.Item.manage_options+ FindSupport.FindSupport.manage_options ) meta_type="Filtered View Folder" def __init__(self, id): """Initialize CustomFilteredFolder Instance""" Folder.__init__(self, id) self.hiddenObjectsIdPattern = ('sql') #assumption would be that if the string 'sql' appeared within #the id, that it would be hidden/filtered self.hiddenObjectsMetaTypes = ('Z SQL Method') #or, this could be done with a meta_type def objectItemsFiltered(self): """Filter results of OM.objectItems""" #unimplemented do something here def objectIdsFiltered(self): """Filter results of OM.objectIds""" #unimplemented do something here def objectValuesFiltered(self): """Filter results of OM.objectValues""" #unimplemented do something here ### Note: DTML for the filtered views would use objectItemsFiltered, where ### normally, it would use objectItems() instead (i.e. manage_allcontents ### would still use OM methods. -----Original Message----- From: Howard Hansen [mailto:zope@halfmagic.com] Sent: Monday, June 10, 2002 4:59 PM To: sean.upton@uniontrib.com; dirk.datzert@rasselstein-hoesch.de Cc: zope@zope.org; ct@gocept.com Subject: Re: [Zope] Zope 2.5 and TransparentFolder incompatibility Thanks for the response Sean, but could we try this again? This is not the answer I want to hear. Could you start your message with something like: "I've patched TF so it will work perfectly with 2.5 and all subsequent versions...." ;-) Seriously, this is not the first time I've heard the "TransparentFolders Considered Harmful" argument, and at some level I'm inclined to agree. Just not at the level of someone who has to wade through tons of dinky objects in his ZMI, nor at the level of someone who has to change lots of his code to account for other changes. It's too bad we can't use an underscore at the beginning of an object's id. Then we could have a "Hidden Contents" tab in the ZMI and view them that way. This would give us one transparent folder in each folder. A boy can dream. This leads me to a different question: how safe (or stable) is it to subclass folder and add some new behaviors to it? People blithely talk about doing it all the time, but my Zope sites total between 2000 and 5000 hits an hour. I get concerned about maintaining stability and performance. Obviously bad coding = bad performance and/or instability, but assuming competent coding, can I expect my subclassed folder to work as well as Folder? Howard Hansen http://howardsmusings.com/categories/zope ----- Original Message ----- From: <sean.upton@uniontrib.com> To: <zope@halfmagic.com>; <dirk.datzert@rasselstein-hoesch.de> Cc: <zope@zope.org>; <ct@gocept.com> Sent: Monday, June 10, 2002 3:34 PM Subject: RE: [Zope] Zope 2.5 and TransparentFolder incompatibility
TFs are bad bad bad... too much magic to the namespace stack. They break Core Session Tracking in Zope < 2.5, and likely don't work with sessions in Zope 2.5. The reason for this is that with the session id manager (which in CST has to have the same name every time), you cannot have more than one (because TF screws up the namespace stack globally, and makes the session id managers appear to already exist for a folder that they don't, or something like that, I can't remember exactly)... If you really want the benefits of TF without the headache and unpredictability, your best bet if you want to hide/sort objects in a folder is to create your own product, subclass folder, and hack the dtml files in the product for the UI to only show what you want (perhaps putting everything else into another ZMI tab or something?).
Sean