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

[Dieter Maurer]

Tres Seaver wrote at 2004-9-28 12:28 -0400:
> ...
>Use case:  Product installer records type-specific annotations
> ...
>   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.
> ...

I would like to see this.

Separate property sheets (as proposed by Lennard) would be ideal
but extension by additional (ungrouped) properties would be enough.

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

You already do that: but for a single attribute only "portal_type".

I did not yet need this feature -- and could easily implement
it with a special "initial_view".

But I would not mind when the CMF would support it...

>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 lobbied heavily for this extension -- and implemented it for
our CMF version. It is used heavily in our applications:

    *  in order to control the "a"(nchor) attribute "title" and "target"

    *  in order to support "object" buttons (implemented in Java)

    *  in order to provide CSS "class" attributes

    *  in order to provide JavaScript event handlers

    *  to provide arguments for calls that compute the true "url",
       "title" and "text" of the generated URL

Alexander Limi wished it for adding a "description" to actions.


I would be happy to see it supported in the official CMF;
it would reduce the differences to our private version...

-- 
Dieter