[Zope-CMF] Re: [dev] refactoring listFilteredActionsFor: a proposal

[Yuppie]

Hi!


Thanks for your feedback.

Dieter Maurer wrote:
> Yuppie wrote at 2003-11-16 19:08 +0100:
>  > It's not enforced these paths are unique, but duplicates are ignored.
> 
> I may be an interesting use case to give different actions
> the same id but use them with different (disjoint) conditions.
> 
> If you want to support such use cases, you should ignore
> duplicates only after filtering.
> 
> Personally, I have no pressing need for these cases and I would
> require that ids are unique (within a single ActionProvider).

I'd really like to have an unique identifier. That would help to resolve 
issues like that: <http://collector.zope.org/CMF/195>

Regarding the use case you describe: Wouldn't it be sufficient to use 
different categories like we have for 'folderContents' in ActionsTool? 
You could use subcategories like 'globalCase1' and 'globalCase2'.

getActionInfo( ('globalCase1/myActionId', 'globalCase2/myActionId') ) 
would return the action depending on the condition. listActionInfos() 
and listFilteredActionsFor() would do the same.

> It may be a good idea to encapulate the filtering in its own
> function. I have an "ActionFolder" product (a hierarchically
> structured "ActionsProvider") that could benefit from such
> factorization.

The implementation I'm working on looks like this:
listActionInfos() encapsulates the filtering in a method. TypesTool is 
also a hierarchically structured ActionProvider. TypesTool and each 
TypeInfo inherit listActionInfos() from ActionProviderBase. The 
aggregation of the hierarchy is still done by listActions().

Could your 'ActionFolder' product benefit from a solution like that?

BTW: Is 'ActionFolder' publicly available? Sounds interesting.

>  > I propose to add these methods to the ActionProvider Interface:
>  > 
>  >      def listActionInfos(action_chain=None, object=None, ec=None,
>  >                          max=999, check_visibility=1,
>  >                          check_permissions=1, check_condition=1):
>  >          """ List Action info mappings.
>  > 
>  >          Permission -- Python only
> 
> Why "Python only"?

I didn't think much about this. The reason I wrote 'Python only' in the 
proposal is I didn't want to make this method public because it exposes 
a lot of information about the site if you disable the checks. I guess 
the right thing to do would be removing the docstring so the method 
isn't publishable. Suggestions are welcome!

>  > 
>  >          Returns -- Tuple of Action info mappings
>  >          """
> 
> Proposals should not only provide the method's signature
> but also describe (at least) the arguments and the return value.

Sorry.

'action_chain' is a sequence of action 'paths' (e.g. 'object/view').
If specified, only these actions will be returned in the given order. 
see <http://mail.zope.org/pipermail/zope-cmf/2003-November/019805.html>

If 'object' is specified, object specific actions are included. If 'ec' 
isn't specified, this object be used for creating the Expression Context.

'ec' is the Expression Context used to evaluate Expressions. If 'object' 
isn't specified, object will be taken from this argument.

The rest should be obvious. 'Action info mappings' are the dicts 
getAction() returns.

I'm not really happy with having 'object' *and* 'ec' as argument. But it 
makes listFilteredActionsFor faster if the Expression Context isn't 
build by each Action Provider. And on the other hand I'd like to have 
the possibility to pass in just the object. Would one 'context' argument 
be better that checks if the value is an Expression Context? Or 
shouldn't we care about performance and always build a new context from 
'object'? (I guess it wouldn't slow down listFilteredActionsFor 
significantly.)

> I am scared about the "max" argument.
> When you anticipate the need for such an argument, then you
> should almost surely provide some way to limit the amount
> of entries returned (such as e.g. interesting categories)
> Some feedback may be required that the list has been truncated, as well.

The use case I had in mind for 'max' is returning only the first result. 
This is used in combination with 'action_chain'. It doesn't make much 
sense to evaluate the fallback actions if we found an action that passes 
the checks. Would a 'only_first' flag better than 'max'?


Cheers,
	Yuppie