Bersih, skema URL anggun adalah rincian penting dalam aplikasi jaringan kualitas-tinggi. Django membuat anda merancang URL bagaimanapun anda inginkan, dengan tanpa batasan kerangka kerja.
\nSee Cool URIs don't change, by World Wide Web creator Tim Berners-Lee, for\nexcellent arguments on why URLs should be clean and usable.
\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).
\nThis mapping can be as short or as long as needed. It can reference other\nmappings. And, because it's pure Python code, it can be constructed\ndynamically.
\nDjango also provides a way to translate URLs according to the active\nlanguage. See the internationalization documentation for more information.
\nWhen a user requests a page from your Django-powered site, this is the\nalgorithm the system follows to determine which Python code to execute:
\nDjango determines the root URLconf module to use. Ordinarily, this is the\nvalue of the ROOT_URLCONF setting, but if the incoming\nHttpRequest object has a urlconf\nattribute (set by middleware), its value will be used in place of the\nROOT_URLCONF setting.
Django loads that Python module and looks for the variable\nurlpatterns. This should be a sequence of\ndjango.urls.path() and/or django.urls.re_path() instances.
Django runs through each URL pattern, in order, and stops at the first\none that matches the requested URL, matching against\npath_info.
Once one of the URL patterns matches, Django imports and calls the given\nview, which is a Python function (or a class-based view). The view gets passed the following\narguments:
\nSebuah instance dari HttpRequest.
If the matched URL pattern contained 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 that are provided, overridden by any arguments specified\nin the optional kwargs 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.
Ini adalah contoh 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]\nCatatan:
\nUntuk menangkap nilai dari URL, gunakan kurung sudut.
Captured values can optionally include a converter type. For example, use\n<int:name> to capture an integer parameter. If a converter isn't\nincluded, any string, excluding a / character, is matched.
Tidak perlu menambahkan awalan garis miring, karena setiap URL memilikinya. Sebgai contoh, itu adalah articles, bukan /articles.
Contoh permintaan:
\nPermintaan pada /articles/2005/03/ akan mencocokkan masukan ketiga dalam list. Django akan memanggil fungsi views.month_archive(permintaan, year=2005, month=3).
/articles/2003/ would match the first pattern in the list, not the\nsecond one, because the patterns are tested in order, and the first one\nis the first test to pass. Feel free to exploit the ordering to insert\nspecial cases like this. Here, Django would call the function\nviews.special_case_2003(request)
/articles/2003 would not match any of these patterns, because each\npattern requires that the URL end with a slash.
/articles/2003/03/building-a-django-site/ would match the final pattern.\nDjango would call the function\nviews.article_detail(request, year=2003, month=3, slug="building-a-django-site").
Perubah jalur berikut tersedia secara awalan:
\nstr - Matches any non-empty string, excluding the path separator,\n'/'. This is the default if a converter isn't included in the expression.
int - Cocok nol atau integer positif apapun. Mengembalikan sebuah 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\na segment of a URL path as with str.
For more complex matching requirements, you can define your own path\nconverters.
\nA converter is a class that includes the following:
\nAtribut kelas regex, sebagai 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 ValueError is\ninterpreted as no match and as a consequence a 404 response is sent to the\nuser unless another URL pattern matches.
A to_url(self, value) method, which handles converting the Python type\ninto a string to be used in the URL. It should raise ValueError if it\ncan't convert the given value. A ValueError is interpreted as no match\nand as a consequence reverse() will raise\nNoReverseMatch unless another URL pattern matches.
Sebagai contoh:
\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(\n r"^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<slug>[\\w-]+)/$",\n views.article_detail,\n ),\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.
\nRegular expressions allow nested arguments, and Django will resolve them and\npass them to the view. When reversing, Django will try to fill in all outer\ncaptured arguments, ignoring any nested captured arguments. Consider the\nfollowing URL patterns which optionally take a page argument:
\nfrom django.urls import re_path\n\nurlpatterns = [\n re_path(r"^blog/(page-([0-9]+)/)?$", blog_articles), # bad\n re_path(r"^comments/(?:page-(?P<page_number>[0-9]+)/)?$", comments), # good\n]\nBoth patterns use nested arguments and will resolve: for example,\nblog/page-2/ will result in a match to blog_articles with two\npositional arguments: page-2/ and 2. The second pattern for\ncomments will match comments/page-2/ with keyword argument\npage_number set to 2. The outer argument in this case is a non-capturing\nargument (?:...).
The blog_articles view needs the outermost captured argument to be\nreversed, page-2/ or no arguments in this case, while comments can be\nreversed with either no arguments or a value for page_number.
Nested captured arguments create a strong coupling between the view arguments\nand the URL as illustrated by blog_articles: the view receives part of the\nURL (page-2/) instead of only the value the view is interested in. This\ncoupling is even more pronounced when reversing, since to reverse the view we\nneed to pass the piece of URL instead of the page number.
As a rule of thumb, only capture the values the view needs to work with and\nuse non-capturing arguments when the regular expression needs an argument but\nthe view ignores it.
\nThe URLconf searches against the requested URL, as a normal Python string. This\ndoes not include GET or POST parameters, or the domain name.
\nSebagai contoh, dalam permintaan pada https://www.example.com/myapp/, URLconf akan mencari myapp/.
Dalam permintaan untuk https://www.example.com/myapp/?page=3, the URLconf akan mencari myapp/.
The URLconf doesn't look at the request method. In other words, all request\nmethods -- POST, GET, HEAD, etc. -- will be routed to the same\nfunction for the same URL.
A convenient trick is to specify default parameters for your views' arguments.\nHere's an example URLconf and 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\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.
Django processes regular expressions in the urlpatterns list which is\ncompiled the first time it's accessed. Subsequent requests use the cached\nconfiguration via the URL resolver.
urlpatternsLink to this heading#urlpatterns should be a sequence of path()\nand/or re_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.
\nThe views to use for these cases are specified by four variables. Their\ndefault values should suffice for most projects, but further customization is\npossible by overriding their default values.
\nLihat dokumentasi pada customizing error views 1 untuk rincian penuh.
\nNilai-nilai itu dapat disetel dalam URLconf akar anda. Pengaturan variabel-variabel ini dalam URLconf lain apapun tidak mempunyai pengaruh.
\nNilai-nilai harus callable, atau deretan karakter mewakili jalur impor Pythn penuh pada tampilan yang harus dipanggil untuk menangani kondisi kesalahan di tangan.
\nVariabel nya adalah:
\nhandler400 -- Lihat django.conf.urls.handler400.
handler403 -- Lihat django.conf.urls.handler403.
handler404 -- Lihat django.conf.urls.handler404.
handler500 -- Lihat django.conf.urls.handler500.
At any point, your urlpatterns can "include" other URLconf modules. This\nessentially "roots" a set of URLs below other ones.
For example, here's an excerpt of the URLconf for the Django website\nitself. It includes a number of other 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]\nDalam contoh ini, URL /credit/reports/ akan ditangani oleh tampilan Django credit_views.report().
This can be used to remove redundancy from URLconfs where a single pattern\nprefix is used repeatedly. For example, consider this 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]\nKami dapat meningkatkan dengan menyatakan awalan jalur umum hanya sekali dan mengelompokkan akhiran yang beda:
\nfrom django.urls import include, path\nfrom . import views\n\nurlpatterns = [\n path(\n "<page_slug>-<page_id>/",\n include(\n [\n path("history/", views.history),\n path("edit/", views.edit),\n path("discuss/", views.discuss),\n path("permissions/", views.permissions),\n ]\n ),\n ),\n]\nAn included URLconf receives any captured parameters from parent URLconfs, so\nthe following example is valid:
\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]\nIn the above example, the captured "username" variable is passed to the\nincluded URLconf, as expected.
URLconfs have a hook that lets you pass extra arguments to your view functions,\nas a Python dictionary.
\nThe path() function can take an optional third argument\nwhich should be a dictionary of extra keyword arguments to pass to the view\nfunction.
Sebagai contoh:
\nfrom django.urls import path\nfrom . import views\n\nurlpatterns = [\n path("blog/<int:year>/", views.year_archive, {"foo": "bar"}),\n]\nDalam contoh ini, untuk permintaan ke /blog/2005/, Django akan memanggil views.year_archive(permintaan, year=2005, foo='bar').
This technique is used in the\nsyndication framework to pass metadata and\noptions to views.
\n\ninclude()Link to this heading#Similarly, you can pass extra options to include() and\neach line in the included URLconf will be passed the extra options.
Sebagai contoh, kumpulan URLcond dua ini adalah kegunaannya mirip:
\nSetel satu:
\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]\nSetel dua:
\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 that extra options will always be passed to every line in the included\nURLconf, regardless of whether the line's view actually accepts those options\nas valid. For this reason, this technique is only useful if you're certain that\nevery view in the included URLconf accepts the extra options you're passing.
\nA common need when working on a Django project is the possibility to obtain\nURLs in their final forms either for embedding in generated content (views and\nassets URLs, URLs shown to the user, etc.) or for handling of the navigation\nflow on the server side (redirections, etc.)
\nIt is strongly desirable to avoid hardcoding these URLs (a laborious,\nnon-scalable and error-prone strategy). Equally dangerous is devising ad-hoc\nmechanisms to generate URLs that are parallel to the design described by the\nURLconf, which can result in the production of URLs that become stale over\ntime.
\nDengan kata lain, apa yang dibutuhkan adalah mekanisme DRY. Diantara keuntungan lain itu akan mengizinkan evolusi dari rancangan URL tanpa harus pergi ke semua kode sumber proyek untuk mencari dan mengganti URL usang.
\nThe primary piece of information we have available to get a URL is an\nidentification (e.g. the name) of the view in charge of handling it. Other\npieces of information that necessarily must participate in the lookup of the\nright URL are the types (positional, keyword) and values of the view arguments.
\nDjango provides a solution such that the URL mapper is the only repository of\nthe URL design. You feed it with your URLconf and then it can be used in both\ndirections:
\nStarting with a URL requested by the user/browser, it calls the right Django\nview providing any arguments it might need with their values as extracted\nfrom the URL.
Dimulai dengan pencirian dari tampilan Django sesuai ditambah nilai-nilai dari argumen yang akan dilewatkan ke itu, ambil URL terkait.
The first one is the usage we've been discussing in the previous sections. The\nsecond one is what is known as reverse resolution of URLs, reverse URL\nmatching, reverse URL lookup, or simply URL reversing.
\nDjango provides tools for performing URL reversing that match the different\nlayers where URLs are needed:
\nDalam cetakan: Menggunakan etiket cetakan url.
Dalam kode Python: Menggunakan fungsi reverse().
In higher level code related to handling of URLs of Django model instances:\nThe get_absolute_url() method.
Pertimbangkan kembali masukan URLconf ini:
\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]\nMenurut rancangan ini, URL untuk arsip yang sesuai pada tahun nnnn adalah /articles/<nnnn>/.
Anda dapat mendapatkan ini dalam kode cetakan dengan menggunakan:
\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>\nAtau di kode Phyton
\nfrom django.http import HttpResponseRedirect\nfrom django.urls import reverse\n\n\ndef redirect_to_year(request):\n # ...\n year = 2006\n # ...\n return HttpResponseRedirect(reverse("news-year-archive", args=(year,)))\nIf, for some reason, it was decided that the URLs where content for yearly\narticle archives are published at should be changed then you would only need to\nchange the entry in the URLconf.
\nIn some scenarios where views are of a generic nature, a many-to-one\nrelationship might exist between URLs and views. For these cases the view name\nisn't a good enough identifier for it when comes the time of reversing URLs.\nRead the next section to know about the solution Django provides for this.
\nIn order to perform URL reversing, you'll need to use named URL patterns\nas done in the examples above. The string used for the URL name can contain any\ncharacters you like. You are not restricted to valid Python names.
\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. Path\nconverters can also raise ValueError to indicate no match, see\nRegistering custom path converters for details.
URL namespaces allow you to uniquely reverse named URL patterns even if different applications use the same URL names.\nIt's a good practice for third-party apps to always use namespaced URLs (as we\ndid in the tutorial). Similarly, it also allows you to reverse URLs if multiple\ninstances of an application are deployed. In other words, since multiple\ninstances of a single application will share named URLs, namespaces provide a\nway to tell these named URLs apart.
\nDjango applications that make proper use of URL namespacing can be deployed\nmore than once for a particular site. For example django.contrib.admin\nhas an AdminSite class which allows you to\ndeploy more than one instance of the admin. In a\nlater example, we'll discuss the idea of deploying the polls application from\nthe tutorial in two different locations so we can serve the same functionality\nto two different audiences (authors and publishers).
Sebuah namespace URL datang dalam dua bagian, keduanya adalah string:
\nThis describes the name of the application that is being deployed. Every\ninstance of a single application will have the same application namespace.\nFor example, Django's admin application has the somewhat predictable\napplication namespace of 'admin'.
Ini mencirikan instance khusus dari sebuah aplikasi. Namespace-namespace instance harus unik terhadap keseluruhan proyen anda. Bagaimanapun, sebuah namespace instance dapat berupa sama seperti namespace aplikasi. Ini digunakan untuk menentukan instance awalan dari sebuah aplikasi. Sebagai contoh, instance admin Django awalan mempunyai sebuah namespace instance dari 'admin'.
URL namespace ditentukan menggunakan penghubung ':'. Sebagai contoh, halaman indeks utama dari aplikasi admin diacukan menggunakan 'admin:index'. Ini menunjukkan sebuah namespace dari 'admin', dan sebuah URL bernama dari 'index'.
Namespace juga dapat bersarang. URL bernama 'sports:polls:index' akan terlihat untuk sebuah pola bernama 'index' dalam namespace 'polls' yag itu sendiri ditentukan dalam namespace tingkat-atas 'sports'.
When given a namespaced URL (e.g. 'polls:index') to resolve, Django splits\nthe fully qualified name into parts and then tries the following lookup:
Pertama, Django mencari untuk kecocokan application namespace (dalam contoh ini, 'polls'). Ini akan menghasilkan daftar dari instance dari aplikasi itu.
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.
The url template tag uses the namespace of the currently resolved\nview as the current application in a\nRequestContext. You can override this default by\nsetting the current application on the request.current_app attribute.
If there is no current application, Django looks for a default\napplication instance. The default application instance is the instance\nthat has an instance namespace matching the application\nnamespace (in this example, an instance of polls called 'polls').
If there is no default application instance, Django will pick the last\ndeployed instance of the application, whatever its instance name may be.
If the provided namespace doesn't match an application namespace in\nstep 1, Django will attempt a direct lookup of the namespace as an\ninstance namespace.
If there are nested namespaces, these steps are repeated for each part of the\nnamespace until only the view name is unresolved. The view name will then be\nresolved into a URL in the namespace that has been found.
\nTo show this resolution strategy in action, consider an example of two\ninstances of the polls application from the tutorial: one called\n'author-polls' and one called 'publisher-polls'. Assume we have\nenhanced that application so that it takes the instance namespace into\nconsideration when creating and displaying 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]\nMenggunakan pengaturan ini, pencarian berikut adalah mungkin:
\nIf one of the instances is current - say, if we were rendering the detail\npage in the instance 'author-polls' - 'polls:index' will resolve to\nthe index page of the 'author-polls' instance; i.e. both of the following\nwill result in "/author-polls/".
Dalam metode dari tampilan berdasarkan-kelas:
\nreverse("polls:index", current_app=self.request.resolver_match.namespace)\ndan di cetakan:
\n{% url 'polls:index' %}\nIf there is no current instance - say, if we were rendering a page\nsomewhere else on the site - 'polls:index' will resolve to the last\nregistered instance of polls. Since there is no default instance\n(instance namespace of 'polls'), the last instance of polls that is\nregistered will be used. This would be 'publisher-polls' since it's\ndeclared last in the urlpatterns.
'author-polls:index' will always resolve to the index page of the\ninstance 'author-polls' (and likewise for 'publisher-polls').
If there were also a default instance - i.e., an instance named 'polls' -\nthe only change from above would be in the case where there is no current\ninstance (the second item in the list above). In this case 'polls:index'\nwould resolve to the index page of the default instance instead of the instance\ndeclared last in urlpatterns.
Namespace-namespace aplikasi dari URLconf disertakan dapat ditentukan dalam dua cara.
\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]\nURL ditentukan dalam polls.urls akan memiliki sebuah namespace aplikasi 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>)\nSebagai contoh:
\nfrom django.urls import include, path\n\nfrom . import views\n\npolls_patterns = (\n [\n path("", views.IndexView.as_view(), name="index"),\n path("<int:pk>/", views.DetailView.as_view(), name="detail"),\n ],\n "polls",\n)\n\nurlpatterns = [\n path("polls/", include(polls_patterns)),\n]\nIni akan menyertakan pola URL ditunjuk kedalam namespace aplikasi diberikan.
\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.