django.urls verktygsfunktioner

omvänd()`

Funktionen reverse() kan användas för att returnera en absolut sökvägsreferens för en given vy och valfria parametrar, på liknande sätt som taggen url:

reverse(viewname, urlconf=None, args=None, kwargs=None, current_app=None, *, query=None, fragment=None)[source]

viewname kan vara ett URL-mönsternamn eller det anropsbara vyobjekt som används i URLconf. Till exempel:, med följande url:

from news import views

path("archive/", views.archive, name="news-archive")

kan du använda något av följande för att vända URL:en:

# using the named URL
reverse("news-archive")

# passing a callable object
# (This is discouraged because you can't reverse namespaced views this way.)
from news import views

reverse(views.archive)

Om URL:en accepterar argument kan du skicka dem i args. Till exempel:

from django.urls import reverse


def myview(request):
    return HttpResponseRedirect(reverse("arch-summary", args=[1945]))

Du kan också skicka kwargs i stället för args. Till exempel:

>>> reverse("admin:app_list", kwargs={"app_label": "auth"})
'/admin/auth/'

args och kwargs kan inte skickas till reverse() samtidigt.

Om ingen matchning kan göras, ger reverse() upphov till ett NoReverseMatch undantag.

Funktionen reverse() kan vända ett stort antal reguljära uttrycksmönster för webbadresser, men inte alla möjliga. Den största begränsningen för närvarande är att mönstret inte kan innehålla alternativa val med hjälp av det vertikala strecket ("|"). Du kan mycket väl använda sådana mönster för att matcha mot inkommande webbadresser och skicka dem till visningar, men du kan inte vända sådana mönster.

Med argumentet current_app kan du ge en ledtråd till resolvern som anger vilken applikation den vy som körs för tillfället tillhör. Detta current_app-argument används som en ledtråd för att lösa upp applikationsnamnrymder till URL:er på specifika applikationsinstanser, enligt :ref:namespaced URL resolution strategy <topics-http-reversing-url-namespaces>.

Argumentet urlconf är URLconf-modulen som innehåller de URL-mönster som ska användas för reversering. Som standard används rot-URLconf för den aktuella tråden.

Nyckelordsargumentet query anger parametrar som ska läggas till i den returnerade URL:en. Det kan acceptera en instans av QueryDict (t.ex. request.GET) eller ett värde som är kompatibelt med urllib.parse.urlencode(). Den kodade frågesträngen läggs till den upplösta URL:en, med en ? som prefix.

Nyckelordsargumentet fragment anger en fragmentidentifierare som ska läggas till i den returnerade URL:en (dvs. efter sökvägen och frågesträngen, föregånget av #).

Till exempel:

>>> from django.urls import reverse
>>> reverse("admin:index", query={"q": "biscuits", "page": 2}, fragment="results")
'/admin/?q=biscuits&page=2#results'
>>> reverse("admin:index", query=[("color", "blue"), ("color", 1), ("none", None)])
'/admin/?color=blue&color=1&none=None'
>>> reverse("admin:index", query={"has empty spaces": "also has empty spaces!"})
'/admin/?has+empty+spaces=also+has+empty+spaces%21'
>>> reverse("admin:index", fragment="no encoding is done")
'/admin/#no encoding is done'

Changed in Django 5.2:

Argumenten query och fragment har lagts till.

Observera

Den sträng som returneras av reverse() är redan urlquoted. Till exempel:

>>> reverse("cities", args=["Orléans"])
'.../Orl%C3%A9ans/'

Att tillämpa ytterligare kodning (t.ex. urllib.parse.quote()) på utdata från reverse() kan ge oönskade resultat.

Omvända klassbaserade åsikter genom att visa objekt

View-objektet kan också vara resultatet av anropet as_view() om samma view-objekt används i URLConf. I enlighet med det ursprungliga exemplet kan vyobjektet definieras som:

nyheter/views.py

 from django.views import View


 class ArchiveView(View): ...


 archive = ArchiveView.as_view()

Kom dock ihåg att namespaced-vyer inte kan vändas av view-objekt.

omvänd_lazy()

En lättsamt utvärderad version av reverse().

reverse_lazy(viewname, urlconf=None, args=None, kwargs=None, current_app=None, *, query=None, fragment=None)

Den är användbar när du behöver använda en URL-reversering innan projektets URLConf har laddats. Några vanliga fall där denna funktion är nödvändig är:

• tillhandahålla en omvänd URL som url-attribut för en generisk klassbaserad vy.

• tillhandahålla en omvänd URL till en dekorator (t.ex. argumentet login_url för dekoratorn django.contrib.auth.decorators.permission_required()).

• tillhandahålla en omvänd URL som standardvärde för en parameter i en funktions signatur.

Changed in Django 5.2:

Argumenten query och fragment har lagts till.

resolve()`

