middleware specific to a app

Using Django Forms & APIs
1

hi there
i dont know if this is the best place for ask

but is there any feature that we set middlware just for an app ?
i know that the middlware already can do this by checking the url in the incoming request but i dont think this is the best, specially for projects that has many urls and routes

thanks

2

Welcome @arminshfatemi !

No.

Middleware acts outside the “app” structure by referencing the request before it goes through the URL resolution to a view.

Actually, it cannot. You cannot assume that any particular url is being handled by a specific app - if for no other reason than that it’s possible for other middleware to redirect the request.

3

You kinda can. Checking for resolver_match.app_name/namespace is actually a good indicator and if you do it in process_view and put your middleware last there is also not really much of a chance that something else redirects…

4

Agreed in the general case - IFF you’re talking about a situation where you are in control of the complete project.

But it’s the last part of that second sentence where I’ve seen the most exceptions.

e.g:

def view_1(request):
  if some_condition:
    response = view_2(request)
  else:
    response = view_3(request)
  return response

(Admittedly, I don’t think we’ve ever done that with different apps, but we have done that within an app. But this would work exactly the same way across different apps.)

Now, I do acknowledge that this raises a valid question as to whether or not the request is being “handled” by “app b” if it is being called this way - at least as far as the OP’s original intent.

I also acknowledge that this is an odd edge-case - and again, preventable if you’re in control of the entire project. But this is also one of those types of situations that might work now - and ends up failing a year from now when someone else adds a view like the above.

5

shrug even with your view_1 example I’d argue that the app that has view_1 is the one “handling” the view for most intents and purpose. Following your analogy further an example like (completely made up):

def view_1(request):
   return GenericView.as_view(...)(request)

would mean that Django’s generic views “app” is the handler. In the end it comes down to splitting hairs and I think it is more helpful to answer/help with an example that covers 99% of the cases (and maybe a sidenote that it is not 100% fool proof) instead of categorically ruling it out. Especially since we don’t know the intent of the author. Maybe they are just looking for a way to easily provide a “decorator” for all their views in their app (admittedly a middleware wouldn’t be the best choice then). But even in that case asking “in which context are you trying to use this” might get us further than flatout rejection.

1 Like
6

Agreed - that would have been a better response in this situation. But I’m still not sure where I could see recommending any type of “middleware on a per-app basis” as a solution to a requirement.

7

thanks for the response

thanks for clarification
possible to request this feature somewhere ?

my situation is where if i dont use middlware based on apps, i need to decorate every view for it for them.

8

What specifically are you looking for this middleware to do?

9

I don’t think it would have much of a chance.

You could loop over the list of urlpatterns in your app and apply the decorator in urls.py directly. But as @KenWhitesell asked: What is this decorator/middleware supposed to do? Maybe there are other solutions that would work better.

10

thanks @apollo13 @KenWhitesell
i almsot solve the problem and dont need it any more

i was need to log every incoming request to the urls in that app, and do some special logic for every incoming request for that app
but because the start of the urls of the app were not the same and dont start like each other it was hard to use the simple middleware

but for now solve it.