[Zope-CMF] Major action exhancements
dieter at handshake.de
Sat Mar 6 06:43:37 EST 2004
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.
* 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
* provide different URLs depending on context
* 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
* 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.
* 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
I will soon start to implement the "immediate measures".
More information about the Zope-CMF