Tres Seaver wrote:
Basically:
* we hardly see a use case for empty path elements. They don't work right now, at least not in the way that you expected them to work. So, we're not really breaking anything if we take away something that didn't work in the first place.
The CMF (and Plone on top of it) work *fine* as they are today for completely empty expressions. Reverting the BBB-incompatible cahnge, and adding deprecation warnings, is our standard practice here.
Yes, for changes that ripped out well-understood and well-supported features. I don't know whether we have a standard practice for cases like this, but there's definitely a straight-forward practice: fix the CMF :).
The "empty element" (as opposed to "empty expression", which is what CMF / Plone use) hasn't worked in qute a while, AFAICT. 'unrestrictedTraverse' raises a KeyError in both 2.8 and 2.9.
* AFAIK the CMF tries to compile empty TALES expessions (I don't know yet whether only in tests or also in "real" code, Hanno Schlichting has been testing my branch against the CMF in the past days). This isn't a use case either. It's just misguided usage, as I would call it (Fred agrees). We can fix the CMF to simply not compile empty TALES expressions.
Yes, but you can't break the CMF in a release without doing the deprecation dance first.
Or we could simply fix the CMF. It would have to be done at some point anyways, only that if we do it now it limits the effort. To provide proper BBB for weird behaviour that doesn't even have a good use case is a much larger effort. CMF bugfix releases could be on their way before Zope 2.10 hits even final.
- CMFDefault/skin/configure.zcml blows up because the syntax of the 'browser:skin' directive has changed in a BBB-incompatible way. The now-failing directive is::
<browser:skin name="cmf" layers="cmf default" />
and the traceback is *very* weird::
ZopeXMLConfigurationError: File \ "/tmp/endgame/Products/CMFDefault/skin/configure.zcml", line \ 10.2-13.8 ConfigurationError: ('Invalid value for', 'layers', "ImportError:\ Couldn't import default, No module named default in cmf default")
Ah yes. This is due to a missing ZCML declaration in Five. I already fixed it on the Five trunk (http://mail.zope.org/pipermail/checkins/2006-May/001859.html), but the zpt branch is a bit too old to have this fix. That's why it works fine on the Zope trunk but not on the zpt branch.
They I guess we should update the external for Five on the branch, and verify?
No, because Five was branched off too. But all that should be history now, anyways, because I merged everything to the trunk and removed the ZPT branches. Philipp