[Zope-CMF] [dev] enhancing Actions: a rough proposal

[Dieter Maurer]

yuppie wrote at 2004-11-21 21:14 +0100:
> ...
>The ActionsTool becomes an ordered folder subclass that contains 
>ActionCategory objects.

I would make "ActionProviderBase" such a folder, instead...

>ActionCategories are OrderedFolder based objects that contain Action 
>objects.

Fine.

>Actions are SimpleItemWithProperties based objects.

Fine.

>Tools are no longer Action providers.

I do not like this. It is not unnatural, to define
tool related action in this tool.

>Products add their Actions to the 
>ActionsTool like they add their skin layers to the SkinsTool.

I find SkinsTool configuration for additional tools/products
quite difficult and error prone (in CMF 1.4; I did not yet look
at CMF 1.5) -- much more difficult than action configuration.

I would not like a similar mechanism for action configurations.

>Type Actions are no longer defined in the TypesTool.

I do not like this.

Different types on top of the same content class often
have different actions.

>Using Method 
>Aliases, one Action defined in the ActionsTool can be used for all types 
>or a subset.

The "alias" mechanism is often not flexible enough: they
cannot handle request parameters, for example.

We use, e.g.:

   Name: Add NewsItem
   URL:  string:$content_url/addItem?type=NewsItem
   
   Name: Add AdItem
   URL:  string:$content_url/addItem?type=AdItem

> ...
>CMFActionIcons becomes obsolete. The consolidation of type Actions makes 
>the post-processing of Actions useless. Icons can be defined in the 
>Action objects themselves. Having all Actions of a category in one 
>place, 'Priority' becomes useless. They can be ordered in their container.

It is not natural, to define all actions in one place.

Especially, implicitly defined actions (such as workflow actions)
would not be in the central place.

-- 
Dieter