With the release of Plone 4.0, I thought it would be useful to set out my understanding of where we are headed with future releases. This draws heavily on conversations with Hanno and focuses on infrastructure rather than user visible changes.
The intention is to spark a discussion from which I'll write up a roadmap on plone.org or dev.plone.org. All plans are of course subject to change - but it is useful to set out a direction. Over the years, Plone has accrued much code and added many concepts. In part this is a reflection of the vibrancy of the project, but it has come at a high cost in complexity. Hanno has been doing heroic work with Zope 2 and the ZTK recently, and we will soon be able to completely avoid the large chunks of old Zope 2 code we do not use at all. 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 ------------------------ Once all content has __parent__ pointers to the root, we will be able to use standard ZTK catalog components. Using zope.intid for the catalogue keys allows result sets to be merged across catalogues. 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 directly. Archetypes ---------- Plone 5 should be the last major release with Archetypes compatibility. For form based content types, Dexterity is the future. 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. 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 ----------------- This is another confusing hurdle for new developers and should be abandoned. Form Controller --------------- Other than the Archetypes edit forms, it would be best to remove all other uses. Tools ----- The various tools should become utilities and views. Most of them need not be persistent as settings can be stored with plone.registry. Skins ----- Old style templates should be replaced with views. CSS/JS/Images should all migrate to resource directories. Python 3 -------- In three to five years time we will have to have moved to Python 3. 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. WSGI ---- 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 would be: * Authentication * Resource registries Laurence _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
