Acquisition

Acquisition was introduced because the ZODB did not support reference cycles. As a programming paradigm though – at least in the implicit form used within Zope 2 – it has been a failure. It is strange and unfamiliar to new developers.

It also prevents us from using some natural patterns: the catalogue indexes content by path rather than directly; references between content must be indirected through a path.

Phillip and Hanno's work to enable Acquisition over __parent__ pointers (included in Zope 2.12 / Plone 4) has given us a path out of our current dependency on it. This has already simplified BrowserViews. The next step is to make sure all content has __parent__ pointers all the way to the application root. We should do this for Plone 5 and drop Acquisition entirely in a future version.http://wiki.zope.org/zope2/SetParentAndNameInOFS

Catalogue and References

We won't actually end up using many of the ZTK catalog components - they are generally too simplistic. The ZCatalog and PluginIndexes components offer many more features, especially now that queryplan is part of ZCatalog in 2.13. We will probably end up coding our own plone.catalog and extend plone.indexer.

Once all content has __parent__ pointers to the root, we will be able to use zope.intid for the catalogue keys, enabling us to merge result sets across catalogues. The catalogue index will reference content objects directly (rather than their path), making renames and moves much less expensive operations.

We'll also be able to store relations as simple references on content - related items can be stored as a simple list of objects on a piece of content. These can then be indexed in zc.relation.

Archetypes

Plone 5 should be the last major release with Archetypes compatibility. For form based content types, Dexterity is the future. We will want to provide a simple migration route for existing content (by automatically creating a persistent Dexterity schema). Any custom templates or views would require manual updates.

The Publisher

The Zope2 publisher has become incredibly complex, with numerous different hooks. In the long run (Plone 6?) we should replace it with our own simplified publisher which runs only in a WSGI pipeline. There will be a lot to learn from BFG here, though that is probably too simplistic for Plone.

Ideally we will also move to WebOb based Request/Response objects, bringing us increased compatibility with other WSGI components.

OFS and CMF

Currently, all Zope2 content inherits OFS.SimpleItem. All Plone content also inherits from CMF. In the long run, content items should have simple classes with code in views. These are significant changes and are likely to be the most difficult.

Restricted Python, Skins, Form Controller

This is another confusing hurdle for new developers and should be abandoned. There shouldn't be any support for writing persistent Python code in the form of scripts at all. The Python expressions in templates won't be using Restricted Python either after the move to Chameleon.

With the exception of Archetypes, core Plone should remove any remaining persistent (incl. CMF file-system based) code and templates. Old style templates should be replaced with views. CSS/JS/Images should all migrate to resource directories.

Other than the Archetypes edit forms, all other uses of Form Controller should be removed.

Security

The current AccessControl security model has served us well. While some simplification may be possible by dropping unused legacy features, no major changes to functionality should be expected. Porting to Python 3 will be the obvious time to make any simplifications.

The ZODB

While it is unfamiliar to new developers, building on top of ZODB is hugely beneficial to Plone. Semi-structured content management data just doesn't map well to relational databases. That said, by reducing our expectations on content types, it should become easier for add ons to integrate relational database backed content into Plone.

Tools

The various tools should become utilities and views. Most of them need not be persistent as settings can be stored with plone.registry.

Portlets and Viewlets

Portlets and viewlets are powerful concepts but they have proved a difficult stumbling block for new developers. The Deco project is working increased layout flexibility for content editors. It also makes it much easier to create dynamic page fragments in the form of 'tiles'. These will replace portlets and most current uses of viewlets.

Python 3

Plone will not be an early adopter of Python 3 - there are too many dependencies which must be ported first. In three to five years time though, we will have to have made the move.

It seems likely that there will be others to help the ZTK porting effort, but little interest in porting Zope2. For the time being then, our focus should be on progressively removing our Zope2 baggage and reducing our dependencies so that our porting effort will be simpler.

It is unlikely that Plone will be able to support both Python 2 and Python 3 concurrently - there will be just too much code.

WSGI

WSGI capability will be in Zope 2.13 / Plone 4.1 and while it will certainly be considered experimental rather than supported at first, we can expect people to gain experience with it over the 4.x series. If all goes well, we will then be able to require WSGI for 5.0.

Various components should be move out of Plone and into the WSGI pipeline. This should allow us to share code with other projects. Prime contenders for this are Authentication and Resource Registries.

Theming

Plone 5 will see plone.app.theming, the integration of Diazo (XDV) and plone.resource, become the default theming system. plone.resource allows themes to be packaged as simple zip files rather than python eggs. The Diazo (XDV) theming engine enables themes to be created without reference to the various markup generating technologies which make up a Plone page.