[Zope-dev] direction

[Leonardo Rochael Almeida]

Hi Hanno,

On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting <hanno at hannosch.eu> wrote:
> On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists at 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.

> [...]

Cheers,

Leo