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

Attachment: signature.asc
Description: This is a digitally signed message part

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to