[Zope-dev] RE: [Zope] Z Classes Tutorial: Rough Draft

[Michel Pelletier]

> -----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 )
>