[Zope] ZClass, Base Classes and logic (QUEST)

[Martijn Pieters]

From: "Oscar Picasso" <picasso@videotron.ca>
> Hi,
>
> Most of the time when someone complains about DTML syntax or the learning
curve
> and so on, the answer is we should code our logic in python if we know
this
> language. That's what I am trying to do because I love Python.
>
> However, many times I don't know how to import my logic in Zope.
>
> example:
>
> I wrote a very simple module MyTest.py:
> ##################################
> class SuperClass:
> def __init__(self):
> self.a='This is a in SuperClass'
>
> class MyClass(SuperClass):
> def __init__(self):
> SuperClass.__init__(self)
> self.b='This is b in Myclass'
> ##################################
> In the python interpreter I do the following things:
> >>>import MyTest
> >>>import MyTest.MyClass
> >>>t=MyTest.MyClass.MyClass()
> >>>t.a
> 'This is a in SuperClass'
> >>>t.b
> 'This is b in Myclass'
>
> That's what I expected. Now I intall the package in zope.  I make a ZClass
which
> only Base class in MyClass. Its metatype is MyClassClass, so it appears on
the
> popup menu near the Add button.
>
> But when I try to add an instance I get the following message:
>
> Error Type: TypeError
>           Error Value: unbound method must be called with class instance
1st
>           argument
>
> I guess that the problem is the line
> SuperClass.__init__(self)
>
> ==>however I don't understand why it works fine with the python
interpreter and
> why not in Zope.
>

This is a side effect of using Extension Classes. From ExtensionClass.stx:

  Overriding methods inherited from Python base classes

    A problem occurs when trying to overide methods inherited from
    Python base classes.  Consider the following example::

      from ExtensionClass import Base

      class Spam:

        def __init__(self, name):
            self.name=name

      class ECSpam(Base, Spam):

        def __init__(self, name, favorite_color):
            Spam.__init__(self,name)
            self.favorite_color=favorite_color

    This implementation will fail when an 'ECSpam' object is
    instantiated.  The problem is that 'ECSpam.__init__' calls
    'Spam.__init__', and 'Spam.__init__' can only be called with a
    Python instance (an object of type '"instance"') as the first
    argument.  The first argument passed to 'Spam.__init__' will be an
    'ECSpam' instance (an object of type 'ECSPam').

    To overcome this problem, extension classes provide a class method
    'inheritedAttribute' that can be used to obtain an inherited
    attribute that is suitable for calling with an extension class
    instance.  Using the 'inheritedAttribute' method, the above
    example can be rewritten as::

      from ExtensionClass import Base

      class Spam:

        def __init__(self, name):
            self.name=name

      class ECSpam(Base, Spam):

        def __init__(self, name, favorite_color):
            ECSpam.inheritedAttribute('__init__')(self,name)
            self.favorite_color=favorite_color

    This isn't as pretty but does provide the desired result.

--
Another way, and I used this, is by bypassing the method binding, by
accessing the unbound method. The above example could also be:

        def __init__(self, name, favorite_color):
            ECSpam.__init__.im_func(self, name)
            self.favorite_color=favorite_color


> Others behaviors of Zope:
> suppose i add the following line in the MyClass __init__ function:
> self.d='I am d'
>
> No problem when I run it with the interpreter:
> >>>t.d
> 'I am d'
>
> In zope:
> <dtml-var "MyClassInstance.d">
> renders:
> Error Type: AttributeError
>           Error Value: d
>
> I get the right value of d only with the new instances of MyClass. On the
other
> hand if MyClass has a property sheet, all the instances are updated if
change
> the property sheet.
>
> ==>So again, why these differences in the behavior of ZClass instances
depending
> of which part we modify (the python Base Class or the Zope ZClass)?

The propertysheet variables become class variables, which are persisted as
well. So when you retrieve an instance, the persisted class that described
the behaviour of that instance is taken from the ZODB, and the new persisted
class has the .d attribute there.

In your python class however, .d is a instance variable, it gets set when a
new instance is created and __init__ is called. And exisiting instances
don't get __init__ called again, after all they were initialized already.
They only get their current state restored, and that state never included
the d attribute. Only on new instances, where __init__ is called, does d get
set.

You could get around this by making d a class variable, by adding d='I am d'
to you class definition. Alternatively, you could use the __setstate__
method, it is called when the instance is retrieved from the ZODB. It
revives the state of the object, and you'll have to remember to call
Persitant.__setstate__ as well:

    def __setstate__(self, state):
        Persistent.__setstate__(self, state)
        if not hasattr(self, 'd'):
            self.d = 'I am d'

>
> I really love Zope but I prefer code in python. However I hit often the
wall
> when I try to put the pieces together. I think that speaking about
> documentation : clear API docs would be, for me the most important.
> What behavior could I expect from the differents parts of Zope.
>
> Example of docs I find useful with other 'languages':
> Python Library Reference
> Java API documentation

We are working on this. Two projects that will work towards solving this:

  http://www.zope.org/Members/Amos/Documentation/Plan
  http://www.zope.org/Members/michel/Projects/Interfaces/FrontPage

Martijn Pieters
| Software Engineer    mailto:mj@digicool.com
| Digital Creations  http://www.digicool.com/
| Creators of Zope       http://www.zope.org/
|   The Open Source Web Application Server
---------------------------------------------