Funktionen resolve() kan användas för att lösa upp URL-sökvägar till motsvarande vyfunktioner. Den har följande signatur:

resolve(path, urlconf=None)[source]

path är den URL-sökväg du vill lösa. Precis som med reverse() behöver du inte oroa dig för parametern urlconf. Funktionen returnerar ett ResolverMatch-objekt som gör att du kan komma åt olika metadata om den upplösta URL:en.

Om URL:en inte kan lösas, ger funktionen upphov till ett Resolver404-undantag (en underklass till Http404) .

class ResolverMatch[source]

func

Den vyfunktion som ska användas för att betjäna URL:en

args

De argument som ska skickas till view-funktionen, som de tolkats från URL:en.

kwargs

Alla nyckelordsargument som ska skickas till vyfunktionen, dvs captured_kwargs och extra_kwargs.

captured_kwargs

De fångade nyckelordsargument som skulle skickas till visningsfunktionen, som de tolkats från URL:en.

extra_kwargs

De ytterligare nyckelordsargument som ska skickas till view-funktionen.

url_name

Namnet på det URL-mönster som matchar URL:en.

route

Rutten för det matchande URL-mönstret.

Om till exempel path('users/<id>/', ...) är det matchande mönstret kommer route att innehålla 'users/<id>/'.

tried

Listan över URL-mönster som provades innan URL:en antingen matchade ett eller uttömde tillgängliga mönster.

app_name

Applikationens namnrymd för det URL-mönster som matchar URL:en.

app_names

Listan över enskilda namnrymdskomponenter i hela applikationens namnrymd för det URL-mönster som matchar URL:en. Om t.ex. app_name är 'foo:bar, kommer app_names att vara ['foo', 'bar'].

namespace

Instansnamnrymden för det URL-mönster som matchar URL:en.

namespaces

Listan över enskilda namnrymdskomponenter i den fullständiga instansens namnrymd för det URL-mönster som matchar URL:en. dvs. om namnrymden är foo:bar kommer namnrymderna att vara ['foo', 'bar'].

view_name

Namnet på den vy som matchar URL:en, inklusive namnrymden om det finns en sådan.

Ett ResolverMatch-objekt kan sedan förfrågas för att ge information om det URL-mönster som matchar en URL:

# Resolve a URL
match = resolve("/some/path/")
# Print the URL pattern that matches the URL
print(match.url_name)

Ett ResolverMatch-objekt kan också tilldelas en trippel:

func, args, kwargs = resolve("/some/path/")

En möjlig användning av resolve() skulle vara att testa om en vy skulle ge upphov till ett Http404-fel innan den omdirigeras till den:

from urllib.parse import urlsplit
from django.urls import resolve
from django.http import Http404, HttpResponseRedirect


def myview(request):
    next = request.META.get("HTTP_REFERER", None) or "/"
    response = HttpResponseRedirect(next)

    # modify the request and response as required, e.g. change locale
    # and set corresponding locale cookie

    view, args, kwargs = resolve(urlsplit(next).path)
    kwargs["request"] = request
    try:
        view(*args, **kwargs)
    except Http404:
        return HttpResponseRedirect("/")
    return response

get_script_prefix()

get_script_prefix()[source]

Normalt bör du alltid använda reverse() för att definiera webbadresser i din applikation. Men om din applikation konstruerar en del av URL-hierarkin själv, kan du ibland behöva generera webbadresser. I så fall måste du kunna hitta bas-URL:en för Django-projektet i dess webbserver (normalt tar reverse() hand om detta åt dig). I så fall kan du anropa get_script_prefix(), som returnerar skriptprefixdelen av URL:en för ditt Django-projekt. Om ditt Django-projekt ligger i roten på webbservern är detta alltid "/".

Varning

Denna funktion kan inte** användas utanför request-response-cykeln eftersom den förlitar sig på värden som initieras under den cykeln.