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

[Tres Seaver]

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

yuppie wrote:
> Hi Martin!
> 
> 
> Martin Aspeli wrote:
>> yuppie-4 wrote:
>>> Wichert Akkerman wrote:
>>>> Previously yuppie wrote:
>>>>> 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"?
>>>> Per-type edit and view actions are a very important customization point.
>>>> We should not make it harder for people to do that. Per-type actions are
>>>> very common in Plone, I'ld hate to loose them.
>>> Can you point me to some examples? Looking at the default CMFPlone 
>>> profile I couldn't find any. Repeated definitions for 'view', 'edit', 
>>> 'download', 'external_edit', 'history' or 'references' Actions look 
>>> quite redundant to me.
>>>
>> I would be extremely uncomfortable with losing the ability to do:
>>
>>  - Per-type definition of *which* actions are shown in a given category
> 
> Sure.
> 
>>  - Per-type definition of *what* those actions go to
> 
> As you mention below, method aliases can be used for that.
> 
>> I think there's a case for saying that there's always a 'view' and an 'edit'
>> action that go to /view and /edit and you use method aliases to point them
>> at different templates. However, we need the ability to change permissions,
>> TALES conditions, labels and so on per-type.
> 
> How often do you need that ability? Can we make that a bit harder if we 
> can get other benefits in return?
> 
>> Reducing repetition would be good, of course. We certainly have conventions
>> that apply to most (but not all) types. If there was a way to make per-type
>> actions optional as overrides/additional items (including the ability to
>> turn off an action inherited from globals) that may be good.
> 
> The solution I have in mind is maintaining a simple set of Action IDs 
> inside a type info property. All Actions are stored in one place, but 
> availability is looked up in the type infos.
> 
> If you need a different edit action, you create a new one with a new ID. 
> And add its ID to the type infos that should use it.

We could just use the aliases for that:  essentially, they would be the
list of "valid" object actions for the object.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI0m5Y+gerLs4ltQ4RAu2RAKDCKAuSHdnkIC+5qjptL5slo0byrgCfVkSw
omCTYtxKVO0MHF3b3RMdVWU=
=EvH7
-----END PGP SIGNATURE-----