[Zope-CMF] CMFActionIcons vs. new-style actions

Jens Vagelpohl jens at dataflake.org
Thu Sep 18 05:40:17 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 18, 2008, at 11:13 , yuppie wrote:

>>  - extend the "old-style" actions, those you see e.g. on a type
>> information "Actions" tab in the ZMI, to also have a field for an  
>> icon
>> URL expression
>
> That might have been the most pragmatic solution, but in the long  
> run we
> should not maintain two different Action machineries.

You are totally right of course. Doing that wholesale switchover and  
replacement simply wasn't something I could get done for 2.2.0. I  
thought about that many times as I went through all the places that do  
define actions. Actually there's not two, but three different  
machineries in play when you consider the workflow actions, and those  
workflow actions are the strangest because they don't use TAL  
expressions but string replacement to expand the expression-style  
fields.


> I personally prefer to move all type info Actions to the actions  
> tool. I
> can't see a need to specify separate 'view', 'edit' or 'metadata'
> Actions for each content type. That just makes it necessary to  
> maintain
> a lot of redundant configuration data. In how many places did you have
> to set "string:${portal_url}/edit_icon.png"?
>
> Some Actions like 'download' should only be available for specific
> portal types. That makes things a bit more complicated, but can be  
> solved.
>
> If people really want to maintain separate Actions for each type, we
> should consider to make type infos containers for new-style Actions.

Yes, there's redundant information in many places. Collecting all  
actions in the actions tool itself would be the cleanest way, but a  
more manageable first step would be making type information objects  
into action containers as you suggest. The same could be applied to  
DCWorkflow Worklist and Transition definitions.

I have added a Launchpad "blueprint":

https://blueprints.launchpad.net/zope-cmf/+spec/unify-actions

Collecting our projects as blueprints has the advantage that there's a  
single place to track all of them, with concise information about the  
task and who's doing/reviewing it:

https://blueprints.launchpad.net/zope-cmf

jens



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjSIgEACgkQRAx5nvEhZLLkLQCdEzmo0d0va5kM6XnsOfX/bjAx
ngQAoIgXB7Evu//jpFDtU7kCGf1czYNE
=TRp9
-----END PGP SIGNATURE-----


More information about the Zope-CMF mailing list