#190: Add page composition machinery

Contents

1. Motivation
2. Assumptions
3. Proposal
4. Implementation
5. Deliverables
6. Risks
7. Progress log
8. Participants

Proposed by

Malthe Borch

Proposal type

User interface, Architecture

Repository branch

plone.composition

State

in-progress

Motivation

To meet the challenge of page composition and succeed where others have not. We need to nail the content layout story and take it to the next level.

Assumptions

The work can be divided into the following moving parts:

• A default data model and rendering engine for compositions
• Import/Export of layout templates via a GenericSetup profile step (layouts should be definable in XML).
• A user interface for managing and creating layouts (be it a template layout or a custom layout)
• Default views for Plone's standard content-types

Still being debated is whether the composition machinery should make use of simple content items like text fields and images that would not be first class content objects. There are certainly scenarios where you want to add content to your composition that does not make sense on its own. Such content items could be traversed to using a registered namespace, i.e.

/some_folder/++composition++8ab636009a071d167f792fb330ce9fef/edit

Proposal

The composition machinery should complement the existing dynamic views in the sense that compositions are per-object additions to the globally available views for that object type.

Assuming that it makes sense to have only a single composition defined on a content item at a time, there could be an option to "create new composition" from the display menu, which would take the user to a selection screen to choose from the available templates including the empty layout.

Customizing the template would probably mean copying the template to an annotated storage and this should require that the user holds some permission.

The rendering engine should be pluggable with separation of the data model and the content. Any persistent object can be part of the composition and it should be easy to add views of any kind of object.

There are three major use-cases we need to support:

1. Plastic layouts. Users can create layouts through-the-web in a "plastic" way.
2. Layout restriction. Site managers can restrict the level of plasticity.
3. Reuse of layouts. Existing layouts can be used as templates for new ones.

In other words, the page composition machinery should support both the enterprise requirements of maintaining a firm grasp on the site's general look and feel, and at the same time it should be easy to create layouts, save them as templates and set up restrictions.

Implementation

Placeless templates

To allow using a canonical, placeless template collection we need to have a way of doing local content assignment on the templates in a way that only affects the local context. The suggestion is here to use a "slot" concept where you could plug in content into a slot relative to a local context.

In order for this to be general, what is actually plugged in is an assignment object (similar to the portlets infrastructure). An assignment can be a reference to a content object, or to a portlet, or maybe a simple object.

Markup and style

We will need some framework or strategy for doing the markup and attaching proper styles. One idea is to use a framework such as blueprint or borrow ideas from it. A grid-based approach (rows and columns) seems most feasible but we need this to be flexible enough to handle a wide variety of layouts. Some content like images require special attention.

Deliverables

• User interface mockup
• GS profile XML format

Risks

We'll probably need a migration step for users currently using Collage; this could be extended to other packages that provide page composition capabilities, for instance CompositePack and ContentPanels.

Progress log

Oct 22nd. First draft of the layout engine implemented.
Oct 17th. Initial branch creation and a few architectural ideas laid down in code and tests.

Participants

Malthe Borch