[Twisted-web] web2 response.setCookie and request.getCookie shortcuts?

[Clark C. Evans]

On Thu, Nov 17, 2005 at 08:26:36AM -0500, glyph at divmod.com wrote:
| On Thu, 17 Nov 2005 13:23:26 +0100, Aleksandar Erkalovic wrote:
| >will i be forced to carry my language flag around in my data model and
| >learn my loaders and renderers to get from data model what template to
| >load or maybe you guys are thinking that Request object could be used
| >to carry this kind of information? 

The acceptable languages that the _response_ is allowed to take can be
found in the 'Accept-Language' header.  This has the advantage of
allowing more than one language choice, eighted by preference and
typically auto-configured by your browser from the operating system
defaults.  In most browsers this setting can be changed; for example, 
in Firefox go to about:config and navigate to intl.accept_languages.

That said, if you have an authenticated user, you might want to provide
a server-side override mechanism so that people using an internet cafe'
in a foreign country are given their primary language.   However, this
is more of a 'Avatar' property.

You can use a path segment to do this I suppose; but it is not standard
and is quite ugly [1].

| This is a good use case, but your language flag *should* be in your data 
| model.  It's simply a mistake to put it in the context.  For example: 
| user A (who speaks en_US) is browsing your site.  They perform an action 
| which impacts user B (who speaks fr_FR).  You need to generate an email 
| to user B.  You look at the context: I guess the email should be in 
| english (whoops!).

This is totally unrelated.  Of course, if an action is going to be
carried out _beyond_ the response; then the application needs to 
know about the users and respond appropriately.  *winks*

Best,

Clark

[1] On a related note, I use a generic PathArgs resource that "consumes"
path segments that have an equal sign in them.  This resource then
modifies the cookies of the incoming request as if they were sent via a
Cookie header.   The advantage of this approach is that an arbitrary
number of /key=value/ path segments can occur in the top of the URL if
the browser doesn't support cookies.   Then a SessionManager resource
sits right below the PathArgs and looks for the 'session' cookie, etc.