After re-reading the rest of those previous discussions, I see at
least one thing wrong with the "disabled_middleware" attribute
approach. 3rd party apps won't know which middleware is installed that
might break their responses, and end-users won't have a mechanism to
disable middleware for respons
I'm going to try and preempt a possible objection that has been raised
in previous discussions on this subject.
Won't this change require a lot of repetitive logic to be shifted into
middleware functions? All middleware authors will now need to inspect
the response and find out if they can make th
Hi,
On Tue, Sep 14, 2010 at 01:22:37AM +0100, Luke Plant wrote:
> It would be extremely useful to me if you could go through the use cases
> linked on the previous thread and see if your solution addressed them
> all.
Sorry, I'll have to get this out tomorrow. I ended up being a little short on
Hi,
I was re-reading this and wanted to clarify a few points.
On Mon, Sep 13, 2010 at 01:34:55PM -0400, Forest Bond wrote:
> Response Freezing
> =
>
> To address #1 and #2, I'd like to propose a response "freezing" API. The
> basic
> idea is that I can freeze a particular heade
Hi, I just submitted my first patch to Django.
It improves rendering performance 2-7 times when USE_L10N. This is
really noticeable in my current project where I've a spreadsheet like
a view with a few thousand numbers and dates.
Existing implementation was really wasteful, doing a lot of
unnece
On Tue, Sep 14, 2010 at 12:50 AM, Tobias McNulty wrote:
> On Sun, Sep 12, 2010 at 11:55 PM, Tobias McNulty
> wrote:
>>
>> At the DjangoCon sprint this weekend I setup Django on our CI server for
>> OSS and had it reporting on builds in the #django-sprint IRC channel. Would
>> that be useful to c
