Though I can't speak at all for DC regarding this matter (this is probably Chris Petrilli's or Brian Lloyd's territory), I like the idea of having a slightly more formal definition of what constitutes a "good" product, even if that definition only consisted of a couple of pages of "shoulds" and "shouldn't"s. I also like the idea of a loose sort of peer review (other than someone just downloading the product, finding out it doesn't work, and posting to the mail lists). I would be willing to work on both. Chris McDonough mailto:chrism@digicool.com Digital Creations http://www.digicool.com Publishers of Zope http://www.zope.org
-----Original Message----- From: Martijn Faassen [mailto:m.faassen@vet.uu.nl] Sent: Wednesday, January 05, 2000 9:38 AM To: zope-dev@zope.org Subject: [Zope-dev] Product standardization
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
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )