From 555e34a84ef7a477a493214bbc16517809d5b59c Mon Sep 17 00:00:00 2001 From: Fred Pauchet Date: Mon, 14 Sep 2015 21:09:30 +0200 Subject: [PATCH] add existing notes --- README.md | 10 ++++++++++ admin.md | 35 +++++++++++++++++++++++++++++++++++ annex/legacy.md | 9 +++++++++ patterns.md | 23 +++++++++++++++++++++++ 4 files changed, 77 insertions(+) create mode 100644 annex/legacy.md create mode 100644 patterns.md diff --git a/README.md b/README.md index e69de29..6d90c91 100644 --- a/README.md +++ b/README.md @@ -0,0 +1,10 @@ +# Django + +[Django](https://www.djangoproject.com/) est l'un des frameworks Web proposant une très bonne intégration des composants, et une flexibilité bien pensée: chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes logiques et faciles à retenir. + +En restant dans les sentiers battus, votre projet suivra le patron de conception `MVC` (Modèle-Vue-Controleur), avec une petite variante sur les termes utilisés: Django les nomme respectivement Modèle-Template-Vue: + + * Le modèle (`models.py`) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. *Grosso modo*, une table SQL correspondra à une classe d'un modèle Django. + * La vue (`views.py`), qui joue le rôle de contrôleur: *a priori*, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l'affichage d'une page. + * Le template, qui s'occupe de la mise en forme: c'est le composant qui va s'occuper de transformer les données en un affichage compréhensible (avec l'aide du navigateur) pour l'utilisateur. + diff --git a/admin.md b/admin.md index 8c000ca..0161960 100644 --- a/admin.md +++ b/admin.md @@ -1 +1,36 @@ # Administration + +Un schéma relationnel demande à l'utilisateur de définir un ensemble de tables, permettant de représenter et stocker de l'information de manière pérenne. Plus précisément, chacune de ces tables devra + + +L'ORM de Django permet de définir travailler uniquement avec une définition de classes, et de faire en sorte que le lien avec la base de données soit géré uniquement de manière indirecte, par Django lui-même. On peut schématiser ce comportement par une classe = une table + +Lors de la définition d'une nouvelle classe, et puisque l'ORM se base sur Active Records, il peut être intéressant de définir une valeur pour les options suivantes: + + * `def __str__(self)`: retournera une chaîne de caractère pour toute instance de la classe + * `def get_absolute_url(self) : retourne l'URI à laquelle on peut envoyer une requête pour obtenir le maximum d'informations concernant cette instance. Par exemple: `return reverse('myapp.views.details', args=[self.id])`. Lorsqu'on en aura besoin, il suffira d'appeler cette méthode pour atterrir d'office sur la bonne page + * class Meta: + * ordering = ['-field1', 'field2'] + * verbose_name = 'my class in singular' + * verbose_name_plural = 'my class when is in a list!' + +Titre +----- + +Le titre de l'administration peut être modifié de deux manières: + + 1. Soit en modifiant le template de l'administration + 2. Soit en ajoutant l'assignation suivante dans le fichier `urls.py`: `admin.site.site_header = "SuperBook Secret Area`. + +Greffons +-------- + +L'interface d'administration est extensible dans une certaine mesure. Notamment utiliser django_extensions pour avoir les ForeignKey auto-complétées. + +# Autre + +# Administration + +L'administration de Django est l'une des fonctionnalités qui saute le plus au yeux lorsqu'on présente le framework à un nouveau-venu: sur base du modèle défini dans les différentes applications, Django peut générer automagiquement les formulaires d'entrée de données, les pages de listing, des fonctions de recherche, ... Tout ça avec très très peu de lignes de code. + +L'un des problèmes par contre est que cette partie d'administration n'est pas destinée aux utilisateurs: c'est plus pour un *super-utilisateur* ou un gestionnaire que pour un utilisateur *lambda*. diff --git a/annex/legacy.md b/annex/legacy.md new file mode 100644 index 0000000..69cc5ce --- /dev/null +++ b/annex/legacy.md @@ -0,0 +1,9 @@ +Quand on intègre une nouvelle application Django dans un environement existant, la première étape est de se câbler sur la base de données existantes; + + 1. Soit l'application sur laquelle on se greffe restera telle quelle; + 2. Soit l'application est **remplacée** par la nouvelle application Django. + + Dans le premier cas, il convient de créer une application et de spécifier pour chaque classe l'attribute `managed = False` dans le `class Meta:` de la définition. + Dans le second, il va falloir câbler deux-trois éléments avant d'avoir une intégration complète (comprendre: avec une interface d'admin, les migrations, les tests unitaires et tout le brol :)) + + `python manage.py inspectdb > models.py` diff --git a/patterns.md b/patterns.md new file mode 100644 index 0000000..338d994 --- /dev/null +++ b/patterns.md @@ -0,0 +1,23 @@ +The CRUD views themselves are simple enough to be self-explanatory, as shown in +the following code: + +```python +# views.py +from django.core.urlresolvers import reverse_lazy +from . import forms + +class ImpDateDetail(generic.DetailView): + model = models.ImportantDate + + class ImpDateCreate(generic.CreateView): + model = models.ImportantDate + form_class = forms.ImportantDateForm + + class ImpDateUpdate(generic.UpdateView): + model = models.ImportantDate + form_class = forms.ImportantDateForm + + class ImpDateDelete(generic.DeleteView): + model = models.ImportantDate + success_url = reverse_lazy("impdate_list") +```