On 2004-03-01 7:21 PM, Max M is reputed to have said: > So if SimpleItem is before ObjectManager the traversal order of the > parent objects will make shure that you get the wrong methods :-( So > this will *not* work...
Aha... that explains a lot of my "irreproducible" behavior. After correcting the order of inheritance, *most* of the bizarre behavior is gone. But not all. Here's what I have now: a hierarchy of five custom classes, pretty close to identical for now. All five subclass ObjectManager, CatalogAware, PropertyManager, and SimpleItem in that order. The top one ("A") may be added to any old Zope folder; B may only be added to A; C to B; D to C; and E to D. Standard Zope Images may be added to E. I can now freely rename A, C, D, and any images within an instance of E. I *cannot* rename B or E; when I try, I get "The object term_0 does not support this operation" ('term_0' is an instance of B), with the following traceback: Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module OFS.CopySupport, line 230, in manage_renameObjects Module OFS.CopySupport, line 247, in manage_renameObject Module OFS.CopySupport, line 393, in _verifyObjectPaste Copy Error: <HTML> <HEAD> <TITLE>Not Supported</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <FORM ACTION="manage_main" METHOD="GET" > <TABLE BORDER="0" WIDTH="100%" CELLPADDING="10"> <TR> <TD VALIGN="TOP"> <BR> <CENTER><B><FONT SIZE="+6" COLOR="#77003B">!</FONT></B></CENTER> </TD> <TD VALIGN="TOP"> <BR><BR> <CENTER> The object <EM>term_0</EM> does not support this operation. </CENTER> </TD> </TR> <TR> <TD VALIGN="TOP"> </TD> <TD VALIGN="TOP"> <CENTER> <INPUT TYPE="SUBMIT" VALUE=" Ok "> </CENTER> </TD> </TR> </TABLE> </FORM> </BODY></HTML> I've scrutinized all five classes, and I can't figure out what makes B and E different from the rest. On 2004-03-02 9:55 AM, Chris Withers is reputed to have said: >> I'll talk about the top 3. I've got things set up so that I can create >> instances of A within my Zope root (or any other "normal" Zope folder), I >> can create instances of B and only B within A, and I can create instances of >> C and only C within B. > > How have you tried to make that happen? My __init.py__ file registers all five classes, but all except the top one (A) have the line 'container_filter = containerFilter_makePrivate,' where 'containerFilter_makePrivate' is a trivial method that returns zero. In other words, classes B through E reject all containers. Then each of the classes declares "all_meta_types" for the classes it is supposed to contain, like this (from A): all_meta_types = ( { 'name':'Type B', 'action':'manage_addProduct/MyProduct/manage_BAddForm' }, ) Since explicitly calling the constructors avoids the container_filter, this has the effect that I want. >> I presume you mean "for cut, paste, rename, etc." If I remove >> PropertyManager, my 'Properties' ZMI tab disappears. > > That's odd, I could have sworn ObjectManager used that. Hmmm, maybe use Folder > instead of ObjectManager ;-) I've been tempted to subclass Folder instead, but I'm not sure what other undesired functionality I might unwittingly inherit. > The HTML would be handy ;-) Okay, see the traceback above in my response to Max M. > What version of ZOpe are you using? Zope 2.7.0 rc2, which claims to be "(unreleased version, python 2.3.3, darwin)" in the ZMI. > I suspect the way you're trying to ensure only certain types of object can go > in certain containers is to blame here... I tried removing all the container_filter statements from the registration code in __init.py__, so that all classes are addable to any Zope folder. I still can't rename an instance of B that's inside A, but if I add a B to the ZMI root folder, I **can** rename it there! Same with E. So the class isn't intrinsically un-renamable; it's either a function of how it was added, or of the container. I still can't get my head around why the problem only occurs for B and E. Thanks for the thoughts. Is there a better or more standard way to create a folderish object that can only contain a specific set of other object types, other than using all_meta_types? Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty [EMAIL PROTECTED] Physics Education Research Group voice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-4525 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )