Hi Laurence, +1 to everything here.
Other big things for me: - I think we want Deco GUI + Blocks rendering as an optional add-on for Plone 4.x at some point, to get this tested properly. - I think we want WSGI as a supported deployment option in 4.x, 5.0 at the latest, via the Zope 2.13 WSGI work Martin On 3 September 2010 04:39, Laurence Rowe <l...@lrowe.co.uk> wrote: > 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 > _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
