[Zope] FW: [Zope] Using Zclasses

Tue, 6 Jul 1999 08:20:16 -0400

> -----Original Message-----
> From: Michel Pelletier 
> Sent: Tuesday, July 06, 1999 8:08 AM
> To: 'Alexander Staubo'
> Cc: 'bruce@perens.com'
> Subject: RE: [Zope] Using Zclasses
> 
> 
> 
> 
> > -----Original Message-----
> > From: Alexander Staubo [mailto:alex@mop.no]
> > Sent: Tuesday, July 06, 1999 1:59 AM
> > To: Zope Mailing List (E-mail)
> > Subject: RE: [Zope] Using Zclasses
> > 
> > 
> > Sort of; if I have interpreted unofficial statements on the 
> > list from DC
> > people correctly, ZClasses replace products in many cases, 
> > although very
> > possibly not all; for example, I'm quite certain that most 
> of Confera
> > could have been implemented as a ZClass. Certainly the 
> product API is
> > complex (or undocumented) to an extent which makes ZClass more
> > desirable, moreover from an object-orientated design perspective,
> > products are inferior.
> > 
> 
> Let me help this discussion with some Jargon Control (tm).  
> Let's step back through the sands of time to Zope 1.10 when 
> ZClasses were just a glimmer in Jim's eye.  Then we had 
> Products.  Products are basicly Python Packages that let you 
> extend the object space of Zope.  If your Product (package) 
> complied with certain rules, it was possible (although not 
> neccesary) for that Product to register with Zope one or more 
> Python classes which Zope could then instanciate via whatever 
> means the Product author wanted (usualy through the 
> management interface, altough it is possible for Python 
> Products to define new DTML tag classes).
> 
> Fast forward a few thousand CVS checkins to Zope 2.0.0a.  
> There are still Products and Classes, but now there are two 
> kinds (at a high level) of each.  There are still good old 
> fasioned Python Products and Python Classes, but now there 
> are Web Products and ZClasses.  To Zope, they are 
> indestiguishable; Products are managed through the same 
> interface, and Classes can be instanciated in Zope.  However, 
> quite of bit of the infrastructure of creating a Product that 
> adds Classes to Zope has been abstracted into a web 
> management interface.  Nothing has changed at the lower 
> level, a Products job is still to extend the object namespace 
> of Zope, and a classes job is still to define new types of 
> objects.  So in light of this, ZClasses are not really meant 
> to 'replace' Products.
> 
> What they can replace are certain candidate Python classes.  
> We discovered in much of our development of Products that 
> alot of our code was identical across products.  All 
> packages, modules, and classes that played nicely with Zope 
> all played nicely in exactly the same way.  In fact, for very 
> simple Products (like the Poll Product) there was nothing the 
> code in the object did that couldn't be done in DTML; the 
> Python code involved was simply a wrapper around a concept, 
> the concept being an object that knows how to hook into Zope. 
>  This concept is was spawned ZClasses.
> 
> ZClasses are very handy, but they are not superior to Python 
> classes.  In fact, they are quite a bit weaker, which is why 
> it is possible for a ZClass to subclass a base class (which 
> may be either Z or Pythonic).  This weakness is payed off in 
> spades however, when it comes to designing, managing, and 
> playing with new types of objects in Zope.  A 'Product' can 
> now be whipped up very quickly, prototyped and modified all 
> without leaving your web browser.
> 
> Your mention of Confera is a good one, because that is the 
> perfect example of a Zope product that can be written with a 
> ZClass, but not entirely.  All of the user interface can be 
> designed with a ZClass, but because Confera uses the indexing 
> machinery, at some point the 'ZConfera' author will need to 
> drop down to Python to index the messages.  This can be done 
> as external methods, or as a Python class that the 'ZConfera' 
> class subclasses.
> 
> Also, the Product API, undocumented though it is, is still a 
> necesary part of serious ZClass design.  The benefit of 
> ZClasses is that most of the more mundane and undocumented 
> parts of Product development are made invisible by web 
> products and ZClasses.   However, the more interesting parts 
> of the Zope API are still needed for ZClasses to do much of 
> anything useful.  Also, ZClasses which subclass something 
> like 'ObjectManager' completely assume that part of the Zope 
> API as their own.
> 
> -Michel
> 
> > (If that is what you asked. If the question was "What is the product
> > interface for?" then the answer isn't "So you can edit properties
> > through the standard management interface," and it isn't "So you can
> > have properties as objects," either.)
> > 
> > --
> > Alexander Staubo             http://www.mop.no/~alex/
> > "What the hell, he thought, you're only young once, and threw
> > himself out of the window. That would at least keep the element of
> > surprise on his side."
> > --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
> > 
> > >-----Original Message-----
> > >From: bruce@perens.com [mailto:bruce@perens.com]
> > >Sent: 6. juli 1999 07:26
> > >To: alex@mop.no; zope@zope.org
> > >Subject: RE: [Zope] Using Zclasses
> > >
> > >
> > >From: Alexander Staubo <alex@mop.no>
> > >> Your second question is trickier, because Zope does not,
> > >afaik, support
> > >> properties that are objects. It's possible, but I believe
> > >you can't edit
> > >> these properties through the standard management interfaces.
> > >
> > >Naievely I ask, isn't that what the product interface is for?
> > >I must be missing
> > >something.
> > >
> > >	Thanks
> > >
> > >	Bruce
> > >
> > 
> > 
> > _______________________________________________
> > 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 )
> > 
>