What's New in Plone 2.0 for Developers

Contents

This document is an overview of the changes between Plone 1.0 and Plone 2.0. It's a technical document and is intended for developers who are at least moderatly famliar with Plone. Plone 2.0 has changed significantly from Plone 1.0, which, while being a very useable content management system, was developed in a relatively short amount of time. Portions of the code were not as elegant as they could have been. Much of the changes in Plone 2.0 have dealt with reworking and refactoring the code to deal with shortcomings that developers have experienced in the first release. The great number of changes from 1.0 to 2.0 means that it would be exceedingly difficult to have a script migrate from a Plone 1.0 installation to a Plone 2.0 installation. This document will provide an overview of what is new to Plone 2.0, for directions on just doing a migration from a Plone 1.0 to Plone 2.0 without delving too deeply into the changes between the two releases see here (xxx there should be a seperate short as possible How To Migrate document - this has not been written).

Some of the significantly changed or new components within Plone 2.0 include support for groups, a new method of controlling and validating forms, a major clean-up of the Page Templates to make it easier to modify and customize Plone, a move to a tableless HTML layout along with a renaming of the elements within the HTML, support for large and ordered folders, the introduction of the Plone Control Panel, and the addition of several new tools.

New Zope Products Included

The number of Products that Plone 2.0 ships with has increased significantly from Plone 1.0. One of the goals of Plone is to take the best-of-breed products from the Zope world, and integrate them into a collection of products that all play well with each other within Plone. Plone 1.0 shipped with only two products: DCWorkflow and Formulator. Plone 2.0 ships with seven products: BTreeFolder2, CMFActionIcons, CMFFormController, CMFQuickInstallerTool, External Editor, Formulator and GroupUserFolder. A brief description of each of these products follows (xxx version numbers for these products will be updated when Plone 2.0 final ships):

BTreeFolder2 0.5.0+

Plone has a new content type called the Large Plone Folder. This uses the BTreeFolder2 Product to store a folder's objects in a BTree. This is essential if you plan on having a Folder with a lot of objects in it. By default, the Members folder in Plone 2.0 is a Large Plone Folder. Folders created by Plone users are still ordinary Plone Folder Type. You can allow users to create large plone folders by checking the Implicitly Addable checkbox in the ZMI in the Large Plone Folder type in the portal_types tool.

CMFActionIcons

This is a simple product that maps actions to icons, for ease of building icon-centirc toolbars. It provides icons for groups of actions such as object actions: view, preivew, edit and metadata; folder actions: folderContents, localroles, syndication; workflow actions: submit, history, retract, approve, reject, expire, yank; and global actions: undo, configPortal, worklist.

CMFFormController 1.0

CMFFormController replaces the portal_form form validation and navigation mechanism from Plone 1.0. This product is a great improvement over portal_form and has changed significantly and thus warrants it's own section below in this document.

CMFQuickInstallerTool 1.4

This product makes it easy to install and uninstall additional CMF Products. The CMFQuickInstallerTool is a seperate product from CMFQuickInstaller, the difference being that it is installed as a portal service called portal_quickinstaller, and that it tracks what a product installs, allowing for uninstallation. This product is used in the Plone Control Panel in the Add/Remove Products screen.

External Editor 0.6

The Zope External Editor is a way of integrating Zope more seamlessly with client-side tools. This is an optional product for Plone 2.0, but is recommended if your users want to edit objects in Plone with better tools than the textarea field.

Formulator 1.4.0

Formulator is a tool to help with the creation and validation of web forms. Form fields are stored as objects in Zope, in a special Form folder.

GroupUserFolder 2.0beta1

Allows support for groups in Zope and it works with existing acl_users products. This is a huge gain for Plone and Zope and is discussed in detail below.

Plone Tools

Plone 2.0 has added a number of new tools. In addition, all of the tools from the CMFCore are now subclassed by Plone. This means that future feature additions or bug fixes made by Plone to the core tools can be done without having to monkey patch the CMF. Note that you will sometimes see the tools also referred to as services. Currently these terms are interchangeable, with tools being a Zope 2 terminology and services being a Zope 3 terminology.

A brief overview of the tools in Plone 2.0 follows:

Caching Policy Manager

Name: caching_policy_manager

Origin: CMF 1.4

What: Allows you to manage a set of caching policies for your Plone site.

Plone Utility Tool

Name: plone_utils

Origin: Plone 1.0

What: The place for things which do not fit anywhere else.

