I'd like to see some action and discussion on this in Bristol, who's in? On Thu, Sep 2, 2010 at 11:16 PM, Martin Aspeli <optilude+li...@gmail.com<optilude%2bli...@gmail.com> > wrote:
> 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 > -- Roel Bruggink http://www.fourdigits.nl/mensen/roel-bruggink Four Digits BV http://www.fourdigits.nl Willemsplein 44, 6811 KD, Arnhem tel: +31(0)26 4422700 fax: +31(0)26 7600012 KVK 091621370000 BTW 8161.22.234.B01
_______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
