Fred
/
gwift-book
1
0
Fork 1
Code Issues 64 Pull Requests 3 Releases 11 Wiki Activity

Mise à jour de 'source/part-3-django-concepts/urls.adoc'
continuous-integration/drone/push Build is passing Details

This commit is contained in:
Fred 2021-08-18 13:37:43 +02:00
parent c951e9f12d
commit 618980ce31
1 changed files with 19 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
source/part-3-django-concepts/urls.adoc
View File

@ -14,9 +14,16 @@ urlpatterns = [
]
----
La variable `urlpatterns` associe un ensemble d'adresses à des fonctions. Dans le fichier *nu*, seul le *pattern* `admin` est défini, et inclut toutes les adresses qui sont définies dans le fichier `admin.site.urls`.
La variable `urlpatterns` associe un ensemble d'adresses à des fonctions.
Dans le fichier *nu*, seul le *pattern* `admin` est défini, et inclut toutes les adresses qui sont définies dans le
fichier `admin.site.urls`.
NOTE: petit mot d'explication sur les expressions rationnelles.
Django fonctionne avec des *expressions rationnelles* simplifiées (des **expressions régulières** ou **regex**)
pour trouver une correspondance entre une URL et la fonction qui recevra la requête et retournera une réponse.
Nous utilisons l'expression `^$` pour déterminer la racine de notre application, mais nous pourrions appliquer d'autres regroupements
(`/home`, `users/<profile_id>`, `articles/<year>/<month>/<day>`, ...).
Chaque *variable* déclarée dans l'expression régulière sera apparenté à un paramètre dans la fonction correspondante.
Ainsi,
[source,python]
----
@ -40,9 +47,14 @@ urlpatterns = [
]
----
NOTE: Dans la mesure du possible, essayez toujours de **nommer** chaque expression.
Cela permettra notamment de les retrouver au travers de la fonction `reverse`, mais permettra également de simplifier vos templates.
A présent, on doit tester que l'URL racine de notre application mène bien vers la fonction `wish_views.wishlists`.
Prenons par exemple l'exemple de Twitter : quand on accède à une URL, elle est de la forme `https://twitter.com/<user>``. Sauf que les pages `about` et `help` existent également. Pour implémenter ce type de précédence, il faudrait implémenter les URLs de la manière suivante:
Prenons par exemple l'exemple de Twitter : quand on accède à une URL, elle est de la forme `https://twitter.com/<user>`.
Sauf que les pages `about` et `help` existent également.
Pour implémenter ce type de précédence, il faudrait implémenter les URLs de la manière suivante:
[source,text]
----
@ -51,11 +63,13 @@ Prenons par exemple l'exemple de Twitter : quand on accède à une URL, elle est
| <user>
----
Mais cela signifie aussi que les utilisateurs `about` et `help` (s'ils existent...) ne pourront jamais accéder à leur profil. Une dernière solution serait de maintenir une liste d'authorité des noms d'utilisateur qu'il n'est pas possible d'utiliser.
Mais cela signifie aussi que les utilisateurs `about` et `help` (s'ils existent...) ne pourront jamais accéder à leur profil.
Une dernière solution serait de maintenir une liste d'authorité des noms d'utilisateur qu'il n'est pas possible d'utiliser.
D'où l'importance de bien définir la séquence de déinition de ces routes, ainsi que des espaces de noms.
L'idée des espaces de noms ou _namespaces_ est de définir un _sous-répertoire_ dans lequel on trouvera nos nouvelles routes. Cette manière de procéder permet notamment de répondre au problème ci-dessous, en définissant un sous-dossier type `https://twitter.com/users/<user>``.
L'idée des espaces de noms ou _namespaces_ est de définir un _sous-répertoire_ dans lequel on trouvera nos nouvelles routes.
Cette manière de procéder permet notamment de répondre au problème ci-dessous, en définissant un sous-dossier type `https://twitter.com/users/<user>`.
De là, découle une autre bonne pratique: l'utilisation de _breadcrumbs_ (https://stackoverflow.com/questions/826889/how-to-implement-breadcrumbs-in-a-django-template) ou de guidelines de navigation.