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

Kapil Thangavelu k_vertigo at objectrealms.net
Wed Dec 1 02:11:12 EST 2004


Hi Yuppie,

On Sun, 2004-11-28 at 19:21 +0100, yuppie wrote:
> Hi Kapil!
> 
> 
> Kapil Thangavelu wrote:
> > okay. could you elaborate on what sort of extensions or use cases are
> > possible with this new model, that currently can't be implemented?
> > the only ones i've seen advanced are relating to have a central location
> > for ui based action manipulation. and even this seems not nesc true if
> > workflow and type actions are going to be manipulated separately, ie. if
> > compatiblity with existing providers is going to be maintained, and
> > instead there will be need be two models, which is fine by me ie. if
> > existing functionality and action provider impl can be preserved.
> 
> Using Actions that subclass from SimpleItemWithProperties...
> 
> - makes it easier to create custom Action classes with custom properties
> 
> - makes it easier to implement property schemas based on PropertySheets, 
> see this thread for a related discussion:
> http://mail.zope.org/pipermail/zope-cmf/2004-September/021307.html
> 
> 

sounds good.

> Using providers and categories that subclass from OrderedFolder...
> 
> - allows to plug in custom Actions and categories
> 
> - allows to use all the standard methods to add/copy/move/sort Actions 
> and categories
> 
> - makes it easy to create hierarchical menus using subcategories
> 
> 

sounds good.

> Moving all Actions into one central ActionProvider...
> 
> - makes the ActionIconsTool redundant
> 

wouldn't this tool be redundant once actions have properties, ie this
functionality can be directly folded into the base action
implementation.

> - clears up the ZMI

in terms of the action ui sure. but i think there might be other ways to
meet this goal. a query based interface, ie. with query of providers and
the actions tool and collation of actions by category.

> 
> > in terms of negatives and feature removal of this proposal, removing
> > action providers for, means to me replacing dynamic capabilities of
> > action providing by the application, in favor of relying on action level
> > tales filtering. using different action category implementations can
> > possibly compensate somewhat but the with the additional restriction on
> > category.
> > 
> > say for example, i have a versioning tool that provides a set of
> > multicategory actions based on whether or not the content is
> > versionable. if i want to dynamically provide actions based on context,
> > with the new mechanism, i would need to register relevant actions with
> > each action category. with the old model a tool could do a simple check
> > in restricted code and disable the whole action set if its not
> > versionable.  
> 
> Do you know of many tools that work like that? 

a few, in the collective sourceforge project, the cmfmetadata tool
http://cvs.sourceforge.net/viewcvs.py/collective/CMFMetadata/MetadataTool.py?rev=1.9&view=auto

and the versioning example i outlined previously is another good one, i
think.

but really its a bit moot here, as its just an optimization.

> Do they have to share 
> many categories with other Action providers?
> 

they share categories typically, but they typically don't provide
multicategory action sets. 

ie. in plone there are ui semantics attached to different categories.
with different providers working to provide the action set that
compromises a category. doing this with the new model would need to
reimplementing the provider semantic on category level which i think
would be a step backwards in terms of complexity management. 

> > or say i have content with dynamic actions based on object state (a
> > workspace with/ actions based on installed plugins or direct action
> > manipulation on the content for example), with the new model i'd have to
> > do it based on tales expressions that would need to be evaluated in the
> > context of all content, as opposed to the relevant instance. 
> 
> That's a similar problem as with type Actions and workflow Actions. I 
> believe that these tools should still control which Actions are 
> available, but not the properties of these Actions.
> 

this is different though in that the object is providing actions as
opposed to tools. ie. the functionality of consulting the object for
actions is something i'd like to see retained.

also at least for things like workflow separating out actions is a bit
of a mismatch as the workflow definition is defining the actions, ie not
just availability configuration but existence. static definitions aren't
really appropriate here imho, as its dependent on the configuration of
the provider.

> A simple implementation of that would be using condition expressions 
> that call a method of the tool. But I'm optimistic there is a faster 
> solution that works with simpler expressions or without. I don't think 
> this has to be resolved before we convert normal Actions.
> 

agreed. the first two implementation steps (actions from simpleitem w/
props, and orderedfolder support) sound good.

cheers,

-kapil



More information about the Zope-CMF mailing list