Plone Action Icons Tool

Name: portal_actionicons

Origin: Plone 2.0

What: Used to interface with the CMFActionIcons product to provide icons for actions.

Plone Actions Tool

Name: portal_actions

Origin: CMF 1.0

What: Custom tabs and buttons.

Plone Calendar Tool

Name: portal_calendar

Origin: CMF 1.0

What: Controls how events are shown.

Plone Catalog Tool

Name: portal_catalog

Origin: CMF 1.0

What: An interface to the mighty ZCatalog. Contains an index of all content in Plone.

Plone Control Panel

Name: portal_controlpanel

Origin: Plone 2.0

What: Control Panel actions. There are three groups of actions in Plone 2.0, Plone Configuration which appears on the plone setup page, Add-on Product Configuration for third party configlets, and Plone Member Preferences, which appears on the my preferences page. Note that this tool was named portal_control_panel_actions and used a different meta type until Plone 2.0RC3. If you are migrating from an earlier release candidate of Plone 2.0, you will need to: delete all ActionIcons with category "controlpanel", delete the portal_control_panel_actions tool, Add Plone Tool - Plone Control Panel Tool, and then invoke the following URL: http://mysite/portal_controlpanel/registerDefaultConfiglets

Plone Discussion Tool

Name: portal_discussion

Origin: CMF 1.0

What: Controls how discussions are stored by default on content.

Plone Factory Tool

Name: portal_factory

Origin: Plone 2.0

What: This tool is used to enable users to edit new objects without having to first create new objects in the ZODB. It's use is optional in Plone 2.0, and it must be enabled first.

Portal Form

Name: portal_form

Origin: Plone 1.0

What: Deprecated in Plone 2.0, this tool used to handle form control and validation.

Portal Form Controller

Name: portal_form_controller

Origin: Plone 2.0

What: The replacement tool for Portal Form. The use of this tool is detailed in the "New form control and validation framework" section of this document.

Portal Group Data Tool

Name: portal_groupdata

Origin: Plone 2.0

What: Stores properties on group data. Think Plone Member Data, only for groups.

Portal Groups Tool

Name: portal_groups

Origin: Plone 2.0

What: Group management functions. Controls the automatic creation of Workspaces, the name of the Workspaces folder, and the Type of Folder that is used to hold Workspaces. This tool is also an action provider.

Portal Interface Tool

Name: portal_interface

Origin: Plone 2.0

What: This tool exposes the interface package for TTW applications, by accepting a dotted name of an interface and exporting the IInterface API.

Plone Memberdata Tool

Name: portal_memberdata

Origin: CMF 1.0

What: Stores properties on users.

Plone Membership Tool

Name: portal_membership

Origin: CMF 1.0

What: User management functions. Handles the authentication of users. As of the CMF 1.4 it is now possible to change the name of the Members folder using this tool.

Plone Metadata Tool

Name: portal_metadata

Origin: CMF 1.4

What: This tool embodies site-wide policies concerning required metadata for each content type, as well as default values and controlled vocabularies.

Plone Migration Tool

Name: portal_migration

Origin: Plone 1.0

What: Handles migrations between versions of Plone.

Plone Navigation Tool

Name: portal_navigation

Origin: Plone 1.0

What: Deprecated tool, used only for backwards compatability with Plone 1.0.

Plone Properties Tool

Name: portal_properties

What: Used for accessing "portal-wide" properties.

Plone QuickInstaller Tool

Name: portal_quickinstaller

Origin: Plone 2.0

What: An interface to the CMFQuickInstallerTool product.

Plone Registration Tool

Name: portal_registration

Origin: CMF 1.0

What: Sets policies for adding new members. It sets the defaults for allowable member IDs and passwords.

Plone Skins Tool

Name: portal_skins

Origin: CMF 1.0

What: Configurable, layered name lookup to "skin methods".

Plone Syndication Tool

Name: portal_syndication

Origin: CMF 1.0

What: Generates RSS for folders.

Plone Types Tool

Name: portal_types

Origin: CMF 1.0

What: Controls the available content types for Plone.

Plone Undo Tool

Name: portal_undo

Origin: CMF 1.0

What: Allows transactions in the ZODB to be undone.

Plone URL Tool

Name: portal_url

Origin: CMF 1.0

What: Provides a mechanism for finding the root Plone object, and for computing paths to objects relative to that Plone.

Plone Workflow Tool

Name: portal_workflow

