On Thu, Mar 28, 2013 at 10:28 PM, meric <meric...@gmail.com> wrote: > > Michael: How does the middleware work with other URLs that do not need to > have fallthrough? Do you have to add them to excluded_path_patterns? > Would like a more general description of how it works. >
A ContentMiddleware behaves basically the same as a standard 404 middleware. If no other middleware or view handles the request, then a ContentMiddleware will get a chance to match during the process_response phase. Most of these middleware are a shim to a view function, but some include logic to make faster (than the view) determinations about the user, type of asset, the request, and whether or not the underlying views could possibly handle request. Most of our content is subject to record level authorization checks that result in heavy queries and reducing response time was one of the main goals of this implementation. There are three possible types of matches that can happen for a middleware and a request; an explicit match, an explicit miss, and an implicit match. An explicit miss only happens when the middleware's process() raises Http404. An explicit match is when a response is returned, either of the ContentHandled exceptions are raised, or a permission error is raised. The ContentHandled exceptions allow the implementing middleware to pass back knowledge of owned URL spaces or assets that could exist at some point in the future. For our site, when a permission check fails, it means the assets exists. The implicit matching happens on all other exceptions. The type of match dictates how long to cache the knowledge about whether or not the request was handled by the middleware. Each middleware dictates what it means for it to match and this is often more than just the URL pattern. During the middleware process_request phase, any previously matched request is immediately processed by the middleware. This short circuits the URL dispatcher and reduces the overall response time for handling the request. On our system, users are able to arbitrarily place assets in the URL structure and these often overlap with the URL patterns of our views. Some of the overlapped views have heavy look ups that could take a few hundred ms before finding out it is and probably always will be a 404. The excluded_path_patterns provides an easy way of explicitly missing based upon the URL without needing to check the database. This also yields a faster response time by avoiding any lookups when the middleware attempts to determine "is this mine" for a new request. We also use excluded_path_patterns to help enforce business rules about the URL space where assets may reside. The example ManualPageMiddleware explicitly prevents any static pages from being found under our image folder. The underlying ManualPage model is generic and has no such restrictions for its URL. Also, couldn't the caching logic, (ignoring fallthrough urls for a minute), > be implemented in a view decorator (which is also what how we do it)? > Basic caching logic could be worked in to a view decorator, but it will not provide responses as quickly as my middleware. The decorated views would be processed in order and you could end up with a request chasing just behind expiring cache entries and having to recheck them all. My middleware is able to check the "is this handled" cache for all of the middleware before needing to go through the URL dispatcher and then trying each of the middleware. You could probably get similar behavior with a decorator wrapping several entries in urls, but it would be a bit ugly and less flexible with cache timeouts. Regards, Michael Manfre -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
