[Zope-CMF] Re: folder_contents was Re: [dev] two small changes

[Tres Seaver]

Tonico Strasser wrote:
> yuppie wrote:
> 
>> Tonico Strasser wrote:
>>
>>> I find the global setting in the actions tool is not good. I think a 
>>> normal object shouldn't have a folder_contents action by default. 
>>> It's confusing and if I would repeat this logic for custom types, 
>>> things would get complicated. But thats just my view.
>>
>> I would agree that folderContents doesn't really belong into the 
>> category 'object'. Looking at the history of the actions tool before 
>> CMF 1.3 there was only 'folder/folderContents', not 
>> 'object/folderContents'. I think that was better. But I would not 
>> remove 'folderContents' completely because there should be a link to 
>> the container of the object.
> 
> I understand this from a historical point of view. The confusing part 
> for me is, when I call 'listFilteredActionsFor(here)', I would not 
> expect actions for container. If I wanted actions for the container, I 
> would call 'listFilteredActionsFor(here.aq_parent)' or similar. And, "up 
> to parent" is a navigational element not an action in my mind.

The distinction between "navigation" and "actions" is not clear cut in 
mine.  You have put your finger on the rationale for putting 
'folder_contents' in the 'object' category for containers, but in the 
'folder' category for non-containers:  the UI can then do something 
different with the two categories, if desired.  The actions tool has the 
two actions largely to allow the action to show up only once for folders.

>>> Removing the visible flag (or deleting the action) is not an option, 
>>> because I want to be as compatible as possible with plain CMF.

The point of having the actions defined in tools, rather than code, is 
precisely to allow you to express local polciy without breaking the CMF; 
  nothing in the framework should *care* if the 'folder' category 
version disappears!

>> I can't follow you here: I thought the problem was related to the fact 
>> you *did* delete the action.
> 
> Sorry for beeing unclear. I removed it for testing purposes. It's there 
> again. I solved it in folder_contents_control.
> 
>>>  > getActionInfo is an ActionProvider method, not an ActionsTool method.
>>>  > atool.getActionInfo() does only return actions defined in 
>>> portal_actions.
>>>
>>> Ah, do you mean in portal_actions? Hmm.
>>
>> Yes. In portal_actions.
> 
> Things quickly get complicated for me if they are global. So I try to 
> avoid it for this case.
> 
>>> Looks good. What about adding object/folderContents to Folder and 
>>> Skinned Folder?
>>
>> Well. If you ask me the 'folder/edit' Action would be the right Action 
>> to manipulate folder contents. 'folder_edit_form' should be called by 
>> 'folder/metadata' or become part of 'folder_contents' (or 
>> 'folder_contents' part of 'folder_edit_form').
>>
>> But right now I'm not the person who'll do that.

Local policy again. :)

One feature I am contemplating for CMF 1.5 is a 'portal_configuration' 
tool which allows you to export all the tool settings to a directory / 
tarball, for migration / version control, etc.  We actually have the 
beast built already;   it just needs to be disentangled from the 
client-specific product it currently inhabits.  At any rate, being able 
to export your "local policy" choices to a reproducible description 
should resolve most issues with the use of local policy knobs.

> I see. Anyway, CMF is a great piece of software. Sometimes I feel sad 
> because it's generally not accredited enough.

Thanks!

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com