[Zope-dev] Re: Custom class: cut,copy,rename?

Tue Mar 2 14:15:26 EST 2004

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 at 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/
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --