[Zope-dev] direction

[Laurence Rowe]

On 5 July 2011 20:21, Leonardo Rochael Almeida <leorochael at gmail.com> wrote:
> 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.

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