[Zope-CMF] Major action exhancements

[Dieter Maurer]

CMF friends,

yesterday, I became aware that colleagues of mine had implemented
user actions by an individual macro for each action; the ActionsTool
was only used as a listing device; everything else was handled
in the macros -- in my view a conceptionally wrong approach.
On the other hand, I had to admit that the current actions feature
set was indeed far away from their requirements.
I make this proposal such that my colleagues (and others of course)
can implement their demanding appliciations in the future based
essentially on the "standard" features of CMF actions.


Use cases:

  *  add additional "attributes" on actions (description, help text,
     target, icons, ...)

  *  support different policies for unavailable actions
     (my colleagues need to represent unavailable actions
     by a "disabled" icon and "available" actions as an "enabled" icon

  *  support advanced user interaction features: e.g. buttom
     implementations by applets or javascript

  *  provide different URLs depending on context


Immediate measures:

  *  Make actions (more precisely: action definitions) first class objects
     (with their own management pages), make them "PropertyManagers".

     This way, actions can get arbitrary additional attributes.

  *  Make available action descriptions (as delivered by
     "listFilteredActionsFor") instances of a new
     "ActionDescription" class (rather than dictionaries).

     For backward compatibility, this class implements the
     "mapping" interface (such that instances can be accessed
     in the same way as the former dictionaries).

     Instances provide access to both the properties in
     the corresponding action definition as well as to
     information "evaluated" in the current context.

     The class provides an additional method "evaluate".
     This method evaluates a TALES expression in the same
     context used by the "ActionsTool" (or specialized action providers
     such as DCWorkflow) to evaluate the "standard" tales expressions.

  *  Add a new boolean property to actions (their definitions):
     "listAlways". This tells the ActionsTool that this
     action should be listed even when it is unavailable.
     "ActionDescriptions" get a new key "isAvailable" with
     the obvious meaning.

     This allows the implementation of different policies to
     represent action availability/inavailability.

  *  Make "DCWorkflow" actions consistent with the actions used
     elsewhere

  *  Replace the "ActionProviderBase" management page.

     This page is already weired. With the enhancements noted
     above, it would become a nightmare.

     I would take the pages used by DCWorkflow to summarize
     its various "containers" (states, transitions, ...).
     But I am not a designer. Maybe someone else can provide
     a better presentation.
     


Future measures:

  *  Define action types to capture common properties of a family
     of related action definitions (e.g. common icons for
     all "edit" actions (now done in the separate "ActionIconsTool").
     Action definitions inherit properties from the associated
     type (maybe types?) but can override them.

  *  Provide a registry for action categories.
     These action categories are first class objects ("PropertyManagers"),
     control the context to evaluate TALES expressions in and
     can get additional properties useful for presentation of
     this category.


I will soon start to implement the "immediate measures".

-- 
Dieter