OrganizingZope

Organizing Zope

Zope provides very powerful, incisive features for creating and exposing applications to the network (particularly the web). It is built primarily in Python, a distinctly comprehensible and cogen high-level language for rapid development and extension. While Zope maintains some of Python's principles of simplicity, it is safe to say that its users lack the confidence of easy, comprehensive knowledge of the system. I suspect part of that is necessary in principle, because Zope's application domain is much more particular than Python's - and part unnecessary, an artifact of the development process and growth, which we need to rectify.

Here are some things i see being necessary to clean up - some of which are already being done, and some which i have suggestions about doing.

• TopDownViewOfZope? - from explaining what it is, to the components and how they connect together, to the things you need to tackle to do various kinds of things with it. It should be elaborated enough to branch into all things zope (including the rest of the things described here), providing a context to organize all the parts with respect to eachother.
• Using Zope Interfaces - The existing interfaces need discoverability (documentation, online help, maybe reflection - see http://www.zope.org/Members/michel/Projects/Interfaces/FrontPage), and need more or less cleaning. It would be nice to step back for and examination and then whatever rationalization, regularization, and refactoring is necessary, reducing as much as possible the unnecessary in the process.
• Packaging - Delivery of the core components with provisions for standalone use, e.g., ZODB, ZServer?, ZEO.
• Finishing Frameworks -
  • ZClasses? deliver through-the-web construction of applications. Their baking needs to be completed - my recollection is vague, here, the things that come to mind are refinement of property sheets functionality (maybe eby's stuff will help, here), security incongruities, subclassing blemishes and nesting of ZClass? definition blemishes.
  • Membership and/or portal and/or content management (PTK - http://www.zope.org/Products/PTK, Wiki - http://joyful.com/zwiki, maybe eby's pluggables, etc)
• Widgets Libraries - We could probably make it a lot easier for users to create forms, by providing validating input widgets - libraries of widgets which make it easy to create forms and plug in more than just basic type (int, boolean, string, etc) validation. (Maybe providing javascript immediate validation when enabled, though our recent disappointments w/javascript security may disqualify it.) Some examples of higher-level types:
  • Member id
  • URL (and special provisions for local vs remote, valid vs currently-exists, etc)
  • Email address
  • Boolean checkbox (using a :default hidden input to prevent absent values)
  • Toggling radio buttons for multi-choice input (including boolean) - see my tracker stuff.
  • Date/Time entry
  • Numeric range
  • Token collections
  • Constrained strings
  • What else?