Um esquema de URL elegante e limpo, é um detalhes importante em uma aplicação Web de alta quailidade, O Django deixa que você especifique URLs como queira, sem limitações do “framework”.
\nNão requer .php ou .cgi, e certamente nada de nonsense 0,2097,1-1-1928,00.
Veja o Cool URIs don’t change, por Tim Berners-Lee criador da World Wide Web, para argumentos excelentes sobre porque URLs devem ser limpas e usáveis.
\nTo design URLs for an app, you create a Python module informally called a\nURLconf (URL configuration). This module is pure Python code and is a\nmapping between URL path expressions to Python functions (your views).
\nEste mapemaneto pode ser tão curto ou tão longo quanto necessário. Pode referenciar outros mapeamentos. E, porque é código Python puro, pode ser construído dinamicamente.
\nO Django também fornece uma maneira de traduzir URLs de acordo com a língua ativa. Veja o documentação de internacionaliação para mais finromação.
\nQuando um usuário requisita uma página do seu site feito em Django, este é o algoritmo que o sistema segue para determinar qual código Python executar:
\nO Django determina o módulo URLConf raiz a ser usado. Ordinariamente, este é o valor da definição do ROOT_URLCONF, mas se o objeto HttpRequest que está chegando tem um atributo urlconf (definido pelo “middleware”), o valor definido por ele será usado no lugar da definição do ROOT_URLCONF.
Django loads that Python module and looks for the variable\nurlpatterns. This should be a Python list of django.urls.path()\nand/or django.urls.re_path() instances.
O Django passa por cada padrão de URL definido, na ordem, e para na primieira que combina com a URL requisitada.
Once one of the URL patterns matches, Django imports and calls the given\nview, which is a simple Python function (or a class-based view). The view gets passed the following\narguments:
\nUma instância do HttpRequest.
If the matched URL pattern returned no named groups, then the\nmatches from the regular expression are provided as positional arguments.
The keyword arguments are made up of any named parts matched by the\npath expression, overridden by any arguments specified in the optional\nkwargs argument to django.urls.path() or\ndjango.urls.re_path().
If no URL pattern matches, or if an exception is raised during any\npoint in this process, Django invokes an appropriate\nerror-handling view. See Error handling below.
Aqui um exemplo de URLconf:
\nfrom django.urls import path\n\nfrom . import views\n\nurlpatterns = [\n path('articles/2003/', views.special_case_2003),\n path('articles/<int:year>/', views.year_archive),\n path('articles/<int:year>/<int:month>/', views.month_archive),\n path('articles/<int:year>/<int:month>/<slug:slug>/', views.article_detail),\n]\nNotas:
\nTo capture a value from the URL, use angle brackets.
Captured values can optionally include a converter type. For example, use\n<int:name> to capture an integer parameter. If a converter isn’t included,\nany string, excluding a / character, is matched.
There’s no need to add a leading slash, because every URL has that. For\nexample, it’s articles, not /articles.
Requisições de exemplo:
\nA request to /articles/2005/03/ would match the third entry in the\nlist. Django would call the function\nviews.month_archive(request, year=2005, month=3).
/articles/2003/ deve combinar com o primeiro padrão de formatp na lista, não o segundo, porque os padrões são testado em ordem, e o primeiro é o que primeiro atende ao padrão. Sinta-se livre para explorar a ordem e inserir casos especiais como este. Aqui, o Django deve chamar a função views.special_case_2003(request)
/articles/2003 não deve combinar com nenhum destes padrões, porque cada padrão de formato requer que a URL termine com uma barra.
/articles/2003/03/building-a-django-site/ would match the final\npattern. Django would call the function\nviews.article_detail(request, year=2003, month=3, slug="building-a-django-site").
The following path converters are available by default:
\nstr - Matches any non-empty string, excluding the path separator, '/'.\nThis is the default if a converter isn’t included in the expression.
int - Matches zero or any positive integer. Returns an int.
slug - Matches any slug string consisting of ASCII letters or numbers,\nplus the hyphen and underscore characters. For example,\nbuilding-your-1st-django-site.
uuid - Matches a formatted UUID. To prevent multiple URLs from mapping to\nthe same page, dashes must be included and letters must be lowercase. For\nexample, 075194d3-6885-417e-a8a8-6c931e272f00. Returns a\nUUID instance.
path - Matches any non-empty string, including the path separator,\n'/'. This allows you to match against a complete URL path rather than\njust a segment of a URL path as with str.
For more complex matching requirements, you can define your own path converters.
\nA converter is a class that includes the following:
\nA regex class attribute, as a string.
A to_python(self, value) method, which handles converting the matched\nstring into the type that should be passed to the view function. It should\nraise ValueError if it can’t convert the given value.
A to_url(self, value) method, which handles converting the Python type\ninto a string to be used in the URL.
Por exemplo:
\nclass FourDigitYearConverter:\n regex = '[0-9]{4}'\n\n def to_python(self, value):\n return int(value)\n\n def to_url(self, value):\n return '%04d' % value\nRegister custom converter classes in your URLconf using\nregister_converter():
from django.urls import path, register_converter\n\nfrom . import converters, views\n\nregister_converter(converters.FourDigitYearConverter, 'yyyy')\n\nurlpatterns = [\n path('articles/2003/', views.special_case_2003),\n path('articles/<yyyy:year>/', views.year_archive),\n ...\n]\nIf the paths and converters syntax isn’t sufficient for defining your URL\npatterns, you can also use regular expressions. To do so, use\nre_path() instead of path().
In Python regular expressions, the syntax for named regular expression groups\nis (?P<name>pattern), where name is the name of the group and\npattern is some pattern to match.
Here’s the example URLconf from earlier, rewritten using regular expressions:
\nfrom django.urls import path, re_path\n\nfrom . import views\n\nurlpatterns = [\n path('articles/2003/', views.special_case_2003),\n re_path(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),\n re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive),\n re_path(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<slug>[\\w-]+)/$', views.article_detail),\n]\nThis accomplishes roughly the same thing as the previous example, except:
\nThe exact URLs that will match are slightly more constrained. For example,\nthe year 10000 will no longer match since the year integers are constrained\nto be exactly four digits long.
Each captured argument is sent to the view as a string, regardless of what\nsort of match the regular expression makes.
When switching from using path() to\nre_path() or vice versa, it’s particularly important to be\naware that the type of the view arguments may change, and so you may need to\nadapt your views.
As well as the named group syntax, e.g. (?P<year>[0-9]{4}), you can\nalso use the shorter unnamed group, e.g. ([0-9]{4}).
This usage isn’t particularly recommended as it makes it easier to accidentally\nintroduce errors between the intended meaning of a match and the arguments\nof the view.
\nIn either case, using only one style within a given regex is recommended. When\nboth styles are mixed, any unnamed groups are ignored and only named groups are\npassed to the view function.
\nExpressões regulares permitem argumentos aninhados, e o Django irá resolvê-los e passá-los para a “view”. Quando usar o “reverse”, o Django tentará preencher todos os argumentos capturados fora, ignorando qualquer argumento aninhado capturado. Considere o seguinte padrão de URL o qual opcionalmente pega um arumento “page”:
\nfrom django.urls import re_path\n\nurlpatterns = [\n re_path(r'^blog/(page-(\\d+)/)?$', blog_articles), # bad\n re_path(r'^comments/(?:page-(?P<page_number>\\d+)/)?$', comments), # good\n]\nAmbos os padrões usam argumento aninhados e irão resolver: por exemplo, blog/page-2/ irá resultar em na combinação com blog_articles com dois argumentos posicionais: page-2/ e 2. O segundo padrão para comments irá encontrar comments/page-2/ com argumento nomeado page_number definido como 2. O argumento mais externo neste caso é um argumento não capturado (?:...).
A “view” blog_articles precisa do argumento mais externo para que seja possível acessá-la de maneira reversa, neste caso page-2/ ou nenhum argumento , enquanto ue comments pode ser acessado reversamente com argumento nenhum ou com um valor para page_number.
Argumentos aninhados criam um acomplamento forte entre os argumentos da “view” e sua URL como ilustrado pelo blog_articles: a “view” recebe parte da URL (``page-2/”) ao invés de somente o valor que a “view” está interessada. Este acoplamento é ainda mais evidente quando acessando reversamente, já que para acessá-la reversamente precisa passar uma parte da URL ao invés de somente o número da página.
Como regra geral, apenas capturar os valores que a “view” precisa para funcionar e usar argumentos não capturáveis quando a expressão regurlar precisar de um argumento mas que a “view” o ignora.
\nO URLconf procura na URL requisitada, como uma string Python normal. Isso não inclui parâmetros GET ou POST, ou o nome do domínio.
\nPor exemplo em uma requisição para https://www.example.com/myapp/, o URLconf irá olhar para myapp/.
Em uma requisição para https://www.example.com/myapp/?page=3, o URLconf irá olhar para myapp/.
O URLconf nÃo olha para o método da requisição. Em outras palavras, todas os métodos de requisições – POST, GET, HEAD, etc. – serão roteados para a mesma função para a mesma URL.
Uma truque conveniente é especificar parâmetros padrão para seus argumentos de “views”. Aqui um exemplo de URLconf e “view”:
\n# URLconf\nfrom django.urls import path\n\nfrom . import views\n\nurlpatterns = [\n path('blog/', views.page),\n path('blog/page<int:num>/', views.page),\n]\n\n# View (in blog/views.py)\ndef page(request, num=1):\n # Output the appropriate page of blog entries, according to num.\n ...\nIn the above example, both URL patterns point to the same view –\nviews.page – but the first pattern doesn’t capture anything from the\nURL. If the first pattern matches, the page() function will use its\ndefault argument for num, 1. If the second pattern matches,\npage() will use whatever num value was captured.
Cada empressão regular dentro do urlpatterns é compilada na primeira vez que é acessad. Isso torna o sistema tremendamente rápido.
urlpatternsLink para este cabeçalho#urlpatterns should be a Python list of path() and/or\nre_path() instances.
When Django can’t find a match for the requested URL, or when an exception is\nraised, Django invokes an error-handling view.
\nAs “views” para usar nestes casos são especificadas por quatro variáveis. O valor padrão destas variáveis deve bastar para a maioria dos projetos, mas uma maior persoanlização é possível sobrescrevendo seus valores padrão.
\nVeja a documentação em Personalizando “views” de erros para detalhes completos.
\nTais valores podem ser definidos dentro do sey URLconf raiz. Definir estes valores em qualquer outro URLconf não irá ter nenhum efeito.
\nOs valores devm ser “executáveis”, ou strings que representam o caminho Python completo para a “view” que deve ser chamada para lidar com o condição de erro.
\nAs variáveis são:
\nhandler400 – Veja django.conf.urls.handler400.
handler403 – Veja django.conf.urls.handler403.
handler404 – Veja django.conf.urls.handler404.
handler500 – Veja django.conf.urls.handler500.
Em qualquer ponto, seus ``urlpatterns``podem “inluir” outros módulos URLconf. Isso essencialmente enraiza um conjunto de URLs embaixo de outros.
\nPor exemplo, aqui um enxerto de URLconf para o próprio Django website. Isso inclui várias outras URLconfs:
\nfrom django.urls import include, path\n\nurlpatterns = [\n # ... snip ...\n path('community/', include('aggregator.urls')),\n path('contact/', include('contact.urls')),\n # ... snip ...\n]\nWhenever Django encounters include(), it chops off\nwhatever part of the URL matched up to that point and sends the remaining\nstring to the included URLconf for further processing.
Another possibility is to include additional URL patterns by using a list of\npath() instances. For example, consider this URLconf:
from django.urls import include, path\n\nfrom apps.main import views as main_views\nfrom credit import views as credit_views\n\nextra_patterns = [\n path('reports/', credit_views.report),\n path('reports/<int:id>/', credit_views.report),\n path('charge/', credit_views.charge),\n]\n\nurlpatterns = [\n path('', main_views.homepage),\n path('help/', include('apps.help.urls')),\n path('credit/', include(extra_patterns)),\n]\nNeste exemplo, a URL /credit/reports/ será manipulada pela view Django credit_views.report().
Isso pode ser usado para remover redundâncias de URLconf onde um único prefixo de padrão é usado repetidamente. Por exemplo, considere o URLconf:
\nfrom django.urls import path\nfrom . import views\n\nurlpatterns = [\n path('<page_slug>-<page_id>/history/', views.history),\n path('<page_slug>-<page_id>/edit/', views.edit),\n path('<page_slug>-<page_id>/discuss/', views.discuss),\n path('<page_slug>-<page_id>/permissions/', views.permissions),\n]\nPodemos melhorar isso começando o caminho comum com um prefixo e agrupando os sufixos que diferem:
\nfrom django.urls import include, path\nfrom . import views\n\nurlpatterns = [\n path('<page_slug>-<page_id>/', include([\n path('history/', views.history),\n path('edit/', views.edit),\n path('discuss/', views.discuss),\n path('permissions/', views.permissions),\n ])),\n]\nUm URLconf que foi inluído recebe qualquer parâmetro capturado vindos dos URLconfs pais, logo o seguinte exemplo é válido:
\n# In settings/urls/main.py\nfrom django.urls import include, path\n\nurlpatterns = [\n path('<username>/blog/', include('foo.urls.blog')),\n]\n\n# In foo/urls/blog.py\nfrom django.urls import path\nfrom . import views\n\nurlpatterns = [\n path('', views.blog.index),\n path('archive/', views.blog.archive),\n]\nNo exemplo acima, a variável "username" é capturada e passada para o URLconf incluído, como esperado.
URLconfs tem um gancho que deixa você passar argumentos extra par suas funções “view”, como um dicionário Python.
\nThe path() function can take an optional third argument\nwhich should be a dictionary of extra keyword arguments to pass to the view\nfunction.
Por exemplo:
\nfrom django.urls import path\nfrom . import views\n\nurlpatterns = [\n path('blog/<int:year>/', views.year_archive, {'foo': 'bar'}),\n]\nIn this example, for a request to /blog/2005/, Django will call\nviews.year_archive(request, year=2005, foo='bar').
Esta técnica é usada no syndication framework para passar metadados e opções para as “views”.
\n\ninclude()Link para este cabeçalho#Similarly, you can pass extra options to include() and\neach line in the included URLconf will be passed the extra options.
Por exemplo, estas duas definições de URLconf são funcionamente idênticas:
\nDefinição um:
\n# main.py\nfrom django.urls import include, path\n\nurlpatterns = [\n path('blog/', include('inner'), {'blog_id': 3}),\n]\n\n# inner.py\nfrom django.urls import path\nfrom mysite import views\n\nurlpatterns = [\n path('archive/', views.archive),\n path('about/', views.about),\n]\nDefinição dois:
\n# main.py\nfrom django.urls import include, path\nfrom mysite import views\n\nurlpatterns = [\n path('blog/', include('inner')),\n]\n\n# inner.py\nfrom django.urls import path\n\nurlpatterns = [\n path('archive/', views.archive, {'blog_id': 3}),\n path('about/', views.about, {'blog_id': 3}),\n]\nNote que as opções extra serão sempre passadas para cada linha do URLconf incluído, independente se a “view” aceita estas opções como válidas. Por esta razão, essa técnica é somente útil se você estiver certo que cada “view” no URLconf incluído aceita as opções extras que estão sendo passadas.
\nUma necessidade comum quando trabalhando com um projeto Django é a possibilidade de obter URLs na sua forma final, seja para adicioná-lo em um conteúdo gerado (“views” e ativos de URLs, URLs a serem mostradas para o usuário, etc.) ou para lidar com o fluxo de navegação no lado do servidor (redirecionamentos, etc).
\nÉ altamente desejável evitar escrever URLs diretamente no código (uma estratégia trabalhosa, não-escalável e propensa a erros). Igualmente perigoso é conceber mecânismos pontuais para gerar URLs que sejam paralelos as especificações descritas no URLconf, o que pode resultar na produção de URLs que se tornem desatualizadas ao passar do tempo.
\nEm outras palavras, o que é preciso é um mecênismo enxuto (“DRY”). Entre outras vantagens isso permitiria a evolução da definição de URL sem ter que passar por todo o código do projeto para procurar e substituir URLs desatualizadas.
\nO primeiro pedaço de infomação que temos disponível para chegar a uma URL é uma identificação (ex.: o nome) da “view” responsável por lidar com ela. Outras partes de informação que necessariamente deve participar da busca pela URL correta são os tipos (posicional, nomeado) e valores dos argumentos da “view”.
\nO Django fornece uma solução tal que o mapeador de URL é o único reposritório de definição de URL. Você o alimenta com seu URLconf e então este pode ser usado em ambas as direções:
\nComeçando com uma URL requisitada pelo usuário/navegador Web, ele chama a “view” Django correta fornecendo quaisquer argumentos que esta necessite e com os valores extraídos da URL.
Começando com a identificação da “view” Django correspondente mais os valores dos argumentos que poderiam ser passados a ela, obten-se a URL associada.
O primeiro caso é o uso que estivemos discutindo na seção anterior. O segundo é o que é conhecido como resolução reversa de URLs, combinação reversa de URL, filtro reverso de URL, ou simplesmente URL reversa.
\nO Django fornece ferramentas para realizar a reversão de URL que vá de encontro com as diferentes camadas onde URLs são necessárias:
\nEm “templates”: usando a tag de template url.
In Python code: Using the reverse() function.
EM código de nível mais alto relacionado à manipulação de URLs de instâncias de modelos Django: o método get_absolute_url().
Considere novamente essa entrada do URLconf:
\nfrom django.urls import path\n\nfrom . import views\n\nurlpatterns = [\n #...\n path('articles/<int:year>/', views.year_archive, name='news-year-archive'),\n #...\n]\nAccording to this design, the URL for the archive corresponding to year nnnn\nis /articles/<nnnn>/.
Você pode obtê-la no código de template usando:
\n<a href="{% url 'news-year-archive' 2012 %}">2012 Archive</a>\n{# Or with the year in a template context variable: #}\n<ul>\n{% for yearvar in year_list %}\n<li><a href="{% url 'news-year-archive' yearvar %}">{{ yearvar }} Archive</a></li>\n{% endfor %}\n</ul>\nOu em código Python:
\nfrom django.http import HttpResponseRedirect\nfrom django.urls import reverse\n\ndef redirect_to_year(request):\n # ...\n year = 2006\n # ...\n return HttpResponseRedirect(reverse('news-year-archive', args=(year,)))\nSe, por algum motivo, foi decidido que a URL onde conteúdo de arquivos de artigos anuais são publicados deve ser alterados, então é deve-se alterar somente a entrada no URLconf.
\nEm alguns cenários onde “views” são de natureza genérica, talvez exista um relacionamento muitos-para-um entre URLs e “views”. Para estes casos o nome da “view” não é um identificador bom o suficiente para identificá-los quando chega a hora de usar a URL reversa. Leia a próxima seção para conhecer a solução que o Django fornece pra isso.
\nDe modo a realizar uma URL reversa, é necessário usar **padrões de URL nominadas* como feito no exemplo acima. A string usada para o nome da URL pode conter qualquer caracter que queira. Você não está restrito a nomes válidos em Python.
\nWhen naming URL patterns, choose names that are unlikely to clash with other\napplications’ choice of names. If you call your URL pattern comment\nand another application does the same thing, the URL that\nreverse() finds depends on whichever pattern is last in\nyour project’s urlpatterns list.
Putting a prefix on your URL names, perhaps derived from the application\nname (such as myapp-comment instead of comment), decreases the chance\nof collision.
You can deliberately choose the same URL name as another application if you\nwant to override a view. For example, a common use case is to override the\nLoginView. Parts of Django and most\nthird-party apps assume that this view has a URL pattern with the name\nlogin. If you have a custom login view and give its URL the name login,\nreverse() will find your custom view as long as it’s in\nurlpatterns after django.contrib.auth.urls is included (if that’s\nincluded at all).
You may also use the same name for multiple URL patterns if they differ in\ntheir arguments. In addition to the URL name, reverse()\nmatches the number of arguments and the names of the keyword arguments.
Nomes de domínios de URL possibilitam a você exclusividade ao reverter os padrões de formato de URL nominados, mesmo que uma aplicação diferente use os mesmos nomes para URL. É uma boa prática para aplicações de terceiros sempre usar URLs dentro de um nome de domínio (como fizemos no tutorial). De mpodo similar, isso também permite a você usar o mode reverso de URLs se múltiplas intâncias de uma aplicação for implantada. Em outras palavras, se múltiplas instâncias de uma única aplicação irá compartilhar URLs nominada, os nomes de domínios fornecem uma maneira de manter essas URLs nominadas separadas.
\nAs aplicações Django que fazem uso correto do “namespacing” da URL podem ser instaladas em produção mais de uma vez para um mesmo site. Por exemplo django.contrib.admin tem uma classe AdminSite a qual permite facilmente instalar mais de uma instância do admin. Em um exemplo a seguir, iremos discutir a idéia de instalar a aplicação “polls” do tutorial em dois locais diferentes de modo que podemos servir as mesmas funcionalidades para dois públicos diferentes (autores e editores).
Um nome de domínio de URL é formado por duas partes, sendo ambas do tipo strings:
\nEste descreve o nome da aplicação que está sendo implantada. Cada instância de uma única aplicação terá o mesmo nome de domínio de apliacação. Por exemlo, a aplicação de administração do Django tem previsivelmente seu nome de domínio de aplicação como sendo 'admin'.
Isso identifica uma instância específica de uma aplicação. Nomes de domínio de instância devem ser únicos dentro de todo o seu projeto. Contudo, um nome de domínio de uma intância pode ser o mesmo que o nome de domínio da sua aplicação. Isso é usado para especificar uma instância padrão da aplicação. Por exemplo, a instância padrão do administrador do Django tem 'admin' como seu nome de domínio de instância.
Nome de domínios de URLs são especificados usando o operador ':'. Por exemplo, a página principal da aplicação “admin” é referenciada usando 'admin:index'. Isso indica um nome de domínio do 'admin', e uma URL moninada de 'índice'.
Nomes de domínio podem ser aninhados. A URL nominada 'sports:polls:index' poderia procurar por um padrão de formato chamado 'index' no nome de domínio 'polls' que é ele próprio definido dentro do nome de domínio de nível superior 'sports'.
Quando dada uma URL com nome de domínio (ex.: 'polls:index') para resolver, o Django divide em partes o nome totalmente qualificado e então trás o seguinte filtro:
Primeiro, o Django procura por uma application namespace que combine (neste exemplo, 'polls'). Isso irá produzir uma lista de instâncias daquela aplicação.
If there is a current application defined, Django finds and returns the URL\nresolver for that instance. The current application can be specified with\nthe current_app argument to the reverse()\nfunction.
A tag de template url usa o nome de domínio da view corrente resolvida como a aplicação corrente em uma RequestContext. Você pode sobrescrever seu padrão definindo a aplicação corrente no atributo request.current_app.
Se não há aplicação corrente, o Django procura por um instância de aplicação padrão. A instância da aplicação padrão é a instância que tem um instance namespace que combine com o application namespace (neste exemplo, uma instância de polls``chamada ``'polls').
Se não uma instância padrão de aplicação, o Django irá usar a última instância instalada da aplicação, não importando qual seja o nome desta instância.
Se o nome de domínio não combina com application namespace no passo 1, o Django irá tentar um filtro direto do nome de domínio como um instance namespace.
Se há nomes de domínios aninhados, estes passos são repetidos para cada parte do nome de domínio até que somente o nome da “view” esteja não resolvido. O nome da “view” será então resolvido em uma URL dentro do nome de domínio no qual foi encontrado.
\nPara mostrar essa estratégia de resolução em ação, considere um exemplo de duas instâncias da aplicação polls do tutorial: uma chamada 'authors-polls' e uma chamada 'publisher-poll'. Assuma que tenhamos melhorado esta aplicação de modo que ela leve em consideração o nome de domínio da instância quando criar e mostrar as enquetes (‘polls’).
urls.pyfrom django.urls import include, path\n\nurlpatterns = [\n path('author-polls/', include('polls.urls', namespace='author-polls')),\n path('publisher-polls/', include('polls.urls', namespace='publisher-polls')),\n]\npolls/urls.pyfrom django.urls import path\n\nfrom . import views\n\napp_name = 'polls'\nurlpatterns = [\n path('', views.IndexView.as_view(), name='index'),\n path('<int:pk>/', views.DetailView.as_view(), name='detail'),\n ...\n]\nUsando esta definição, os seguintes filtros são possíveis:
\nSe uma das intâncias é a corrente - digamos, se estivermos renderizando a página de detalhes da instância 'author-polls' - 'polls:index' será resolvido para a página de índice da instância 'author-polls'; isto é, ambos os seguintes irão resultar em "/author-polls/".
No método de uma “view” baseada em classe:
\nreverse('polls:index', current_app=self.request.resolver_match.namespace)\ne no “template”:
\n{% url 'polls:index' %}\nSe não houver uma instância corrente - digamos, se estivermos renderizando uma págna el algum outro lugar do site - 'polls:index' será resolvido para a última instância registrada de polls. Desde que não haja uma instância padrão (nome de domínio de instância 'polls'), a última instância de polls registrada será usada. Essa deve ser 'publisher-polls' já que foi declarada por último no urlpatterns.
'author-polls:index' sempre irá resolver para a página de índice da instância 'author-polls' (da mesma forma para 'publisher-polls') .
Se havia também uma instância padrão - isto é, uma instância nominada 'polls' - a única mudança do exemplo acima seria no caso onde não há intância corrente (o segundo item na lista acima). Neste caso 'polls:index' seria resolvido para a página de índice da intância padrão ao invés da instância declarada por último no urlpatterns.
o Domínio dos nomes de aplicação de URLconfs cinludídos podem ser especificados de dois modos.
\nFirstly, you can set an app_name attribute in the included URLconf module,\nat the same level as the urlpatterns attribute. You have to pass the actual\nmodule, or a string reference to the module, to include(),\nnot the list of urlpatterns itself.
polls/urls.pyfrom django.urls import path\n\nfrom . import views\n\napp_name = 'polls'\nurlpatterns = [\n path('', views.IndexView.as_view(), name='index'),\n path('<int:pk>/', views.DetailView.as_view(), name='detail'),\n ...\n]\nurls.pyfrom django.urls import include, path\n\nurlpatterns = [\n path('polls/', include('polls.urls')),\n]\nAs URLs definidas em polls.urls terão um nome de domínio como polls.
Secondly, you can include an object that contains embedded namespace data. If\nyou include() a list of path() or\nre_path() instances, the URLs contained in that object\nwill be added to the global namespace. However, you can also include() a\n2-tuple containing:
(<list of path()/re_path() instances>, <application namespace>)\nPor exemplo:
\nfrom django.urls import include, path\n\nfrom . import views\n\npolls_patterns = ([\n path('', views.IndexView.as_view(), name='index'),\n path('<int:pk>/', views.DetailView.as_view(), name='detail'),\n], 'polls')\n\nurlpatterns = [\n path('polls/', include(polls_patterns)),\n]\nIsso irá incluir o nome do padrão de formato de URL nomeado dentro do nome de domínio da dada aplicação.
\nThe instance namespace can be specified using the namespace argument to\ninclude(). If the instance namespace is not specified,\nit will default to the included URLconf’s application namespace. This means\nit will also be the default instance for that namespace.