[Zope-dev] Product standardization

Martijn Faassen m.faassen@vet.uu.nl
Wed, 05 Jan 2000 15:37:46 +0100


Hi there,

Many of us are developing products for Zope; either in pure python, pure
ZClasses, or a combination. I'd like to make the products I'm making as
'Zope compliant' as possible; that is, they should use:

* the standard Zope web interface
* they should follow the standard Zope security conventions
* when possible, they should implement a number other standard Zope
interfaces, such as the properties interface and the object manager
interface.

The problem is that there is, as far as I know, no:

* standard Zope web interface definition
* standard Zope security conventions description
* description of other standard Zope interfaces

This is in part a documentation problem, but in part it's simply that
the standards are probably undefined. The classes to inherit from are
there in many cases, but I personally am in the dark concerning many
issues. I just practice 'voodoo programming' where I just do stuff
because I know I have to, but haven't a clue why. This is bad. 

So, could we start somekind of process in order to define what it means
to be 'Zope compliant'. I have in mind:

* standards documents 

* guidelines documents

* motivations and explanations of the standards and guidelines.

* tutorials and examples, such as products like the 'Boring' product
that give working and compliant examples.

* a peer review process; developers review each other's product code for
standard compliance. Product users can do part of the reviewing as well.

* Perhaps somekind of 'official approval stamp', that at least gives a
clue that the product you're using is mature and complaint. Though we
should watch out that this process wouldn't slow down development.

Doing this could help us in many ways; we learn more about how to write
a product, we learn more about how to write a *good* (secure, usable)
product, and finally the development of Zope itself is helped by
pointing out what people use/should use, and suggestions for future
directions.

Any comments, ideas?

Regards,

Martijn