On 5 July 2011 20:21, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Hi Hanno,
On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no?
The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working.
I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with "native" interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal:
"I think what's going to stay is AccessControl, OFS (a bit lighter), ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of Zope Toolkit libraries like components, events, browser pages and so on.
That's the kind of scope that should be possible to port to Python 3 and actually modernize enough to be understandable.(...)"
Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base?
If we still have that minimalistic ZMI, all players in our community can decide how much effort they want to spend maintaining which legacy pieces technology, depending on what makes economic sense to them, without causing extra maintenance burden on the other players.
I think the problem with the current ZMI is that it brings in a whole load of dependencies that we don't otherwise need - if it were minimalistic it wouldn't be a problem. I'm all for someone writing a very simple object browser though, it would make a great optional package. I'm certainly interested in moving away from OFS in the medium term towards the much simpler ZTK / Pyramid approach of __getitem__ traversal. Laurence