-----Original Message----- From: tsarna@endicor.com [mailto:tsarna@endicor.com] Sent: Friday, May 07, 1999 6:34 PM To: zope@zope.org Subject: Re: [Zope] Z Classes Tutorial: Rough Draft

In article <613145F79272D211914B0020AFF6401915C3FA@gandalf.digicool.com>, Michel Pelletier <michel@digicool.com> wrote:

...

A better solution is to create a Python class (in a Product) and sprinkle a little ZClass magic pixie dust in the __init__.py file to make the Python class (PClass) subclassable by a ZClass. Thus when you

Is there and example of this you can point us at? ("Hey, Mr. Zope Pusher, I need some magic pixie dust" :->)

(I've moved this thread to zope-dev) I thought I immediately followed to original message with a message containing the magic? Well, I didn't completely explain the magic anyway. Product __init__.py files used to contain attributes which defined some Product meta-data that Zope cared about, like meta_type, icon, __ac_permissions__ etc. These things are now actively registered with a method call: import MyModule def initialize(context): context.registerClass(MyModule.MyClass, permission='Add My Object' constructors=(MyModule.addMyClassForm, MyModule.addMyClass,), icon='MyIcon.gif', ) 'permission' is a permission that protects the constructors. The first element of the 'constructors' tuple is the method that gets called when the use selects the Class to be added (usually a form). Further elements are methods that you may want to protect under 'permission'. addMyClass, for example, is called by addMyClassForm, so you'll want them both to be guared by the 'Add My Object' permission. 'icon' is, I assume, farily obvious. This is how normal products get registered. Lets say however that you wanted to make a Product class subclassable? import MyModule def initialize(context): context.registerBaseClass(MyModule.MyClass) Both registerClass and registerBaseClass can be called in the same initialize, thus Products can be both standalone and subclassable. The old way still works for backward compatability (in fact, in true Digital Creations style, we have left most of our own products the old way, we'll get around to converting them *one* of these days). ;)

This is interesting. ZClasses didn't look quite powerful enough for some of the things I'd like to do with them. But a ZClass that subclassed from a read-write TinyTable would be perfect for many of those things.

Another beauty of this method is that your underlying Python class need not do anything Zope specific (except for __ac_permissions__ which is just passive meta-data anyway), it need only provide methods and attributes. The upsell of this is examplified in the Catalog. Catalog consists of three class, ZTablesCore, Catalog, and ZCatalog. The first provides a searching, indexing, cataloging mechanism. Other than __ac_permissions__, it has no Zope specific parts. It could be used in an IMAPd server, as an example, for doing searching. The second class, Catalog, is also written in Python and it contains an instance of ZTableCore.ZTable. It provides a wrapper around the Core with some classic Zopeish Python methods that would be too difficult to do in DTML. The third class, ZCatalog, is a ZClass which subclasses the Python Catalog class: it defines a slew of manage_* DTML and publicly available DTML that define the user and managment interfaces for Catalogs. I've been thinking that this three level design is pretty neat, The low level is a reusable component, the middle level deals with any lower level Zope specific stuff, and the ZClass level deals with the interfaces. In NotMail/IMAPAdapter for example, I could have a low level Python Class called IMAPCore which contains all of my connection and instantiation bull, a higher level Python Class called IMAPAdapter which does some of the formatting and User authenication needs for Zope, and a ZClass called NotMail which defines the mailer and managment interfaces. Of course three layers aren't necesary. Two work perfectly if you have no need for such an abstraction.

In my every-so-slowly-developing Palm Desktop in Zope, I have a screen that controls the order of conduits. Instead of a "first" button, I have "Earleir" (swap with one above) and "Later" (swap with one below) buttons, which seems friendlier. Maybe a First/Earlier/Later/Last (or First/Up/Down/Last) is what's called for.

This isn't really necesary, because you can pick multiple views before clicking first. For example, if you want to make the first thing last, just pick everything *but* the first then and they will all be put in front of it, thus making it last. Any combination of views may be placed first, which pretty much does everything needed. I have a feeling alot of people are going to ask that question, and my answer is going to be "Just play with it, you'll get it". -Michel

_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope

(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )