If the super call changes any data then by the time you've run whatever
code comes after the super call, the changes have already occured.
- If you wait to call super before running your own code, then request,
args, and kwargs are not available on the request, so anything that depends
On 14/11/12 03:43, Justin Holmes wrote:
> My only concern is that we'll limit our audience by requiring users to
> use a specific STATICFILES_STORAGE. What if they're already using a
> custom one?
One solution is to have your own COLDBREW_STATICFILES_STORAGE_BACKEND
setting, which can be used
On Tue, Nov 13, 2012 at 7:04 PM, Rohit Banga wrote:
> I have some abstract models and I have created several concrete
> implementations of each of these models. The usecase is create multiple sets
> of tables across each having the same set of fields. When I use abstract
Hmm, ok, so that is only and issue if you don’t know the side effects calling
super when dealing with non django provided views - and you can still
pre-process request before calling super.
So at the moment I can understand the appeal of init() as shown in the example
but fail to see where I
For example, you miss Http404 and other error responses, which are
implemented as exceptional control flow. In addition, you can't do any
preprocessing of the request; for example, you can't set up any invariants
before your actual view method is called.
Best,
Alex Ogier
On Wed, Nov 14, 2012 at
Can you elaborate the nasty side effects you are thinking of? I can’t think of
any that that the base views do to warrant your statement.
From: Aaron Merriam
Sent: Friday, November 09, 2012 3:12 PM
To: django-developers@googlegroups.com
Subject: Re: Class based views: A standard hook for
Thanks for the feedback everyone. I'm made some updates based on these
suggestions, please see the ticket:
https://code.djangoproject.com/ticket/16779
On Sunday, November 11, 2012 5:50:18 PM UTC-5, Daniele Procida wrote:
>
> On Sat, Nov 10, 2012, Tim Graham
> wrote:
>
>