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

[Florent Guillaume]

In article <41599140.1090306 at zope.com> you write:
> 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.

That's a use case I'm confortable with, and I know it's useful.


> 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?)

I believe this is best dealt with another specific TypeInformation
subclass, that has a schema setting and initializes its object as it
wishes.

(That's actually what we do in CPS, using our FlexibleTypeInformation.)


> 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.

I'd use that too (open action in popup, different icon, display with tooltip, etc).

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 71 59  http://nuxeo.com  mailto:fg at nuxeo.com