My Zope 3.3 wishlist ==================== We got a month and a half left till the feature freeze for Zope 3.3. Here's my wishlist of things that I'd really like to see happen in this release: Egg support. This doesn't necessarily mean that Zope 3 itself will be packed up as eggs (or "egg salad" as we called it in Dallas, since each package in the ``zope`` namespace would be its own egg). This "just" means that Zope 3 will support 3rd party eggs in a zip-safe form. PageTemplates, ZCML, browser resources, etc. will all have to be loaded from ZIP files. Fred started working on this at some Goldegg sprint. His work remains on the ``zipimport-support`` branch. It introduces a new package, ``zope.filereference``, which seems to duplicate a lot of (if not all of) setuptools behaviour and smells a lot like NIH. In any case, the value in this branch is not really ``zope.filereference``, but the identification of all (or most of) the places where files in packages are loaded and, even more importantly, tests for loading them from ZIP packages. Perhaps somebody wants to pick up this branch again, see if it can't be made to use setuptools instead of a home-grown solution and bring it into the trunk in time? Smaller ``zope.app``. ``zope.app`` is a beast whose definition is vague and diluted by now. Basically, ``zope.app`` should only contain the application server itself: the server bootstrap, the default publication and perhaps some wiring. Frameworks like ``filerepresentation``, ``annotation``, etc. could very well be used outside of ``zope.app`` (Zope 2 would be the best example). `In a mailinglist post last month `_, I asked about this and Jim suggested in a response to start moving down those things that are needed by Zope 2 so that in the future, Zope 2 won't need to include ``zope.app``. For some packages, this might be trivial because they would simply be moved from ``zope.app.foo`` to ``zope.foo``, installing a temporary backward compatibility alias in ``sys.modules``. Other packages would have to be merged with their ``zope.*`` equivalent, or divided up into several packages. A proposal for this would probably require some research and a fair amount of digging through Zope 3 sources. Less ZCML directives. I believe `ZCML needs to do less `_ and so do `Jeff Shell `_ and a bunch of other people. This has two parts: * `Reducing the amount of specialized ZCML directives `_ when a little bit of Python code and a more general directive would also do. I have killed 8 directives so far (not counting the ``content`` alias to the ``class`` directive). That's only 10% of all the directives out there. * Reducing the work that directives do. This may or may not boil down to the same thing described in the previous point. If, for example, we decide to let ``browser:page`` stick around, then it should at least not do magic class creation, or at least only when a template is registered without any auxiliary view class. `I brainstormed about this before `_ so there are a few ideas in my head. Some people feel strongly that ``browser:page`` (or ``browser:view``) should stick around, so whatever we come up with might just be a compromise (directive(s) stick around, but they do less magic). Better local component configuration. `Jim proposed this `_ some time ago and has implemented large parts of it on his ``jim-adapter`` branch. This currently mostly entails the adapter look-up refactoring (and optimization!) that is part of this redesign (I vaguely remember Jim mentioning at PyCON a 100% speed increase for unit tests). My wish is to have a simple and straight-forward story for local components. `At PyCON I was able to create a prototype `_ for a particular use case (the *Customize* button) that hopefully leads to a local component framework and UI shared between Zope 2 and 3. So, Easter Bunny, won't you please make those wishes come true... :)