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

[Sidnei da Silva]

On Thu, Feb 26, 2004 at 10:51:45AM +0100, yuppie wrote:
| >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>

What's your point with this? I don't see why writing 15 lines of
python my be better than changing a .ini-like file.

| >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.

The point is that we want to *avoid* the script.

| >  redirect_to_action:tales_expression
| 
| Can be done with a few lines of code (see 'Cancel' in the script above). 

See previous answer.

| Does redirect_to_action: work with global actions like 'user/plone_setup'?

It should *wink*.

| >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.

Ok, that may have been a bad example. I have only used it once, as
Archetypes has only one form. 

| >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?

Good question. Alan? Limi?
 
-- 
Sidnei da Silva <sidnei at awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

Variables don't; constants aren't.