Hi all,

I've been playing with Zope 3 for a short while, and am ready to use it
seriously to put together an accounting application. Zope 3 is fantastic
stuff - in Zope 2 I really missed interfaces and other clean programming
patterns from when I was writing lots of Java. In fact, I even started a
Java component framework, called JChassis, that had services, factories,
etc configured in XML files that looked a lot like ZCML!

I did have a question about fields in interfaces. I've had a bit of a
search around and can't find the answers I need.

Most of the Zope 3 tutorials create interfaces like this:

class IFooA(Interface):

    bar = Choice(

However, my old Java habits make me prefer an interface like this:

class IFooB(Interface):

    getBar, setBar = accessors(

The second way means I can still enjoy automatic add/edit form generation
(I've tested it and it works), but isolate the implementation of the 'bar'
attribute. For example I could do this, which will work with forms:

class FooX(Persistent):
    bar = None
    def setBar(self, bar):
        self.bar = bar

    def getBar(self):
        return self.bar

Or even this:

class FooY(Persistent):
    myDB = new SomeDatabaseConnection()
    def setBar(self, bar):

    def getBar(self):
        return self.myDB.get(bar)

No 'bar' attribute needed! If I was implementing IFooA, then I would have
a "hard-coded" 'bar' attribute, and others might access this by value =
foo.bar or foo.ar= value, making hard to migrate to other scenarios like
FooY (although I guess they can be hacked in using
__setattr__ etc.? Not something I'd like to see in your average
application code).

So I'm inclines to use the IFooB approach by default to achieve more
abstract attributes. Am I missing something here in the IFooA approach
that allows me to do this anyway? Any help or pointers to help appreciated.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to