On Wed, 2006-06-09 at 13:52 +0200, Philipp von Weitershausen wrote: > That said, *if* we choose to go with such a configuration option, I > think it woudl probably be a good idea to have it disabled by default in > the first release and enabled in subsequent releases. That way > applications could opt in for the new behaviour earlier than necessary > (much like Python's __future__ imports).
My 2 cents here. I've also spent a great deal of time pondering this particular problem. And there has been some good discussion in this thread. Personally what I'm leaning towards liking the most would be an approach that blends the configuration and adapter ideas discussed here. Five version X would introduce an IBrowserRequest adapter for a zope 2 request and a new zcml directive, say five:zope3request, that would toggle whether or not Five should pass through the adapted request instead of the raw request. By default it would not adapt (for BBB compat). We could consider issuing a deprecation message saying the default will be changed with future Five release. And with Five version X+1 or X+2 we change the default to adapt. I'd propose version X would be 1.5 and the release that sets the default to zope3 requests be version 1.6. We could always keep around the five:zope3request directive even after we change the default so that people who really need old-style behaviour (raw zopee 2 requests) can still re-activate it. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
