[Zope-CMF] Re: [dev] CMF 1.5 roadmap?

yuppie y.2004_ at wcm-solutions.de
Thu Feb 26 04:51:45 EST 2004


Hi Sidnei!


Thanks for your detailed reply!

Sidnei da Silva wrote:
> There's no such thing as FormActions. You have an 'action' which is
> performed when a set of conditions are met, but this has nothing to do
> with CMF's Actions (except the fact that you can redirect to an action
> by name).

Sorry. But these 'actions' are stored in *FormAction* objects. The fact 
the documentation just talks about 'actions' isn't very helpful to 
distinguish them from CMF's Actions.

> eg:
> 
> [default]
> title=Advanced Metadata Configuration
> 
> [security]
> View=0:Authenticated
> 
> [validators]
> validators..Upload=validate_id,validate_metadata_upload_xml
> validators..EditMappings=validate_id,validate_metadata_edit_mappings
> validators..Cancel=
> 
> [actions]
> action.success..Upload=traverse_to:string:metadata_upload_xml
> action.success..EditMappings=traverse_to:string:metadata_edit_mappings
> action.success..Cancel=traverse_to:string:plone_control_panel
> action.failure=traverse_to:string:prefs_metadata_form

To make it easier to compare things I tried to rewrite this as a script. 
These are the modifications I made:

- replaced the Upload / EditMappings 'traverse_to:' by calls assuming 
they traverse back to prefs_metadata_form anyway

- replaced the Cancel 'traverse_to:' by a redirect to keep the browser 
URL up to date and used the 'user/plone_setup' Action to keep this 
redirect in sync with Action changes

- replaced the state object by a simple dict (this has to be done in all 
related scripts / templates)

<script>

## Script (Python) "prefs_metadata_control"
##parameters=Upload=None, EditMappings=None, Cancel=None, **control
##
from Products.CMFCore.utils import getToolByName
mtool = getToolByName(context, 'portal_membership')

if Upload:
     control = context.validate_id(control)
     control = context.validate_metadata_upload_xml(control)
     if control['status'] == 'success':
         control = context.metadata_upload_xml(control)

elif EditMappings:
     control = context.validate_id(control)
     control = context.validate_metadata_edit_mappings(control)
     if control['status'] == 'success':
         control = context.metadata_edit_mappings(control)

elif Cancel:
     target = mtool.getActionInfo('user/plone_setup')['url']
     context.REQUEST.RESPONSE.redirect(target)
     return

return control

</script>

> There are 4 kinds of actions that can be performed: 
> 
>   traverse_to:tales_expression

If we call the methods from a script we don't need this.

>   traverse_to_action:tales_expression

Can't see a usecase for that.

>   redirect_to:tales_expression

Defining an Action and using 'redirect_to_action' would do the same 
without adding another way to define redirect targets.

>   redirect_to_action:tales_expression

Can be done with a few lines of code (see 'Cancel' in the script above). 
Does redirect_to_action: work with global actions like 'user/plone_setup'?

> The first part of the action definition will be matched against the
> context of the submitted form. 
> 
>   - 'action' is a fixed string for now
>   - 'success'/'failure' is the state, which you set inside the script
>   - 'portal_type', which is the portal type of the context object
>   - 'Upload'/'Cancel' are the names of the buttons clicked
> 
> In this example, if the 'state' after running the validators is
> 'success' and you clicked the button named 'Upload', FormController
> will traverse to the 'metadata_upload_xml' object and call it.
> 
> Say, you define a *base* set of controller actions, like this:
> 
> [actions]
> action.success..Save=traverse_to_action:string:edit
> action.success..SaveAndView=traverse_to_action:string:view
> action.failure=traverse_to_action:string:edit

Can't see how this should work. Save and SaveAndView need to traverse to 
a script like document_edit that does the job. And this script needs to 
traverse back to edit or redirect to view, depending on the button and 
the status.

> This could be used for *all* of the CMF default portal types, and if
> you want to change behavior, you only need to change this, and doesn't
> have to touch a single template or python script.

Ok. And why doesn't plone use one definition for all portal types?


Cheers,
	Yuppie




More information about the Zope-CMF mailing list