One problem with fixing the refresh is that the more you fix, the
longer the refresh will take. To fix Five to be stable in refresh, we
may very well have to kill all things registered by ZCML, and
re-register all of it. It's highly unlikely that we get a real stable
refresh by just refreshing one products ZCML. What happens if there
are overrides, and so on.
So, in the end, you end up with refreshing everything, which would
take just as long as stopping and starting the ZEO client.
We can probably make it possible to make the refresh somewhat more
stable and support a wider range of cases. But you still have to make
very careful configuration of the refresh in most of this cases, and
if you don't do it just right, it won't work.
So I'm not sure it's worth the effort.
Doing tests is a good idea especially if you take a bit of care. The
calendar products I'm working on have that care taken automatically,
as it's split into three products, one pure python, one Zope layer
with the persistance and UI and one CPS integration. Most tests are on
the python product, or the Zope product. The python tests take 0.8
seconds to run, the Zope tests 4 seconds.
With CPS it gets worse, because the tests need to create a CPS site.
It's the same with Plone. In those cases tests will not be faster than
refreshing. Running all of them takes a bit less than a minute I
think, and running just one isn't that much faster. But the amount of
tests needed there is very low, as most is done on the CalCore and
This way development is pretty fast, and doesn't need much refreshing.
Then comes a part where you need to get it to actually work, and not
just pass the tests. Here you need to refresh a bit. And then most of
the work is UI-fixing, which doesn't need refresh again, because it's
I find this mode of development faster than when I had working
refresh, beause the existance of the tests stop me from shooting my
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -