>
> To avoid the problems with the bad interaction with the request machinery,
> another approach that came to mind would be to allow inserting / including
> a function at any point in the URLconf. The function would return whether
> the pattern should be skipped or claimed. That would have the advantage of
> taking place before any view is started.


One can already do this by reaching a little into the internals... but I'm
also not sure it's a good idea.

You can do it like so:

from functools import partial

from django.urls.conf import _path
from django.urls.resolvers import RoutePattern


class FilteringRoutePattern(RoutePattern):
    def match(self, path):
        matched = super().match(path)
        if matched and my_other_logic():
            matched = None
        return matched

filtering_path = partial(_path, Pattern=FilteringRoutePattern)

I tried it with my_other_logic() doing random.choice([True, False]) and it
works.

On Fri, 7 May 2021 at 17:48, Florian Apolloner <f.apollo...@gmail.com>
wrote:

> Hi Chris,
>
> nice hearing from you.
>
> On Friday, May 7, 2021 at 6:20:44 PM UTC+2 chris.j...@gmail.com wrote:
>
>> With the suggested work-around of having a view call other views, would a
>> view be able to continue URL resolution in that case?
>>
>
> Not without many code changes I fear and I am not sure about the gains.
>
>
>> To avoid the problems with the bad interaction with the request
>> machinery, another approach that came to mind would be to allow inserting /
>> including a function at any point in the URLconf. The function would return
>> whether the pattern should be skipped or claimed. That would have the
>> advantage of taking place before any view is started.
>>
>
> I'll put it like this: Interesting idea but I am afraid of the outcome :D
> Before I'd support such a change we'd really want to gather usecases first
> and think hard what it could/would break… And now I cannot stop thinking
> about such a function ala "lambda: random.choice([True, False])". Thank you
> for that ;)
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0c72e667-0223-4a28-8e4f-83c5d0f3c758n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0c72e667-0223-4a28-8e4f-83c5d0f3c758n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3uuhf%3DSDyYObZptzXZ%3D1fgKAWp1kV2UifBV3QpJdwdtQ%40mail.gmail.com.
    • ... Tidiane Dia
      • ... Tidiane Dia
  • Re:... Florian Apolloner
    • ... Tidiane Dia
      • ... Florian Apolloner
        • ... Tidiane Dia
          • ... 'Adam Johnson' via Django developers (Contributions to Django itself)
            • ... Florian Apolloner
        • ... chris.j...@gmail.com
          • ... Florian Apolloner
            • ... 'Adam Johnson' via Django developers (Contributions to Django itself)

Reply via email to