Re: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

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 them being there (such as self.get_object()) will not work, so it must 
   be re-implemented, 
   - Otherwise you have to set request, args, kwargs yourself which does 
   not feel very DRY.
   
For me, the entire reason I would like this change, is so that I can do 
something before dispatch that uses self.request/args/kwargs.  Everything I 
want can be accomplished within dispatch, but not as cleanly, or as DRY as 
if this method hook existed.

On Wednesday, November 14, 2012 6:49:06 AM UTC-7, Daniel Sokolowski wrote:
>
>   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-d...@googlegroups.com  
> *Subject:* Re: Class based views: A standard hook for 
> http-method-independent code
>  
> That pattern has nasty side-effects.  It can be used in some cases but it 
> fails in most.
>
> On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
>>
>>   I’ve done the below in the past, the only issue with that is if you 
>> have side effects in parent’s dispatch you don’t want executed but you 
>> would also run that risk if you had an initialize() method work flow; in 
>> the end I find dispatch() is enough in my experience. 
>>  
>> def dispatch(self, request, *args, **kwargs):
>> parent_dispatch_return = super(Class, self).dispatch(request, *args, 
>> **kwargs)
>> ...my code based on values based on the super call...
>> return parent_dispatch_return
>>   
>>  *From:* Jordan Hagan 
>> *Sent:* Friday, November 09, 2012 12:37 AM
>> *To:* django-d...@googlegroups.com 
>> *Subject:* Re: Class based views: A standard hook for 
>> http-method-independent code
>>  
>> Hey Russ, 
>>  
>> The main point of concern which I think you may be missing is that 
>> self.kwargs and self.args are set inside dispatch, so using other mixins 
>> that require self.kwargs and self.args to be set (most do) will not work, 
>> without doing:
>>  
>> def dispatch(self, request, *args, **kwargs):
>> self.args = args;
>> self.kwargs = kwargs
>> self.init()
>> return super(Class, self).dispatch(request, *args, **kwargs)
>>  
>> Which isn't very tidy, to me having self.args and self.kwargs be set 
>> twice (once in my overridden dispatch method, and once in the original 
>> dispatch) feels wrong. I can't give you a good reason for it, it just feels 
>> bad every time I do it. The only way to work around this is to override 
>> dispatch without calling the original, and essentially duplicate the 
>> original dispatch method with an init call added in.
>>  
>> Cheers,
>> Jordan
>>   
>> On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <
>> rus...@keith-magee.com> wrote:
>>
>>>
>>>
>>>  On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam wrote:
>>>
 Without setting request, args, and kwargs on on the view instance 
 (which is done during the base dispatch view), anything in the view that 
 assumes these values are present cannot run.   
  
 Most of my views end up with functions which retrieve an object and 
 then do some basic validation to ensure that a user has permissions, or 
 that the object is valid in some fashion, or that some set of conditions 
 is 
 met prior to allowing any method call to happen.  
  
 I have found that without this init method, the vast majority of my 
 views end up re-writing dispatch which includes the super call.  This is 
 especially annoying when you have to compare some aspect of the requesting 
 user with an object that must be looked up with something from args or 
 kwargs.  My view often already has this machinery built in, but it can't 
 function without dispatch setting request, args, and kwargs, so to 
 accomplish my check, I have to duplicate the lookup code in my dispatch 
 method.
  
 I don't propose mine is the best solution, but I know that it is 
 non-intrusive, simple, and covers my use cases well.  It is also simple to 
 accomplish any number of things since `init` merely needs to return a 
 falsy 
 value to allow the request to pass on through, raise an exception if that 
 type of failure is desired, or return a response of it wants to hijack the 
 view entirely.

  
>>> I'm starting to feel like I'm incredibly dense, because I still don't 
>>> understand what your use case *is* - or, at least, why what your proposing 
>>> provides any significant advantages over what you can do using basic Python 
>>> inheritance techniques.
>>>  
>>> 

Re: proposal: post-collectstatic signal

