Friday, July 18, 2008

Plone reloaded

I've been silently working on a project called plone.reload which has been noticed by some.

After I got positive feedback from Martin Aspeli, Kai Diefenbach and Jon Stahl I felt it might be ready.

Danny Bloemendaal calls it:
The best improvement since the day (automatic) product refreshes died in Zope.
And my Co-Worker Denys Mishunov told me:
We should include it in every project we do.
So what is this project that gets people excited?

Its PyPi page is short and concise without any glamour:
Configuration and code reload without server restarts.
What does this mean for you? It brings back the good old refresh feature, we used to have for Products. Remember the refresh.txt files? Does it work for products alone? No!

This project tries to bring code reloading back into the modern world of Zope 3. Reload code located in browser views? Not a problem. What about that new browser:page you registered? Just reload all your ZCML without having to restart your server. Do you need to mark your packages in any way? No, you don't.

This project is most useful when you do user interface oriented work. You can work on file system based templates just fine in Zope debug mode, but so far modifying underlying browser views, viewlets or portlets always required you to restart. This time is over!

Is this useful as a general reload feature for all code imaginable? No, it's not.

For all application specific logic unit tests are still your best and fastest bet. For content types, register them once, get your GenericSetup profiles up and keep them as stupid as possible. Then plone.reload will help you on getting your user-interface in shape, without spending your time on getting coffee while Plone restarts all day long...

This project is heavily based on the work done by the fine Products.RefreshNG folks and wouldn't been possible without Guido himself contributing to the idea. So if you find it useful, remember the titans on whose shoulders we stand upon.



  1. I can attest that plone.reload is amazing. This, plus the startup speed work that Hanno has done recently means that developing in Plone has gotten a lot more pleasant.

    Another thing that makes for speedy development: write proper unit tests, not integration tests, and rely on them for the "after each change" type test runs. You still need integration tests, but you don't need to run them constantly.

    Fast unit tests are possible with mock based testing. See

  2. "We should include it in every project we do."

    # development.cfg
    extends =

    eggs +=

    zcml +=

    Done, Kai :-)

  3. Can this be made to work in Zope3 or, more importantly, Grok?

  4. @peterbe:

    The dependencies on Zope2 are pretty minimal, but so far I didn't consider it to be of much to any help for a Zope 3 project. Usually the restart time for those should be under three seconds and most of the time you will have a much higher focus on unit tests.

    I'm not quite sure how exactly Grok does the configuration actions (grokking) but it might conflict with the plone.reload approach. I can probably ask PhiliKON about it at the Black Forest Sprint :)