Origin: CMF 1.0

What: Associates objects of a given content type with a workflow. Workflows are "state machines", each representing the life cycle of a given family of content types, and specifiying the "workflow actions" which are possible in any phase of the life cycle. This tool is also an action provider.

Plone Control Panel

XXX Add some notes here on Plone Control Panel

Groups and Group Workspaces

Basic support for groups is now provided in Plone 2.0 using the GroupUserFolder (GRUF) Product. At it's core, GRUF allows you to have groups of users. Groups can have roles associated with them, just like users can, and if a user belong to a specific group, then it gains all the roles associated with that group.

Why add support for groups when you can just assign a set of roles to a user directly? In short, groups can greatly simplify managing the roles that a user is granted. For instance, consider a company intranet where you have a team of developers working on a software product. You can assign each developer to a Developer group and create a folder an give the Developer group write access to that folder. Later on, you create another folder that you also give write access priveleges to anyone in the Developer group. Then you hire a new developer. Instead of having to remember that you had created two folders that developers need a local role assigned to them granting them write-access, you simply make the developers user account part of your Developer group.

Groups and also users can now be managed Through The Plone (TTP) by visiting Users and Groups Administration under plone setup. The Users and Groups Administration control panel allows you to add and remove users and groups, as well as assign users to groups.

When you create new groups using Plone 2.0, Plone will automatically create a folder named GroupWorkspaces for you, and then create a folder within that GroupWorkspaces folder with the name of your new group. This group has the local role of Owner assigned to it - you can view this setting by visiting the sharing tab for that particular group workspace folder. Anyone part of that group can then create and edit all content contained within that folder.

GRUF has been designed to work without Plone, and can be used with Zope alone. GRUF has been integrated into a Plone 2.0 in a sensible manner. For example, calling context.portal_membership.listMembers() will only list users and not groups, even though group information is stored in the acl_users folder.

GRUF uses an ordinary acl_users folder to store Groups, and another seperate acl_users folder to store Users. Therefore most types of User Folders can be used to store User and Group information. You can even mix and match your User Folders, for example you could use the SimpleUserFolder Product to store your Users and LDAPUserFolder to store information on your Groups.

More information on GRUF can be found on the GRUF home page

New form control and validation framework

Plone 2.0 ships with version 1.0 of the CMFFormController Product. The old method of controlling the navigation of forms using portal_form is now deprecated in Plone 2.0. The old tool is still there, but developers are discouraged from using it, as it will be removed in a future revision of Plone.

In short, CMFFormController fixes some short comings of the portal_form tool. The old tool allowed a user to bypass validation if they knew the arguements being passed to the action. including the security concerns of being able to bypass validation in the old method, easier development by allowing the actions and validations of forms to be set on the filesystem, site administrators can override the actions and validations set on the filesystem making it easier for them to upgrade without disturbing their modifications. And lastly, but not least, it is no longer necessary to have the phrase portal_form in the URL.

Developers are encouraged to read the complete documentation on how to use the CMFFormController

If you have a number of older forms, validations and actions that you want to migrate, a shorter document is available on How to migrate to CMFFormController

Temporary Objects

New to Plone 2.0 is the Plone Factory Tool, named portal_factory. This tool allows users to initiate the creation of objects in such a way that if they do not complete an edit form, no object is created in the ZODB. The tool works by creating a temporary object in the request, when the request terminates, the object will be garbage collected.

You must use the Plone Factory Tool to specify which content types should be created using portal_factory. In Plone 2.0, none of content types use portal_factory by default. You must visit the Factory Types tab in the ZMI of the portal_factory tool to enable temporary object creation for the types that you wish. You should be able to safely enable all of the stock content types that ship with Plone 2.0 to use portal_factory.

Making Types portal_factory aware

portal_factory creates a temporary object in the REQUEST. When the request ends, the object is garbage collected. If you want to modify an object, you must first instantiate it in the ZODB. portal_factory provides a utility method that tests an object to see if it is temporary and, if so, instantiates it in the proper place in the ZODB. You can invoke this method via:

    portal_factory.doCreate(object, id)

Typically this method will be invoked in the object's edit script via code that looks like the following:

    Non-portal_factory-aware code:

    # parameters=id, param1, param2
    context.edit(param1, param2)
    context.plone_utils.contentEdit(context, id=id)
    ...

    portal_factory-aware code:

    # parameters=id, param1, param2
    new_context = portal_factory.doCreate(context, id)
    new_context.edit(param1, param2)
    new_context.plone_utils.contentEdit(new_context, id=id)
    ...