[Luke Plant]

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 if people have their own STATICFILES_STORAGE,
and your one wraps it. django-mailer uses that approach to allow it to
wrap whatever real email backend people are using.

Luke

-- 
"It is a truth universally acknowledged, that a single man in
possession of a good fortune, must be in want of a wife." (Jane
Austen)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature Request: Support for abstract models in ModelForm

[Tom Evans]

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
> models for modelforms it works fine until I get a unique key in the picture.
> Details of the problem I faced are detailed in this django ticket.
> https://code.djangoproject.com/ticket/19271
>
> Working version of code: (Works just by chance - Apparently it is not
> supported)
> https://github.com/iamrohitbanga/django_ticket_19271/tree/code_working
>
> Non-Working verison of the code (unique key in abstract model)
> https://github.com/iamrohitbanga/django_ticket_19271/tree/code_not_working
>
> Is it possible to support this feature in a future release?
>
> Thanks
> Rohit
>

Can you explain what an "abstract ModelForm" is for? ModelForms are
used to accept and validate browser input and serialise that data to a
Model, storing or updating that data in a database. Abstract models do
not correspond to database tables, so what is the use of this?

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

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 couldn’t just use dispatch() instead. In the past when 
we needed to tie permission checks I opted into making a view mixin to override 
dispatch similar to this one: 
https://github.com/lukaszb/django-guardian/blob/master/guardian/mixins.py

Perhaps people that do find this init() method worthwhile should voice so. 
Thanks
From: Alex Ogier 
Sent: Wednesday, November 14, 2012 10:35 AM
To: django-developers@googlegroups.com 
Subject: Re: Class based views: A standard hook for http-method-independent code

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 8:48 AM, Daniel Sokolowski 
 wrote:

  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 http-method-independent 
code

  That pattern has nasty side-effects.  It can be used in some cases but it 
fails in most.

  On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
I’ve done the below in the past, the only issue with that is if you have 
side effects in parent’s dispatch you don’t want executed but you would also 
run that risk if you had an initialize() method work flow; in the end I find 
dispatch() is enough in my experience. 

def dispatch(self, request, *args, **kwargs):
parent_dispatch_return = super(Class, self).dispatch(request, *args, 
**kwargs)
...my code based on values based on the super call...
return parent_dispatch_return
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Daniel Sokolowski
http://webdesign.danols.com/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Alex Ogier]

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 8:48 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:

>   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
> http-method-independent code
>
> That pattern has nasty side-effects.  It can be used in some cases but it
> fails in most.
>
> On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote:
>>
>>   I’ve done the below in the past, the only issue with that is if you
>> have side effects in parent’s dispatch you don’t want executed but you
>> would also run that risk if you had an initialize() method work flow; in
>> the end I find dispatch() is enough in my experience.
>>
>> def dispatch(self, request, *args, **kwargs):
>> parent_dispatch_return = super(Class, self).dispatch(request, *args,
>> **kwargs)
>> ...my code based on values based on the super call...
>> return parent_dispatch_return
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

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 http-method-independent code

That pattern has nasty side-effects.  It can be used in some cases but it fails 
in most.

On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote: 
  I’ve done the below in the past, the only issue with that is if you have side 
effects in parent’s dispatch you don’t want executed but you would also run 
that risk if you had an initialize() method work flow; in the end I find 
dispatch() is enough in my experience. 

  def dispatch(self, request, *args, **kwargs):
  parent_dispatch_return = super(Class, self).dispatch(request, *args, 
**kwargs)
  ...my code based on values based on the super call...
  return parent_dispatch_return

  From: Jordan Hagan 
  Sent: Friday, November 09, 2012 12:37 AM
  To: django-d...@googlegroups.com 
  Subject: Re: Class based views: A standard hook for http-method-independent 
code

  Hey Russ, 

  The main point of concern which I think you may be missing is that 
self.kwargs and self.args are set inside dispatch, so using other mixins that 
require self.kwargs and self.args to be set (most do) will not work, without 
doing:

  def dispatch(self, request, *args, **kwargs):
  self.args = args;
  self.kwargs = kwargs
  self.init()
  return super(Class, self).dispatch(request, *args, **kwargs)

  Which isn't very tidy, to me having self.args and self.kwargs be set twice 
(once in my overridden dispatch method, and once in the original dispatch) 
feels wrong. I can't give you a good reason for it, it just feels bad every 
time I do it. The only way to work around this is to override dispatch without 
calling the original, and essentially duplicate the original dispatch method 
with an init call added in.

  Cheers,
  Jordan

  On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee  
wrote:




On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam  wrote:

  Without setting request, args, and kwargs on on the view instance (which 
is done during the base dispatch view), anything in the view that assumes these 
values are present cannot run.   

  Most of my views end up with functions which retrieve an object and then 
do some basic validation to ensure that a user has permissions, or that the 
object is valid in some fashion, or that some set of conditions is met prior to 
allowing any method call to happen.  

  I have found that without this init method, the vast majority of my views 
end up re-writing dispatch which includes the super call.  This is especially 
annoying when you have to compare some aspect of the requesting user with an 
object that must be looked up with something from args or kwargs.  My view 
often already has this machinery built in, but it can't function without 
dispatch setting request, args, and kwargs, so to accomplish my check, I have 
to duplicate the lookup code in my dispatch method.

  I don't propose mine is the best solution, but I know that it is 
non-intrusive, simple, and covers my use cases well.  It is also simple to 
accomplish any number of things since `init` merely needs to return a falsy 
value to allow the request to pass on through, raise an exception if that type 
of failure is desired, or return a response of it wants to hijack the view 
entirely.



I'm starting to feel like I'm incredibly dense, because I still don't 
understand what your use case *is* - or, at least, why what your proposing 
provides any significant advantages over what you can do using basic Python 
inheritance techniques.

Specifically, I still can't see why:

class MyView(View):
def  dispatch(self, request, *args, **kwargs):
init()
return super(MyView, self).dispatch(request, *args, **kwargs)

def init():
# your init logic here

is superior to the solution provided by using basic Python inheritance:

class MyView(View):
def  dispatch(self, request, *args, **kwargs):
# your init logic here
return super(MyView, self).dispatch(request, *args, **kwargs)

You have exactly the same workflow, and exactly the same order of 
operations. You don't need to document any special CBV-specific API -- e.g., 
when/how init() will be invoked, and with what assumptions about the request 
environment can be made -- and you don't have to incur the overhead of a 
function call (ok - the overhead is tiny, but let's not pretend it's zero).

So - can someone explain to me what the advantage is? Why is this init() 
method needed?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django 

Re: #16779 - a tutorial for first time Django contributors

[Tim Graham]

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: 
>
> >Any specific feedback on this paragraph, or the tutorial as whole, would 
> be 
> >appreciated: 
>
> My four thoughts: 
>
> Firstly: I like to see things like: 
>
> ./runtests.py --settings=test_sqlite 
>
> include a comment when appropriate; in this case to say why we are using 
> --settings=test_sqlite 
>
> Secondly: "For advanced users who wish to use virtualenv" - is this really 
> implying that only advanced users would use virtualenv? 
>
> I think that the most helpful thing to say to people who are not using 
> virtualenv already is that they need spend 15 minutes learning to use it 
> before they do anything else, because it's one of the most valuable and 
> easy to learn tools they will ever encounter. 
>
> Thirdly: if everyone is using virtualenv, would that eliminate the 
> difficulties trying to explain PYTHONPATH? 
>
> Fourthly: although this and the Working with Git and GitHub tutorial 
> explain the technical part of the process well, they both somewhat assume 
> that you're able to come up with complete if not perfect patch. 
>
> In reality I think a lot of back-and-forth refinement goes on before that 
> point is reached - what would be handy is advice on how to proceed when 
> your patch is incomplete and you need some feedback before going further. 
>
> But this looks great, I wish I had read it myself before trying to submit 
> anything. 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/fRCPN4aoma4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.