you might want to implement something similar to what apache2 did with
their hooks.
it sounds pretty complex, but in reality you hardly need to use all the options.
1. define when the middle ware will be run .. FIRST, MIDDLE, or LAST.
2. define which middleware has to run before and which has to run afterwards
eg.. this is how I would set up a 'hook' in apache which will run
before proxy and after rewrite.
static const char * const aszPreCheck[] = { "mod_rewrite.c", NULL };
static const char * const aszPost[] = { "mod_proxy.c", NULL };
ap_hook_translate_name(check_ontology,aszPreCheck,aszPost,APR_HOOK_FIRST);
regards
ian
On 11/15/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Hey folks --
>
> As some have pointed out in the past, there are some potential
> pitfalls in the current way the middleware API works. As it stands
> now, MIDDLEWARE_CLASSES is implemented as a stack: the middleware
> bits are called in order on the process_request and process_view
> phases, and in reverse order on the process_response and
> process_exception phases.
>
> The idea behind this was that if you wanted to do something really
> low-level like munging the request/response objects, you'd usually
> want to be the first request middleware and the last response
> middleware. I really didn't want to have to define an order for both
> request and response (let alone all four phases).
>
> With more middleware being written, however, people are running into
> problems with middleware ordering. Frankly, I hadn't excepted that
> the middleware API would be used that much at all, but it's proven to
> be pretty useful. Given that we're trying to nail down all our APIs
> for a 1.0 release, I think it's time to make any changes to the
> middleware API that we need to make.
>
> As I see it, there are three problems (two major, one minor) with the
> current setup:
>
> 1. There's no way to set the order of the response middleware without
> changing the order of the request middleware. So if you've got a
> middleware that needs to be the first on both request and response,
> you're screwed.
>
> 2. Any of the phases are allowed to return an HttpResponse object
> which short-circuits the rest of the middleware phases. This means
> that a middleware component that returns a HttpResponse in
> process_request will prevent any response middleware from being used.
>
> 3. The config directive seems rather verbose
> ("django.middleware.cache.CacheMiddleware") -- this isn't a big deal,
> but if it's fixable, that would be wonderful.
>
> This email has been sitting in my drafts folder for a week while I
> try to think of a good, clean fix, and apparently I'm not smart
> enough... So, anyone have any ideas?
>
> Jacob
>
--
[EMAIL PROTECTED] -- ++61-3-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti
