[Zope-CMF] [dev] RFC: Extensible propertysheet use cases

[Tres Seaver]

I have been asked over the past few weeks to consider a number of uses 
for extensible propertysheets, particularly in the types tool.  I would 
like to summarize the requests, as I recall them, and let the folks who 
have the usecases comment / elaborate on them.  We can then figure out 
how we want to address the use cases.

Use case:  Product installer records type-specific annotations

   Some products (CPS, for one) would like to register various bits
   of product-specific information about different content types, e.g.
   to enable data-driven policy decisions within the site.

   You could likewise envision some of the current properties (the
   discussable flag, the addability settings, etc.) as similar
   annotations, used only for particular "sub-frameworks" within the
   CMF.

   One natural way to model such type-specific annotations would be to
   loosen the schema of the type information objects, allowing additionsl
   properties to be added (e.g., by product installer tools / scripts).
   We would need to extend the export / import facilities of CMFSetup
   to take such additional properties into account, as well.

   Surfacing them at the ZMI level would allow the site manager to
   override the policy choices created by the installer.  I don't know
   whether allowing creation of new properties via the ZMI is worthwhile,
   but it might be a natural way to experiment with the names used
   eventually to create a profile or product code which used them.

   Status:  currently checked in for CMF 1.5 and the HEAD.

Use case:  Site manager sets default content annotations

   Some products would like to create "template properties" on the
   type information object, and use them to initialize (or provide
   defaults for) the equivalent properties on content instances.
   This is a simple form of schema-based programming, which would
   make some kinds of customization simpler without the need to
   create additional content classes (e.g., to add a special
   "routing_number" field to a Document.)

   We would probably implement this by adding an "Instance Properties"
   tab to the TypeInformation class, which kept the "template"
   properties segregated from those pertaining to the type info
   itself.  Again, the CMFSetup code for the types tool would need to
   take this extra propertysheet (sheets?) into account.

   Status:  A patch is supposed to be available for the types tool
     part;  the proposer might also offer the code used to create
     the content instance propertysheet (Mike?)

Use case:  Designer records action-specific annotations

   Some kinds of UI development would be simplified by the ability to
   make policy choices more data driven, e.g., the ability to associate
   snippets of Javascript or CSS with a given action.  The
   portal_actionicons tool might be one place for such annotations,
   if the apply to all uses of a given category + action_id;  however,
   some users have requirements for varying the snippets based on type,
   instead.

   We would likely implement this by adding a link on the main
   "Actions" tab which pointed to the "full" propertysheet for the
   action.  Again, we would need to extend CMFSetup to deal with the
   extra properties.

Comments, please.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com