yuppie-4 wrote:
> Hi Wichert!
> 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
 - Per-type definition of *what* those actions go to

Actions in the FTI usually result in tabs in Plone. Custom types often have
additional tabs, or make /edit, say, point to another view.

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.

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.

View this message in context: 
Sent from the Zope - CMF list2 mailing list archive at Nabble.com.

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to