On 5/16/18 10:49 AM, Florian Apolloner wrote:
> Hi Carl,
>
> On Wednesday, May 16, 2018 at 5:58:02 AM UTC+2, Carl Meyer wrote:
>
> I'm not sure this part is feasible. It's an intentional part of
> middleware design AFAIK (and useful) that middleware can modify
> request.path and have
I'm also in favour of simplifying away process_view . And having worked
with a multi-domain site that altered request.urlconf in a middleware, I
know the problems it can bring.
Carl's point about modifying request.path is interesting - if we're looking
to allow modifying it in the resolver step bu
Hi Carl,
On Wednesday, May 16, 2018 at 5:58:02 AM UTC+2, Carl Meyer wrote:
>
> I'm not sure this part is feasible. It's an intentional part of
> middleware design AFAIK (and useful) that middleware can modify
> request.path and have this modification respected in view resolution.
>
my proposed
Hi Florian,
On 5/12/18 10:22 AM, Florian Apolloner wrote:
> After refactoring the middlewares to new-style middlewares as we have them
> now, I am left with two pain points:
>
> * atomic requests are still special cased and not in a middleware
> * process_view is as useless as always (it can
Hi there,
After refactoring the middlewares to new-style middlewares as we have them now,
I am left with two pain points:
* atomic requests are still special cased and not in a middleware
* process_view is as useless as always (it can neither alter nor convert
args/kwargs or the view)
To c
