Warning

This document hasn't been checked for compatibility with current versions of Plone. Use at your own risk.

Customizing content object form behavior

by Mikko Ohtamaa last modified Dec 06, 2009 09:27 PM
Adding new form buttons or different action after successful content object save are usual use cases. This how to will give pointers how to customize the behavior of Archetypes content types.

Purpose

You have created a new content type and you want to tune up it a bit

  • Go to some other page instead of view on a successful save
  • Customize how view and edit widgets are rendered

 

Prerequisities

You have created Archetypes content type as a Python product. You are aware how Plone skin layers function and able to add a new skin layer where your customized templates go.

Step by step

Plone uses an underlying subsystem called CMFFormController to manage HTML form submissions. Due to its heritage, this subsystem is quite complex and has several different types of parts

  • .pt page template files to render normal HTML pages
  • .cpt page template files to render HTML forms with traversing data
  • .py Python Script files to add view logic
  • .cpy Python Script files to add custom traversing logic
  • .metadata text files in INI format to describe traversing and validation
  • .xml GenericSetup files to register various parts during the product installation
With the exception of GenericSetup XML, all these files live inside skin layer folders.

.py and .cpy files are not Python modules. They are Python script snippets which are executed inside a security manager i.e. the user executing the script cannot break out of the sandbox even accidentally.

 

Since the controlling is not done in pure Python, but using several custom file formats managing and debugging CMFFormController can be challenging.

Customizing view page

  • Copy-paste base_view.pt from

 

 

Customizing edit page

 

 

 

Customizing traversing

A very complex traversing chain is used during the object save. Here I cover all the steps. Versioning steps are optional and available only for objects supporting versioning.

  1. mycustomcontent_edit.cpt - Render HTML form, based on atct_edit.cpt
  2. mycustomcontent_edit.metadata - Decide traversing after the form has been submitted
    1. validate_atct - Execute form validators
    2. success -> 3 (if versioning is used)
    3. success -> 4
    4. failure -> 1
    5. add_reference -> last_referer - Custom hook for reference edit field
  3. (update_version_before_edit) - optionally set versioning save point
    1. success -> 4
  4. mycustomcontent_content_edit.cpy - Call content_edit_impl.py
  5. mycustomcontent_content_edit.metadata
    1. validate_base - Validate fields after save
    2. success -> 6
  6. mycustomcontent_validate_integrity - Check that references are ok after save
    1. success -> 7
    2. success -> update_version_on_edit (if versioning is used)
    3. failure -> 1
  7. mycustomcontent_view

 

Further information

Some existing examples


Contribute

Something wrong or out of date? Anybody can edit or create a new article in the knowledge base. Simply create an account on this site, log in, and click the Edit button to contribute.