inclusion doc Django
This commit is contained in:
parent
e52939136f
commit
68f779f770
96
doc.md
96
doc.md
|
|
@ -1607,102 +1607,6 @@ Seule l'écriture du fichier models.py est nécessaire. Il suffit de préciser l
|
|||
# Mise au point technique
|
||||
## Python
|
||||
### Packing et unpacking
|
||||
## Django
|
||||
TODO Se documenter sur les templates (modèle MVT)
|
||||
Expliquer philosophie DRY (*Don't Repeat Yourself*)
|
||||
### Principes généraux
|
||||
#### Vues
|
||||
|
||||
##### Class-Based Views (CBV)
|
||||
Nouvelle façon d'écrire des vues
|
||||
Repose sur la définition d'une classe contenant les attributs nécessaires à la construction de la vue et la définition de méthodes correspondant aux requêtes http vers la vue
|
||||
|
||||
Les *mixins* propose, par l'utilisation de l'héritage multiple, un mécanisme voué à éviter la duplication du code dans les CBV.
|
||||
|
||||
##### Decorators
|
||||
La mise en place du POC a nécessité l'utilisation de décorateurs de vue. Ce mécanisme propre à Django permet de restreindre l'affichage d'une vue sous certaines conditions.
|
||||
Des décorateurs sont proposés par défaut dans Django. Ils commencent par `@` et précédent la définition d'une vue dans les sources de l'application. Par exemple:
|
||||
`@csrf_exempt`
|
||||
`def index(request):`
|
||||
` <view logic>`
|
||||
` return wcs_submit(data)`
|
||||
|
||||
Le décorateur `@csrf_exempt` est de type permissif : il stipule que le client (par exemple un navigateur) n'a pas besoin de fournir un jeton CSRF (*csrf token*) pour pouvoir accéder à la vue.
|
||||
|
||||
Au contraire, des décorateurs tels que `@login_required` ou `@require_http_methods` peuvent être de type restrictif.
|
||||
|
||||
Bien que Django fournisse des décorateurs par défaut, ce framework permet aux développeurs de définir les leurs. Un décorateur est une double définition de deux fonctions imbriquées - l'un des deux fonctions devant renvoyer en argument la seconde. Par exemple, nous pouvons définir un décorateur interdisant l'affichage de la vue si le dernier utilisateur connecté possède déjà un compte renseigné dans le LDAP:
|
||||
|
||||
`def user_not_in_ldap(function):`
|
||||
` def wrapped(request, *args, **kwargs):`
|
||||
` user_data = saml_collect_data()`
|
||||
` if ldap_is_in_directory(user_data):`
|
||||
` raise PermissionDenied`
|
||||
` else:`
|
||||
` return function(request, *args, **kwargs)`
|
||||
` return wrapped`
|
||||
|
||||
|
||||
##### URIs
|
||||
APPEND_SLASH ?
|
||||
"Adding slash to: '/login'"
|
||||
|
||||
#### Modèles
|
||||
Les modèles Django standardisent l'utilisation des objets dans l'application web.
|
||||
Ils reprennent les mécanismes de POO proposés par Python, pour faciliter la mise en place de l'appli Web, et plus particulièrement les mécanismes ORM (*Object-Relational Mapping*).
|
||||
|
||||
La définition de modèles spécifiques à l'application se fait dans le fichier `models.py`. L'utilitaire Django `manage.py` permet la migration en base de données, c'est-à-dire la création des tables associées aux classes définies dans l'appli. Prenons l'exemple du modèle TODOTODOTODO
|
||||
|
||||
#### Templates
|
||||
Langage procédural propre à django à l'intérieur des templates.
|
||||
Il s'agit d'un langage à syntaxe restreintes, permettant d'effectuer des operations d'affichage et des opérations fonctionnelles et logiques simples avant génération de la page html.
|
||||
|
||||
Les templates Django sont un outil plus léger et plus simple d'utilisation que JSP, son équivalent J2E.
|
||||
|
||||
Prenons l'exemple d'un template utilisé pour l'application POC :
|
||||
Fichier login.html :
|
||||
`{% extends "manager_base.html" %}`
|
||||
`{% load i18n %}`
|
||||
`{% block content %}`
|
||||
`<form method="post">`
|
||||
`{% csrf_token %}`
|
||||
`{{ form.as_p }}`
|
||||
`<input type="submit" value="{% trans 'Log in' %}" />`
|
||||
`</form>`
|
||||
`{% endblock %}`
|
||||
|
||||
On remarque par exemple le *one-liner* `{{ form.as_p }}` permettant l'affichage d'un formulaire html à partir des différents attributs d'un objet Django de la classe `Form.forms`.
|
||||
L'ajout du jeton CSRF en tant que balise cachée (*hidden tag*) du formulaire se fait par l'instruction `{% csrf_token %}`
|
||||
|
||||
Le template est ensuite traité par l'instruction `render` dans la vue associée, pour aboutir à la génération d'une page html présentée au client (traitement côté serveur, au même titre que les JSP).
|
||||
|
||||
Finalement, suivant le principe DRY propre à Django, les templates s'appeler les uns les autres à l'aide de la directive `extends`.
|
||||
#### TemplateResponse
|
||||
Dynamise la phase de création de la réponse HTTP après exécution de la vue associée. Fonctionnalité impossible à réaliser à l'aide de simples objets HttpResponse.
|
||||
|
||||
La manipulation des mixins se fait à l'aide de l'objet SingleObjectMixin et de SingleObjectTemplateResponseMixin.
|
||||
TODO Si mixin associé à une ListView, alors MultipleObjectMixin.
|
||||
|
||||
### Remarques
|
||||
L'interface Web d'administration et le compte *superuser* ne sont pas activés par défaut.
|
||||
Page `/admin` pour la gestion des webapps.
|
||||
Opérations CRUD : Create, Read, Update, Delete
|
||||
|
||||
La GUI est générée automatiquement en fonction des modèles de donnée de l'application, pourvu que ceux-ci aient été enregistrés au préalable (méthode `admin.site.register()`)
|
||||
|
||||
Champs `list_display`, `list_filter`, `date_hierarchy`, `ordering` et `search_fields` de la classe `admin.ModelAdmin`
|
||||
|
||||
Classe Q : requêtes avancées -> à lire
|
||||
Appli ContentType pour les relations génériques
|
||||
|
||||
*template context processors*
|
||||
|
||||
*custom tags* utilisant la fonction *render*
|
||||
|
||||
django.db.models.signals
|
||||
|
||||
django.contrib.auth.models.User
|
||||
|
||||
### Coding style
|
||||
* keywork `linebreaks`
|
||||
* `cleaned_data` pour les formulaires
|
||||
|
|
|
|||
|
|
@ -47,6 +47,101 @@ Paul Marillonnet
|
|||
# Prise en main des technologies
|
||||
|
||||
## Django
|
||||
TODO Se documenter sur les templates (modèle MVT)
|
||||
Expliquer philosophie DRY (*Don't Repeat Yourself*)
|
||||
### Principes généraux
|
||||
#### Vues
|
||||
|
||||
##### Class-Based Views (CBV)
|
||||
Nouvelle façon d'écrire des vues
|
||||
Repose sur la définition d'une classe contenant les attributs nécessaires à la construction de la vue et la définition de méthodes correspondant aux requêtes http vers la vue
|
||||
|
||||
Les *mixins* propose, par l'utilisation de l'héritage multiple, un mécanisme voué à éviter la duplication du code dans les CBV.
|
||||
|
||||
##### Decorators
|
||||
La mise en place du POC a nécessité l'utilisation de décorateurs de vue. Ce mécanisme propre à Django permet de restreindre l'affichage d'une vue sous certaines conditions.
|
||||
Des décorateurs sont proposés par défaut dans Django. Ils commencent par `@` et précédent la définition d'une vue dans les sources de l'application. Par exemple:
|
||||
`@csrf_exempt`
|
||||
`def index(request):`
|
||||
` <view logic>`
|
||||
` return wcs_submit(data)`
|
||||
|
||||
Le décorateur `@csrf_exempt` est de type permissif : il stipule que le client (par exemple un navigateur) n'a pas besoin de fournir un jeton CSRF (*csrf token*) pour pouvoir accéder à la vue.
|
||||
|
||||
Au contraire, des décorateurs tels que `@login_required` ou `@require_http_methods` peuvent être de type restrictif.
|
||||
|
||||
Bien que Django fournisse des décorateurs par défaut, ce framework permet aux développeurs de définir les leurs. Un décorateur est une double définition de deux fonctions imbriquées - l'un des deux fonctions devant renvoyer en argument la seconde. Par exemple, nous pouvons définir un décorateur interdisant l'affichage de la vue si le dernier utilisateur connecté possède déjà un compte renseigné dans le LDAP:
|
||||
|
||||
`def user_not_in_ldap(function):`
|
||||
` def wrapped(request, *args, **kwargs):`
|
||||
` user_data = saml_collect_data()`
|
||||
` if ldap_is_in_directory(user_data):`
|
||||
` raise PermissionDenied`
|
||||
` else:`
|
||||
` return function(request, *args, **kwargs)`
|
||||
` return wrapped`
|
||||
|
||||
|
||||
##### URIs
|
||||
APPEND_SLASH ?
|
||||
"Adding slash to: '/login'"
|
||||
|
||||
#### Modèles
|
||||
Les modèles Django standardisent l'utilisation des objets dans l'application web.
|
||||
Ils reprennent les mécanismes de POO proposés par Python, pour faciliter la mise en place de l'appli Web, et plus particulièrement les mécanismes ORM (*Object-Relational Mapping*).
|
||||
|
||||
La définition de modèles spécifiques à l'application se fait dans le fichier `models.py`. L'utilitaire Django `manage.py` permet la migration en base de données, c'est-à-dire la création des tables associées aux classes définies dans l'appli. Prenons l'exemple du modèle TODOTODOTODO
|
||||
|
||||
#### Templates
|
||||
Langage procédural propre à django à l'intérieur des templates.
|
||||
Il s'agit d'un langage à syntaxe restreintes, permettant d'effectuer des operations d'affichage et des opérations fonctionnelles et logiques simples avant génération de la page html.
|
||||
|
||||
Les templates Django sont un outil plus léger et plus simple d'utilisation que JSP, son équivalent J2E.
|
||||
|
||||
Prenons l'exemple d'un template utilisé pour l'application POC :
|
||||
Fichier login.html :
|
||||
`{% extends "manager_base.html" %}`
|
||||
`{% load i18n %}`
|
||||
`{% block content %}`
|
||||
`<form method="post">`
|
||||
`{% csrf_token %}`
|
||||
`{{ form.as_p }}`
|
||||
`<input type="submit" value="{% trans 'Log in' %}" />`
|
||||
`</form>`
|
||||
`{% endblock %}`
|
||||
|
||||
On remarque par exemple le *one-liner* `{{ form.as_p }}` permettant l'affichage d'un formulaire html à partir des différents attributs d'un objet Django de la classe `Form.forms`.
|
||||
L'ajout du jeton CSRF en tant que balise cachée (*hidden tag*) du formulaire se fait par l'instruction `{% csrf_token %}`
|
||||
|
||||
Le template est ensuite traité par l'instruction `render` dans la vue associée, pour aboutir à la génération d'une page html présentée au client (traitement côté serveur, au même titre que les JSP).
|
||||
|
||||
Finalement, suivant le principe DRY propre à Django, les templates s'appeler les uns les autres à l'aide de la directive `extends`.
|
||||
#### TemplateResponse
|
||||
Dynamise la phase de création de la réponse HTTP après exécution de la vue associée. Fonctionnalité impossible à réaliser à l'aide de simples objets HttpResponse.
|
||||
|
||||
La manipulation des mixins se fait à l'aide de l'objet SingleObjectMixin et de SingleObjectTemplateResponseMixin.
|
||||
TODO Si mixin associé à une ListView, alors MultipleObjectMixin.
|
||||
|
||||
### Remarques
|
||||
L'interface Web d'administration et le compte *superuser* ne sont pas activés par défaut.
|
||||
Page `/admin` pour la gestion des webapps.
|
||||
Opérations CRUD : Create, Read, Update, Delete
|
||||
|
||||
La GUI est générée automatiquement en fonction des modèles de donnée de l'application, pourvu que ceux-ci aient été enregistrés au préalable (méthode `admin.site.register()`)
|
||||
|
||||
Champs `list_display`, `list_filter`, `date_hierarchy`, `ordering` et `search_fields` de la classe `admin.ModelAdmin`
|
||||
|
||||
Classe Q : requêtes avancées -> à lire
|
||||
Appli ContentType pour les relations génériques
|
||||
|
||||
*template context processors*
|
||||
|
||||
*custom tags* utilisant la fonction *render*
|
||||
|
||||
django.db.models.signals
|
||||
|
||||
django.contrib.auth.models.User
|
||||
|
||||
|
||||
## w.c.s / Passerelle
|
||||
|
||||
|
|
|
|||
Reference in New Issue