[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