[Zope-dev] Zope 2.13 roadmap

[Martin Aspeli]

Hanno Schlichting wrote:
> On Thu, Apr 1, 2010 at 9:33 AM, Martin Aspeli<optilude+lists at gmail.com>  wrote:
>> Hanno Schlichting wrote:
>>> - Five deprecation
>> +1 - sounds hairy, though.
>>
>> Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView
>> (already done, I guess) would be a good starting point.
>
> With Zope 2.12 BrowserView is basically done. You can now import the
> BrowserView class from zope.publisher.browser instead of the one from
> Five. But ZCML directives still use the Five class, to ensure code
> using fancy Acquisition magic continues to work.

Right. That's pretty unobtrusive, though, and doesn't stop you from 
writing views that work in other Zope scenarios.

> ViewPageTemplateFile is a very different beast. The page template
> machinery of Zope2 and zope.tal are different enough, that there's no
> easy upgrade path. The expression context ("here", "modules", ...),
> path traversal, restricted templates, ... there's enough subtle
> differences all over. I think it is more likely that applications like
> Plone will switch to Chameleon and adjust import paths to a chameleon
> specific package.

That's probably a better solution, although I'd really like to be able 
to write packages that use page templates that are not tied to Zope 2, 
Five, Plone or, ideally, Chameleon, at least not unless everyone else 
(Grok, Blue Bream, thus the ZTK) switched to Chameleon and deprecated 
zope.pagetemplate.

>>> - Make Zope 2 more modular
>> I think it may help to make a list of the things we'd like to be able to
>> get rid of, and then isolate those.
>
> I'd kind of like to be able to explicitly decide what to get and make
> this an opt-in. I could see someone using AccessControl, OFS, Zope2
> (for the application bootstrapping) and ZPublisher without much of
> anything else, except their "dependencies" like Acquisition or tiny
> packages like Globals, Lifetime and Signals. Such a minimal set
> wouldn't be called Zope 2 anymore, as Zope 2 is the application server
> with all the TTW capabilities, Python scripts, ZRDB and friends. But
> only actually looking at the code and refactoring it will tell to what
> extend this is possible. My first step is to attack Five, as its been
> pulled in by everyone and was dependent on everything in return. Once
> we untied that knot, we can see what is going to be possible.

Good plan.

>> One thing that would be interesting from a Plone perspective is whether
>> people could optionally use Zope 2.13 with Plone 4.x. That may be quite
>> attractive if Zope 2.13 has WSGI.
>
> This is speculation at the moment. If WSGI ends up in 2.13 without a
> backport to 2.12, we can look at it. One option is for someone to
> backport the changes into a standalone package, like repoze.zope2 and
> allow people to pull it in as an experimental backport. If only some
> people will want to use it, this is a very viable option and much like
> the status quo of repoze.zope2 today.

Indeed, I just don't want to end up with the kind of inevitable bitrot 
that something as complicated and compatible as repoze.zope2 ended up with.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book