[Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Chris Withers wrote:
> Philipp von Weitershausen wrote:
>>> Practically, it will very rarely hinder you to add attributes (such as
>>> "locale") to the request.
>>
>> I think "locale" and "debug" are just common enough to be form variables.
> 
> Funny, I've never used either in 6 years of zoping ;-)

Me neither, but are we prepared to break the apps of the people who do?

(Btw, just thought of another one possible name clash: 'response')

>> You'd be surprised (I was too). Plus, TALES path expressions first try 
>> attribute access, then item access.
> 
> ZPT sux ;-)

TALES path expression sux (for various reasons).

>> Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I 
>> wouldn't mind. But I'm sure others would.
> 
> I thought adapters were for this exact kind of thing?
> Existing Zoep 2 code would use a Zope 2 request, the Zope 3 components 
> should be presented with a Zope 2 request that has been adapted to 
> present IBrowserRequest rather than just being marked as implementing 
> it, no?

This would have been a possible solution at the time, but it wasn't 
chosen. Neither the people who introduced IBrowserRequest to Zope 2 nor 
I who pretty much took on Five maintenance afterwards realized this 
problem back then.

I've thought about introducing the adaption approach now. I think we'd 
be opening a can of worms since the request objects are likely to be 
passed from old style code to new style code and vice versa.

>> Perhaps. A configuration option (that would usually be turned to 'off') 
> 
> What do you mean by "off" here? The config option should make the stfuf 
> that ships (like the widgets!) work by default...

I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 
doesn't mean that everything from the 'zope' namespace has to work. Five 
has never made that promise.

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).

Philipp