[Zope-CMF] info about Zope action objects!

[alan runyan]

Phil,

> Or, since the endeavor is similar to archeology, "explore Indiana Jones"!

8)

> Perhaps, Alan, you could read the results of my excavations and tell me at
> least if I'm on the right track as well as answer the questions I'm
running
> into.
>
> Taking the overview of the portal_actions tool at face value -- that it
> "assembles the "actions" which are germane to the current user" -- it
seems
> to me that to understand portal_actions we need to understand the sources
> from which it "assembles" them. Referring again to the overview, the
sources
> of actions are: the workflow tool, the membership tool, and the types
tool.
> ("Global" actions can be created only in the portal_actions tool, as well,
> but I'll leave those aside for a minute). Actually, I see a number of
other
> tools listed under the "Action providers" tab in the portal_actions tool.
> Are these other sources of actions that portal_actions should be
> registering?

all actions have their condition expressions applied. if they succeed they
are included in the listFilteredActionsFor()
These 'other sources' are registered withe the actions tool.  the actions
tool will ask them for their actions and then
do the filtereing (apply the condition expression) to the context.

> Conceptually, then, it seems that portal_actions is meant to be a
> clearinghouse for determining which actions pertain to a given object, or
> set of objects, that you are working with. Leaving aside for now global
> actions, it is just a unified view into the other "action providers."

yes

> But I'm having trouble seeing how this works in real life. In the types
> tool, if I click the "Event" type, and then go the Actions tab, I find the
> following three actioins defined: event_view, event_edit_form, and
> metadata_edit_form. I would have thought, given all that we've said, that
> these three actions would show up in the list of actions I find in the
> portal_actions tool. But they do not! I checked the "Action Providers" tab
> and initially found that the portal_types tool was not among the listed
> providers, so I added it. BUt the event actions still do not show up in
the
> portal_actions tool. Can you elaborate on what I might be missing here?

ah! but then there are 'object' actions which are gotten from the
portal_types.
in Plone for instance we use 'object/folder' actions (dictated by category)
to
display in the 'contentTabs' (green tabs) portion of a page.  each type
inside
portal_type itself has actions.  these actions usually represent 'views'..

> It also seems to me that there is a much deeper truth about the way Zope
> works -- so deep, I suspect, that it may be hard to articulate. Basically
> this whole thing is data driven. Which buttons and forms and links show up
> in any given place appears to be largely governed by types and actions.
This
> is deep stuff. I have faith that this is all leading me to enlightenment,
to
> Zope Zen, but I definitely feel like I'm going through the dark night of
the
> Zopista, here.

* portal_actions arent necessary 'zopefully zenful' entities, they really
are CMF constructs
* how they show up is responsibility of the PageTemplate (view) that is
rendering them.
* take a look at ActionProviderBase (a mix-in for tools that want to be
action_providers)
* portal_types is a ActionProvider but also contains a registry of Types.
these Types (content object definitions)
   also have Actions on them.  These actions are really not about options
for a user in a given context but
   what 'views' are available to this content object.
* I highly suggest reading Portal.py and CustomizationPolicy.py in CMFPlone
(from CVS or from alpha2) as
   this is the only thing I know of that really does acrobats with the CMF
machinery.  Maybe you can make
   some more understanding by looking at it, installing Plone, viewing it
and Indiana Jones'ing it.

> By the way, in case anyone is interested, the best information I could
find
> on the types tool are: the relevant section of
> http://cmf.zope.org/Members/beehive/ZWACKChap5.html, which provides a
> conceptual understanding, and
> http://cmf.zope.org/Members/tseaver/how_tos/taming_types_tool/view, which
> gets into the APIs.

I guess so.  I just read the source.  Its really not that bad.  the
SkinsContainer/SkinsTool -- now that is some gnarly stuff.

I would like to take the opportunity to plead with everyone to purchase a
Learning Python/Essential Reference and have your python
interpreters ready.  ZOPE/CMF is Python and there is no way around
customizing and understanding it in a meaningful way w/o
understsanding Python.  The upside is Python is the simplest language around
that does the most amazing things.
Create stuff on the filesystem -- its where Python class definitions are
most comfortable.  I use to love ZClasses (and I still do)
but they can cause lots of gnashing of teeth and losing of hair w/o having
appropriate understanding of context (Acquisition and ZODB)
and the elegant Python language.

cheers,
~runyaga

p.s. i hope this answered some questions.. I also find it helpful to do
things like this in a footer.pt -
<span tal:replace="here/portal_actions/listFilteredActionsFor" /> which
displays the sequence of ActionItems
(they look and act like dictionaries, but they are full fledged objects)