Working with temporary objects

You can manipulate temporary objects by using a URL of the form:

    http://myportal/myfolder/portal_factory/TYPE_NAME/OBJECT_ID

For example, the following URL points to a temporary Document with id foo:

    http://myportal/myfolder/portal_factory/Document/foo

Template and HTML improvements

The Page Templates used in Plone 2.0 have been cleaned up from 1.0. This makes customizing your Plone installation much easier in the 2.0 series.

The HTML that Plone uses is now 100% table free. The advantage of moving away from using HTML tables to do layout is that Plone 2.0 can now be customized to a much greater degree by only editing your ploneCustom.css file.

UI NameAgeddon

The names of the HTML elements have been renamed. See UINameAGeddon and UICodingStandards

New Forms style

The HTML and style for forms in Plone 2.0 has changed quite a bit. The reasons for this are for simplicity, easier to do multi-column forms, visible tooltips for better usability, and it's easier to change the behaviour with CSS. The simplest flavour of a new form looks like this:

      <form action="" >
        <fieldset>
          <legend>Document Details</legend>
          <div class="field">
            <label for="id">Short Name</label>
            <div class="formHelp">Help Text</div>
            <input name="id" id="id" type="text" />
          </div>
          <div class="formControls">
            <input type="formControls" class="context" />
          </div>
        </fieldset>
      </form>

Limi has written How To Convert from the Plone 1.0 Forms Format

Directory structure changes

The hierarchy of the skins directory has been flattened in Plone 2.0. This is to mimic the behaviour of the way that portal_skins in the CMF is meant to flatten the namespace. There should be no nested folders in the skins directory. The following is a list of directories in skins directory, and their contents:

• cmf_legacy : Python Scripts from CMFDefault, so that it is no longer necessary to mix skins from CMFDefault in your Plone skins.
• plone_ecmascript : ECMAScript files, known as Javascript in Mozilla or Jscript in MSIE.
• plone_images : Icons, badges and the Plone logo.
• plone_scripts : A miscellaneous collection of Python scripts.
• plone_wysiwyg : The default wysiwyg editor box.
• plone_3rdParty : deprecated.
• plone_form_scripts : Scripts that validate or edit content objects.
• plone_portlets : Previously known as plone_templates/plone_slots, the boxes on the sidebars are now refered to as portlets.
• plone_styles : Cascading Stylesheet files.
• plone_content : Views for content objects.
• plone_forms : Forms in Plone that aren't for editing content objects.
• plone_prefs : Files used by the Plone Control Panel.
• plone_templates : Templates that control the structure of Plone.

The plone_3rdParty directory in the skins has been removed. Files that lived in there are now a part of the CMFCollective. This is too keep Plone from getting fat. Plone is intended to be a simple, core system. Additional products such as wikis, collectors, photo albums, etc. are maintained seperatly from Plone. The Add/Remove Products section in the Plone Control Panel makes it easier for users to install and uninstall additional 3rd party add-ons to Plone.

CMF 1.4

Plone 2.0 now requires CMF 1.4. If you are still running CMF 1.3, it would be helpful to review the list of changes between the :1.3 and the 1.4 release

A few of the more signifcant changes and features of the CMF 1.4 are the ability to store metadata properties for filesystem objects in a .metadata file. The .metadata file can contain proxy roles and security assertions. It is also possible to rename the Members folder, and use the MembershipTool to retrieve the Members folder using the getMembersFolder() method. When managing the Layers for skins in portal_skins, the Layers are now newline seperated and edited via a textarea field instead of a text field.

Unit Testing Framework

Plone 2.0 now has a growing set of unit tests. If you have changed the code in Plone itself you can run the unit tests to see if you have broken anything. To run unit tests:

• Download http://zope.org/Members/shh/ZopeTestCase and install it in your lib/python/Testing directory
• Set the following two environment variables:

  export INSTANCE_HOME=/var/zope/test # Where your Zope lives (var dir etc) # On Windows: \Program Files\Plone\Data export SOFTWARE_HOME=/var/zope/test/lib/python # Where the core Zope Products are # On Windows: \Program Files\Plone\Zope\lib\python

• Run python CMFPlone/tests/runalltests.py (On Windows: \Programs\Plone\Python\python.exe \Programs\Plone\Data\Products\CMFPlone\tests\runalltests.py)