CPS4/Z3ECM Paris sprint report, CPSSkins4Five

I spent the week during the CPS4/Z3ECM Paris sprint trying to make cpsskins v3 (written entirely with zope3) run on zope2.

Here is a summary, but first see the preview animation

For some background information:

cpsskins v3 provides a theme engine and a portlet manager for zope3.  However it did not until now run on anything but zope3, which provides better technology to develop with but which also still has a limited amount of end-user applications.

The Five approach which consists in using Zope3 technology in Zope2 would have been interesting to consider at the start of the cpsskins project, but the goal was instead to develop entirely with zope3 first and to consider backward compatibility issues with zope2 later on, i.e. now.

Strategy

The strategy is still to keep on developing cpsskins in zope3 without worrying about zope2, which means that cpsskins v3 contains no references to zope2.

However, there is now a Zope2/Five product called CPSSkins4Five which acts as a bridge between zope3 and zope2. In CPSSkins4Five, cpsskins v3 is considered as a python library that does theme rendering.

CPSSkins4Five currently runs on the philikon-local-components branch of zope2 which integrates the jim-adapter branch of zope3, and contains changes in Five for using the new local utility and adapter registration API.

All these branches will be merged into the upcoming zope 2.10 (scheduled in June).

CPSSkins v3 heavily uses local utilities for registering resources and having a clean and a unique API in zope2 and zope3 was sufficiently important to justify developing against Phillip's and Jim's branches.

First phase

The first phase was to port cpsskins v3 to the new local utility and adapter API. This was done in a branch of cpsskins called paris-sprint-2006.

A simple doctest was added to make sure that the part of the utility registration API used by cpsskins worked as expected.

Second phase

The second phase consisted in getting the philikon-local-components branch of zope to start, which required adjusting some module import paths.

Third phase

Then cpsskins v3 was added into the lib/python directory of the zope2 instance. The CPSSkins4Five product was created to load cpsskins' zcml configuration files, do some minor patches and load zope3 packages required by cpsskins.

Also an simple installer was created to make it possible to create a CPSSkins site inside the ZMI.

A "CPSSkins site" can be any folder in Zope2 (CMF, CPS, Plone, Silva ... site) that can be turned into a zope3 site with a local site manager. Of course CPSSkins4Five does not provide compatibility with CMF or CPS or Plone sites, but it shows how a simple zope folder can become a CPSSkins v3 site.

Zope2/Five issues

There have been and there still are a couple of issues:

Use of resources

In zope3, I am used to referring to resources with /++skin+cpsskins/@@/++resource++myfile.css to provide a fixed path to objects. In Five/Zope2 this apparently does not work.

path adapters

I did not manage to get path adapters to work in Five, which is why the theme editorstill displays the "KeyError: formattable" message ('formattable' is a named adapter with support for path traversal).

docstrings on publishable objects

Zope2 does not publish objects without docstrings. The solution is to add docstrings to these classes, however it often takes time to find out what is missing.

page templates / zope2 requests

When passing a zope2 request to zope.app.pagetemplate.ViewPageTemplateFile or to a BrowserView a 'debug' attribute is missing in the request which make it impossible to debug errors unless the attribute is manually added to the request object before calling the template.

icon directive / Five

The <browser:icon> directive is missing in Five.

zope3 packages not configured in Five

A lot of zope3 packages are by default not enabled in Five, although they are distributed in zope2 and are available as python packages. This is not really an issue since the CPSSkins4Five product will load them, but it can take some time to identify the real problems, as one is expecting a bug in the application. Such packages are: zope.app.keyreference and zope.location.

Positive points

The result is very positive: apart from the remaining issues described above, this experiment has shown that it is possible to develop entirely in zope3 for months and port to zope2 afterwards. This however requires that the application be developed without creating too many points of entries with the ZODB. In cpsskins v3 there is only one point: i.e. the "theme management" local utility which contains all persistent information used by the application.

Future plans

• make it possible for Zope2 applications to register specific portlets. Fortunately the application will only need to provide data structures (not presentation which is taken care of by cpsskins)
• try and use complex schemas definitions using another language than zope3 schemas for describing portlet data structures that are typically non-flat data structures.