9 ms·

This won't work since the request is not yet available when the callback is set up.

• Demiurge 9y ago
  correct
• kerkeslager 9y ago
  Yeah, that's why I said I wasn't sure of the context. :) I guess the middleware suggestion someone else posted is probably the idiomatic Django way, then. In general this is why I don't like the direction Django is going. The Python idiom for this would be to create the callback as a closure after the request is available, and then pass it into the library function that calls the callback. I suspect you might still be able to do this, but you'd have to use a function-based view, and that's no longer idiomatic Django. It seems like what Django folks want is to write a configuration markup language that is a subset of Python classes and not actually ever write any function bodies. The problem with this approach is that you're limited to the configuration points the framework gives you (in this case, the arguments passed to the callback). They can give you workarounds (i.e. middleware) but this is still fairly hacky. It would be better, IMHO, to stick with function-based views and provide library functions to do what the framework does, which can be called through function-based views in a way that's idiomatic with the host language. But Django has gone too far down this path to change now, so I guess I just have to accept it. :)