plonewars.com

I pair-programmed on CacheFu today with Maciek Dziergwa. See
yesterday’s
entry
for a list of things we could work on.

Fixing unittests

Today’s cachfu sprinting started out with fixing the failing
unittests. In the first hour, we fixed two templates in CMFSquidTool
and fixed one failing unittests: a test that failed if you didn’t have
an apache running on port 80 on your local machine. That’s not very
unittest-like, but ok. We now catch the error that occurs and the rest
of the tests are running ok.

We added a few if/else statements to CacheSetup that conditionally
import code for either plone 3.0 or 2.5, this makes sure the product
is usable for both. The change was needed because plone3.0/zope2.10
uses a different page template implementation.

We ran into some remaining test problems:

• The rules defined in CacheSetup’s genericsetup.xml seem to
  disappear from the cache configuration, somehow. strange. Only in
  plone 3.0, though.
• PolicyHTTPCacheManager also has a testing problem: the result is
  different in 3.0 and 2.5 due to a change to cmf 2.x. There’s a
  strange message in the doctest: Starting with CMF 2.x any caching
  policies previously registered with the site are automatically
  applied to CMF Files and Images in their respective index_html, so
  we get the cache headers even before associating with our
  PolicyCache. Anyone know what to make of that?

Genericsetup

Genericsetup support was added by Rocky (and it works like a charm),
it only missed the last configuration tab. Nice, bite-sized task. We
discovered it was missing the data from the last configuration tab
because that data comes from a separate tool (the pagecachemanager)
in the plone root, not from AT contenttypes like the rest of the
cachefu setup machinery. We didn’t get it working yet, basically
because there was a missing configure.zcml that prevented the
testing mechanism from finding the exportimport adapters. Now I’m
getting another error. We’ll figure it out.

Handy comments we got during the day

During the day, I got a couple of very handy comments from people
that I’m writing down here to preserve them.

• Wiggy suggested what is essential for caching is that someone
  implements a post-publish and pre-publish events for the zope2 and
  zope3 publishers. Once you have those you can easily reimplement
  cachefu cleanly. You want post-traversal-pre-publish so you can
  look for a cached rendering you can immediately serve and you want
  post-publish so you can tweak response headers and cache the final
  rendered output. If it got implemented during the sprint, it
  could potentially end up in zope 2.11, which would mean plone
  3.5+.
• Wiggy pointed me at lovely.viewcache, that caches z3 views so
  you can strike that from your todo list. Zope3 views, no cachefu
  evilness.
• Stonor said z3c.responseheaders also looks relevant.
• During the lunch, I talked with Balasz and Alec. The conclusion
  was that adding the event to zope’s publisher wasn’t that good an
  idea. The publisher will change anyway (when twisted will get
  used). And you probably can’t send a response back to the browser
  from within an event. Balasz has some code in a json server that
  patches zope’s publisher. That might be a good stop-gap measure
  that replaces three monkeypatches with a single one. And it is
  something that will work in plone 2.5 and 3.0, too.