>
> * Settings that are internally cached. For example, anything that
> modifies INSTALLED_APPS.
>
> * Settings that need to make call to reset state affected by loading
> new new group of settings. For example, if you change TZ, you need to
> call "time.tzset()" on teardown to reset the
> This would kill the ability to use __init__ to store anything on the
> instance, since it would only work for the first request, and so would
> enforce subclassing as the only means of customising behaviour. It would
> be more effective at dealing with thread safety concerns than a
> 'copy()',
>
> We document the issue, warn people not to store state on the instance
> itself, but tell them that if they must have stateful data, it should be
> attached to self.state instead of self, and they will be OK. They might
> still be bitten if they put mutable configuration data into the __init__
>
> I already have one specific piece of API feedback: the current
> implementation requires that all view logic is contained in GET(),
> POST() etc style views. This is fine, except for the fact that there
> are occasions where GET and POST share a lot of common logic. It would
> make sense to me
>
> I'm not particularly for or against the idea.. but I know raising more
> meaningful exceptions is an issue that has received some attention
> previously.
>
> Thoughts anyone?
I think its fairly simple and definitely positive. If we apply the DRY
principle to the mailing lists this would be a
For reference:
http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login
(look
at the note at the end of "login()" called "Calling authenticate() first")
On Thu, Sep 23, 2010 at 3:56 PM, Santiago Perez <san...@santip.com.ar>wrote:
> You need
In the cases where you want to prevent server-side caching but are ok
with client-side caching, couldn't you freeze the 'Cache-Control'
header to another value and set all necessary headers to get the
caching you want? Would that work?
On Wed, Sep 15, 2010 at 3:03 PM, Forest Bond
>
> The biggest problem with the approach I've proposed is that it is not
> sufficiently granular to handle the case where I don't want the response
> content
> modified (e.g. compressed) but I *do* want to return HTTP 304 Not Modified
> where
> appropriate. That's the only use case I can think
> I'd be happy to use raw(); but then you lose len(), slicing,
> pagination, filter chaining, etc. My problem came about because admin
> change lists were unusably slow on large tables. With_hints allowed a
> simple monkey patch to admin, dropping 2s per page down to ~0.01s.
How about a
> I can't really imagine that this situation is all that common. I'm not
> saying it's never used, but the barrier is a bit higher than just "more
> than one person uses this".
Maybe it's just me, but in all 3 projects I have faced with django so
far I have had to work around this, the most
Hi, I found myself needing to reference the previous or next element
of a list within a for loop of a template.
I think it would be pretty easy to implement the following extra
members to the forloop context variable:
+ forloop.next_element
+ forloop.next_counter
+ forloop.next_counter0
+
11 matches
Mail list logo
