>
> * 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 timezone
> 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()', bu
>
> 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 wrote:
> You need to obtain the user by calling auth.
You need to obtain the user by calling auth.authenticate, this sets the
backend to the user.
auth.login expects an user created this way and stores the backend in the
session, if you want to avoid the auth.authenticate you will have to set a
backend in the user yourself.
On Thu, Sep 23, 2010 at
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 wrote:
> Hi,
>
>
>
> 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 of
> 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 raw_hints(
> 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 usual
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
+ for
12 matches
Mail list logo
