History for OrganizingZope

??changed:
-
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?