[Zope-CMF] Re: Major action exhancements

[Dieter Maurer]

yuppie wrote at 2004-3-6 14:18 +0100:
>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?

I cannot define a set that can be considered complete.

Beside what we know already ("url", "title", "description", "name",
"icon", "target", "condition", "visible", "listAlways", "applet"),
others are imaginable: e.g. "class", "id" (to refer to in a CSS stylesheet),
"tooltip", "accesskey", ...

I fear the potential list is open ended.

The easiest way for us is to not restrict the set by the infrastructure
but allow additions, in case it is really necessary.

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

Some of the additional properties may be similar to "action"
and "condition", i.e. they may be TALES expressions.
In this case, there is a need to evaluate these expressions
in a context, most naturally the same context that is used
to evaluate "condition" and "action".

I saw two ways to implement this:

  *  provide a new property type "tales expression"
     which is evaluated automatically

  *  provide the "evaluate" method such that the UI
     can evaluate the expression as needed.

I opted for the second option as it easier to implement
and more flexible.


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

The default should almost surely be "false".
Usually, we want only available actions in our result.
Few applications will want to display unavailable actions by passive
icons.

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

This may not be sufficient:

  "categories" are a global concept (spanning different ActionProviders).
  Therefore, we probably still want a category registry.

  Nevertheless, I like the idea to locally organize actions
  by category (implemented as you suggested by "OrderedFolder").

>Great :-) Do you have cvs access?

No. I was (and I am) not ready to take responsibility with respect to
the extreme US patent laws.

I will first develop it against CMF 1.4.2 (that's what we still use).
After that, I can incorporate the changes in the then current CVS
version and finally provide patches against this version.
Someone with CVS write access can then integrate the patch
(after he checked potential patent issue :-) ).

-- 
Dieter