[Zope-CMF] Re: Major action exhancements

[yuppie]

Hi!


Dieter Maurer wrote:
>   *  Make actions (more precisely: action definitions) first class objects

+1

>      (with their own management pages), make them "PropertyManagers".
> 
>      This way, actions can get arbitrary additional attributes.

Do we need arbitrary additional attributes per item?

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

I'm not sure I understand this: Is 'evaluate' an alias for 
getAction(ec)['url'] or does it something else?

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

+0

This is a nice feature, no doubt. But if you make the properties 
customizable, we should discuss what the default properties are.

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

+1

This isn't fun. WorkflowTool is the Action Provider and there are other 
workflows than DCWorkflow.

See also <http://collector.zope.org/CMF/207>

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

What about making ActionProviderBase folderish, subclassing categories 
from OrderedFolder and storing Action objects inside of categories 
inside of Action Providers?

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

Great :-) Do you have cvs access?


Cheers,
	Yuppie