For a URL template Django task, bind the link to a namespaced URL name and its required argument. Then review a route revision against fresh reversal and template-render observations. A displayed expected path is a specification, not evidence that a link resolved or a page opened.
This original example uses the Django 5.2 documentation as its reference. It does not establish the installed or latest version. The application is called notebook, the URL name is detail, and the authored note ID is 7. No database, real note, server, authentication, or deployment is connected.
State the route contract completely
| Contract field | Authored fixture |
|---|---|
| Application namespace | notebook |
| Instance namespace | notebook, a single default instance |
| Named route | detail |
| Required keyword argument | note_id |
| Example argument | 7 |
| Root inclusion | Once at the project root, no additional mount prefix |
| Source revision S1 | notes/int:note_id/ |
| Source revision S2 | entries/int:note_id/ |
The root inclusion matters. A route fragment does not tell you the whole path if a project mounts it beneath another prefix. Keep that configuration in the record rather than assuming /notes/7/ from the application route alone.
Django documents application namespaces through an included URLconf's app_name and instance namespaces through include configuration. Our single root-mounted default instance removes ambiguity for this fixture; a different project configuration needs its own reviewed result. Django 5.2 namespace documentation.
Prepare S1 as a native source specification
The following snippets are authoring material inside this manuscript. They have not been written as executable project files or run.
Application URLconf specification, notebook/urls.py:
from django.urls import path
from . import views
app_name = "notebook"
urlpatterns = [
path("notes/<int:note_id>/", views.detail, name="detail"),
]
Project root URLconf specification:
from django.urls import include, path
urlpatterns = [
path("", include("notebook.urls")),
]
Minimal view stub specification, notebook/views.py:
from django.http import HttpResponse
def detail(request, note_id):
return HttpResponse("Demonstration route only.")
The stub deliberately supplies no real note content or database lookup. Its eventual use would let a native test resolve the view binding without pretending note 7 exists.
Link template specification:
<a href="{% url 'notebook:detail' note_id=7 %}">Open demonstration note 7</a>
The expected path under S1 is /notes/7/, without a domain. The authored argument is explicit in this fixture. If your application passes a context value instead, record that context and test it; do not assume that an absent context value becomes 7.
Django's url tag uses a named route and the required arguments. Quote the literal name and use keyword arguments consistently. A direct tag raises NoReverseMatch when the lookup cannot be reversed; this manuscript's actual render/error observations remain blank. Django 5.2 url tag reference.
Revise the path while retaining the binding
For S2, change only the application route's path:
path("entries/<int:note_id>/", views.detail, name="detail")
Keep the application namespace, default instance, route name, keyword argument, root inclusion, and link template unchanged. The expected path becomes /entries/7/. The template still asks for notebook:detail with note_id=7.
That is the useful comparison: the route definition changes the expected location without a literal path edit in the template. Do not update a display-only expected result and treat it as a fresh rendered output.
Keep this native evidence ledger:
| Case | Inputs | Expected result | Actual reverse/render result |
|---|---|---|---|
| S1 | Root mount, notebook:detail, note_id=7, notes path | /notes/7/ | |
| S2 | Same binding and template, entries path | /entries/7/ | |
| E1 | Direct tag uses notebook:missing | NoReverseMatch | |
| E2 | Direct notebook:detail tag omits note_id | NoReverseMatch |
Actual cells are blank. The expected S1 result cannot count as proof for S2. Record the installed Django version, relevant settings, URLconf/template/context revisions, and actual test output when native testing occurs.
Changing the mount prefix, namespace, name, argument contract, context, or template retires earlier acceptance for the changed inputs. Keep historical results labeled with their original source revision rather than deleting them or presenting them as current.
Separate required failure from an optional link
The detail link is required in this fixture. If the direct tag cannot reverse it, investigate the contract instead of inserting a guessed href. A hand-entered /notes/7/ can hide a broken name or missing argument.
For a genuinely optional route, use a separate case:
{% url 'notebook:help' as optional_url %}
{% if optional_url %}
<a href="{{ optional_url }}">Notebook help</a>
{% endif %}
No help route is supplied in this fixture. Django documents the as-variable form for optional views without the same missing-view error. The expected optional case is no anchor when that route is unavailable. Verify the actual behavior later; do not replace the guard with an empty href or a decorative link that has no destination.
An optional policy should not silently swallow a required detail-route failure. Keep E1/E2 in the direct-tag error cases and the missing help route in its own optional case.
Plan native checks before the reading copy
The later test plan needs two kinds of evidence. Named reversal checks the path produced for the chosen route binding. Template rendering checks the link produced by the actual template and its context. Neither proves that the target page contains a real note or that access is authorized.
For S1 and S2, inspect the actual path and rendered href under the stated settings. For E1/E2, record the actual exception rather than a written assertion that the test failed correctly. For the optional case, inspect that no anchor with an empty or guessed destination is emitted.
Then review escaping, readable anchor text, keyboard access, and the actual production article and narrow container. The simple authored paths here do not establish behavior for other argument types or special characters.
The current deliverable is the source specification and test ledger. Native files, reversal, rendering, server requests, and visual inspection have not been performed.
Copy this prompt to prepare the route packet
Create one complete, self-contained US-English HTML companion for “Django named URL · route contract workbench”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for S1 · notes; S2 · entries; Restore S1 fixture; Select text. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an original English authoring packet for a Django named URL link. Reference the official Django 5.2 documentation, not an assumed installed
or latest version. Do not create executable files, run Django, start a
server, open URLs, access a database, create native framework output, capture, or deploy.
Fixture:
Application module notebook; app_name = "notebook". Single default instance namespace notebook. Include notebook.urls once at project root using an empty mount prefix. Named route detail requires integer keyword argument note_id. S1 route: notes/<int:note_id>/. S2 route: entries/<int:note_id>/. Both bind views.detail with name="detail". Minimal view stub accepts request and note_id and returns a demonstration
response, no real note data.
Link template:
<a href="{% url 'notebook:detail' note_id=7 %}">Open demonstration note 7</a>
Expected results, not executed:
S1 -> /notes/7/ without domain. S2 -> /entries/7/ without domain. Namespace/name/argument/root inclusion and template stay unchanged
between S1 and S2. Only the route path changes. Use quoted names and keyword arguments; do not mix positional/keyword. Do not add a mount prefix or context dependency silently.
Required error cases:
Direct tag with notebook:missing -> expected NoReverseMatch. Direct notebook:detail with missing note_id -> expected NoReverseMatch. Actual exceptions remain unobserved. No guessed fallback href.
Separate optional case, with no help route supplied:
{% url 'notebook:help' as optional_url %}
{% if optional_url %}
<a href="{{ optional_url }}">Notebook help</a>
{% endif %}
Expected missing optional route: no anchor. Actual render pending. No empty href or pseudo-link. Do not use this optional policy to conceal
required detail-link failures.
Deliver:
Native URLconf/template/minimal-view source specifications inside the
authoring packet, not executable project files. Source revision ledger for URLconf, root mount, namespace, template,
context, settings and installed version. Expected-case matrix with blank actual reverse/render/error observations. Plan native reversal and template-render tests for S1/S2/E1/E2/optional. Inputs changed -> retire prior acceptance for those changed inputs,
retain historical evidence with its original revision.
No claim of a real note, live link, database, authentication, runtime
success, current installation or deployment. Escaping, keyboard/focus,
production article width and narrow layout observations remain pending.
Native URLconf/template/tests remain
authoritative. NOS does not resolve Django namespaces or execute Django.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# URL Template Django: Keep the Link Bound to Its Name
You change a route from notes to entries, but the template still contains /notes/7/. The page renders a plausible-looking link to the old location. Fixing each literal path by hand makes the next route change harder to review.
For a URL template Django task, bind the link to a namespaced URL name and its required argument. Then review a route revision against fresh reversal and template-render observations. A displayed expected path is a specification, not evidence that a link resolved or a page opened.
This original example uses the Django **5.2 documentation as its reference**. It does not establish the installed or latest version. The application is called notebook, the URL name is detail, and the authored note ID is 7. No database, real note, server, authentication, or deployment is connected.
## State the route contract completely
| Contract field | Authored fixture |
| --- | --- |
| Application namespace | notebook |
| Instance namespace | notebook, a single default instance |
| Named route | detail |
| Required keyword argument | note_id |
| Example argument | 7 |
| Root inclusion | Once at the project root, no additional mount prefix |
| Source revision S1 | notes/<int:note_id>/ |
| Source revision S2 | entries/<int:note_id>/ |
The root inclusion matters. A route fragment does not tell you the whole path if a project mounts it beneath another prefix. Keep that configuration in the record rather than assuming /notes/7/ from the application route alone.
Django documents application namespaces through an included URLconf's app_name and instance namespaces through include configuration. Our single root-mounted default instance removes ambiguity for this fixture; a different project configuration needs its own reviewed result. [Django 5.2 namespace documentation](https://docs.djangoproject.com/en/5.2/topics/http/urls/#url-namespaces).
## Prepare S1 as a native source specification
The following snippets are authoring material inside this manuscript. They have not been written as executable project files or run.
**Application URLconf specification, notebook/urls.py:**
from django.urls import path
from . import views
app_name = "notebook"
urlpatterns = [
path("notes/<int:note_id>/", views.detail, name="detail"),
]
**Project root URLconf specification:**
from django.urls import include, path
urlpatterns = [
path("", include("notebook.urls")),
]
**Minimal view stub specification, notebook/views.py:**
from django.http import HttpResponse
def detail(request, note_id):
return HttpResponse("Demonstration route only.")
The stub deliberately supplies no real note content or database lookup. Its eventual use would let a native test resolve the view binding without pretending note 7 exists.
**Link template specification:**
<a href="{% url 'notebook:detail' note_id=7 %}">Open demonstration note 7</a>
The expected path under S1 is **/notes/7/**, without a domain. The authored argument is explicit in this fixture. If your application passes a context value instead, record that context and test it; do not assume that an absent context value becomes 7.
Django's url tag uses a named route and the required arguments. Quote the literal name and use keyword arguments consistently. A direct tag raises NoReverseMatch when the lookup cannot be reversed; this manuscript's actual render/error observations remain blank. [Django 5.2 url tag reference](https://docs.djangoproject.com/en/5.2/ref/templates/builtins/#url).
## Revise the path while retaining the binding
For S2, change only the application route's path:
path("entries/<int:note_id>/", views.detail, name="detail")
Keep the application namespace, default instance, route name, keyword argument, root inclusion, and link template unchanged. The expected path becomes **/entries/7/**. The template still asks for notebook:detail with note_id=7.
That is the useful comparison: the route definition changes the expected location without a literal path edit in the template. Do not update a display-only expected result and treat it as a fresh rendered output.
Keep this native evidence ledger:
| Case | Inputs | Expected result | Actual reverse/render result |
| --- | --- | --- | --- |
| S1 | Root mount, notebook:detail, note_id=7, notes path | /notes/7/ | |
| S2 | Same binding and template, entries path | /entries/7/ | |
| E1 | Direct tag uses notebook:missing | NoReverseMatch | |
| E2 | Direct notebook:detail tag omits note_id | NoReverseMatch | |
Actual cells are blank. The expected S1 result cannot count as proof for S2. Record the installed Django version, relevant settings, URLconf/template/context revisions, and actual test output when native testing occurs.
Changing the mount prefix, namespace, name, argument contract, context, or template retires earlier acceptance for the changed inputs. Keep historical results labeled with their original source revision rather than deleting them or presenting them as current.
## Separate required failure from an optional link
The detail link is required in this fixture. If the direct tag cannot reverse it, investigate the contract instead of inserting a guessed href. A hand-entered /notes/7/ can hide a broken name or missing argument.
For a genuinely optional route, use a separate case:
{% url 'notebook:help' as optional_url %}
{% if optional_url %}
<a href="{{ optional_url }}">Notebook help</a>
{% endif %}
No help route is supplied in this fixture. Django documents the as-variable form for optional views without the same missing-view error. The expected optional case is no anchor when that route is unavailable. Verify the actual behavior later; do not replace the guard with an empty href or a decorative link that has no destination.
An optional policy should not silently swallow a required detail-route failure. Keep E1/E2 in the direct-tag error cases and the missing help route in its own optional case.
## Plan native checks before the reading copy
The later test plan needs two kinds of evidence. Named reversal checks the path produced for the chosen route binding. Template rendering checks the link produced by the actual template and its context. Neither proves that the target page contains a real note or that access is authorized.
For S1 and S2, inspect the actual path and rendered href under the stated settings. For E1/E2, record the actual exception rather than a written assertion that the test failed correctly. For the optional case, inspect that no anchor with an empty or guessed destination is emitted.
Then review escaping, readable anchor text, keyboard access, and the actual production article and narrow container. The simple authored paths here do not establish behavior for other argument types or special characters.
The current deliverable is the source specification and test ledger. Native files, reversal, rendering, server requests, and visual inspection have not been performed.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review the prepared route-review copy
After native testing, a reading copy can put the unchanged template beside S1/S2 source revisions and their actual observations, making the route change easy to review.
Keep native URLconf, template, settings, and test evidence authoritative. A rendered reading copy does not perform Django reversal, execute a view, establish a live note, or prove access.
Leave the reviewer with the exact binding and current native evidence, rather than an old path that merely looks right.