On 2004-03-01 3:44 PM, Chris Withers is reputed to have said:

Ian Beatty wrote:

...

OFS.ObjectManager.ObjectManager Products.ZCatalog.CatalogPathAwareness.CatalogAware OFS.PropertyManager.PropertyManager OFS.SimpleItem.SimpleItem

I'm pretty sure all you should actually need is:

...

OFS.ObjectManager.ObjectManager Products.ZCatalog.CatalogPathAwareness.CatalogAware

I presume you mean "for cut, paste, rename, etc." If I remove PropertyManager, my 'Properties' ZMI tab disappears. I'm not quite sure what SimpleItem provides for me, but it's in the examples I'm trying to work from.

...

OFS.SimpleItem.Item (subclassed by OFS.SimpleItem.SimpleItem) is supposed to provide cut-and-paste functionality. So, how might I be breaking it?

Show us some error messages, exceptions, types ,values and tracebacks adn amaybe we can help ;-)

Okay. This is bizarre. I've got a containment hierarchy of several classes; 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. When I try to rename an instance of A, the ZMI gives me the standard rename-object form; but when I type in a new ID and click 'OK', I get a ZMI page with a red exclamation mark, an 'OK' button, and nothing else except the word '_notifyOfCopyTo'. The error log shows a "Copy Error" 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 252, in manage_renameObject Copy Error: [html snipped] Now, If I view the ZMI for A, select a contained item of type B, and try to rename it, it fails but with a different signature: the notification page says 'The object term_0 does not support this operation' instead of '_notifyOfCopyTo'. ("term_0 is the ID of the B instance.) The error log shows a Copy Error with this 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 snipped] Attempting to rename an instance of C within B fails in the same way as renaming A (i.e., with a '_notifyOfCopyTo'). I've currently got A subclassing ObjectManager, CatalogAware, and PropertyManager; B subclassing the same plus SimpleItem (just as an experiment); and C subclassing the same as A. If I remove SimpleItem from B's list of superclasses, I still get the same set of errors, *except* when attempting to rename C. Now, I instead get the failure message 'You do not possess the permission required to call manage_addProduct/KBProduct/manage_KBCourseAddForm in the context of the container into which you are pasting, thus you are not able to perform this operation.' The Error Log traceback is: 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 378, in _verifyObjectPaste Copy Error: [html snipped] I'm completely bewildered here. Any suggestions would be tremendously appreciated. By the way, if this isn't the appropriate venue for this kind of question, please point me in the right direction. This list seems to focus on Zope's internals, but the Zope Users list seems a bit low-level for Python-based product development. Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty beatty@physics.umass.edu 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/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --

Ian Beatty wrote at 2004-3-1 16:38 -0500:

... Traceback (innermost last): ... Module OFS.CopySupport, line 230, in manage_renameObjects Module OFS.CopySupport, line 252, in manage_renameObject Copy Error: [html snipped]

Using that Zope is Open Source ;-) and looking at line 252 of "OFS/CopySupport.py" reveals: "ob._notifyOfCopyTo(self, op=1)" raises an exception. Try to find out why (e.g. by calling this method in an interactive interpreter or by adding a log message in the "except:").

... Traceback (innermost last): ... Module OFS.CopySupport, line 247, in manage_renameObject Module OFS.CopySupport, line 393, in _verifyObjectPaste Copy Error: [html snipped]

Cannot help you with this one: my code is too different from yours. But, you should look at line 393! -- Dieter

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 beatty@physics.umass.edu 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/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --