On Wed, Dec 30, 2009 at 1:46 AM, Martijn Faassen <faas...@startifact.com> wrote:
> Assuming ZTK x.y won't have zope.app packages, this means that those
> upgrading to Zope 2.13 might be helped by a list of working versions of
> those zope.app.* packages (such as the one in zopeapp), or am I wrong?
> Of course I imagine this list is quite short in your case, as you were
> already on ZTK 0.5.
The list is quite small indeed. There's:
all of which don't matter, as those are just transitive dependencies
but contain no code that was usable inside Zope 2. And then there's:
zope.app.component was mostly used to import the hooks getSite /
setSite stuff. But we already have zope.site containing those and
app.component is just a BBB shim.
Almost nothing inside zope.app.container is actually used, as we have
OFS and Products.BTreeFolder as the canonical folder implementations,
in any case app.container is a BBB shim around container as well.
zope.app.form has a bit of a special status, but we solved that by
factoring out the entire formlib / app.form dependency into an extra
distribution called five.formlib. Users of formlib can switch to that
during Zope 2.12, in 2.13 we won't have to ship it anymore.
And finally zope.app.testing had seen some uses for the ztapi stuff or
test setup, but generally we have Testing and ZopeTestCase that
provide the Zope2 specific versions of those.
And well, that's it. Since most of the other code inside zope.app was
never actually usable inside Zope 2, we don't have that much of a
problem with it. Some other things are hidden behind ZCML constructs
like the various browser registrations and Zope 2 takes care of
loading the right meta.zcml's for you. Other stuff is hidden behind
Five, which actually works to our advantage now ;)
> Earlier on, we had quite a big discussion about "What is the ZTK" where
> various people were arguing for starting with a short list and building
> it up, versus starting with the long list and whittling it down. At the
> time we went with the latter. One of the motivations for the long list I
> believe was to help people transition better.
Yeah, I was a proponent of the start small approach :)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -