Op 9 nov. 2012, om 07:05 heeft Russell Keith-Magee het volgende geschreven:

> What I don't understand is why the need for an init() method isn't being 
> challenged in the first place. 
> 
> Why on earth can't just just take the logic that you're putting in init(), 
> and put it *in dispatch()*. The sequence of calls is *identical*, and since 
> *args and **kwargs are locals, they don't need to be set anywhere. What's the 
> problem with putting the init() logic in the dispatch() method in the way I 
> described?
> 

It has to do with the order of execution, the derived class always runs first.
When a permission check is in dispatch(), anything that overrides dispatch() 
runs before the permission check.
The same also applies to any other initialization code, a derived class can 
never build on top of that because it should call


Please allow me to paraphrase my previous explanation 
(https://groups.google.com/d/msg/django-developers/7c7aI-slGNc/a-DYFrIM3ZgJ)


What is the problem with overriding dispatch()?
When overriding dispatch(), get() or post() the flow is always:

def dispatch(self, request, *args, **kwargs):
    # my code here.
    return super(…).dispatch(request, *args, **kwargs)

The same also applies to get() and post().
In other words, the last deriving class on top of the inheritance chain is 
always initializing first before it's base classes.
It can't rely on a base class to do some initialization.

With our permission check in the base class' dispatch() method, anything 
deriving from that effectively
couldn't override dispatch() anymore because that would run before the 
permission check.

How does the init method fix this?
By doing a self.init() in the top-most dispatch() method, each class in the 
inheritance chain has a chance to fetch the objects it needs to have.

That code can be written as:

def init(self):
    super(..).init()
    # my code here.

Now, the base class can initialize, then the deriving class.
With a larger inheritance chain, this behavior becomes crucial.
Each class can build upon what the other has prepared already.



Greetings,

Diederik

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

Reply via email to