On 09/04/13 12:34, Tom Evans wrote:
> The basis of web development was CGI. From CGI came everything.
> Therefore, almost all webservers - Apache, nginx - almost all
> frameworks - RoR, PHP, Django - that deal with the web will have
> similar or equivalent environment hashes like this.
> The convention for headers (uppercase header name, s/-/_/g, prepend
> 'HTTP_') is similarly ubiquitous.
>
> Your argument is that this structure is confusing to the absolute
> newbie who has never programmed a web application in his life. My
> counter argument is that changing it would be confusing to anyone who
> has ever programmed a web application in the last 20 years.
Well, that depends on which frameworks they use. From what I can tell,
Java servlets have an API like request.getHeader("Accept-Language")
without the HTTP_ name mangling, and ASP.NET has
Request.Headers["Accept-Language"]. It's entirely possible to be a
competent web developer without knowing about CGI name mangling.
I don't often follow Java/C#, but I'll gladly follow anyone that is
using a sensible API, and I really don't believe that current
familiarity with quirky historical artefacts should hold us back -
Python 3, to take one example, would never have happened with that attitude.
I don't have (too much) of a problem with things like WSGI following
CGI, if only because they had to in order to gain traction, but that
isn't a reason why developers should be forced to do CGI name mangling
to access a header.
>> The biggest problem is what to do with our test Client and
>> RequestFactory, which allow specifying headers as keyword arguments
>> using the CGI style of naming e.g.:
>>
>> self.client.get('/path', HTTP_X_REQUESTED_WITH='XMLHttpRequest')
>>
>> Since keyword arguments can't have "-" in them, this is harder to
>> replace. We could either leave it as it is, or add a new 'headers'
>> keyword argument to these methods, deprecating **extra.
>
> This seems a problem with the API to Client and RequestFactory, not a
> problem with request.META
Now that we've dropped the proposal to deprecate request.META, and just
add request.headers as an alternative for getting HTTP headers, these
classes don't need to change. It was simply for consistency that I
proposed fixing them.
Regards,
Luke
--
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
