Better table of content

This commit is contained in:
jaguarondi 2015-10-28 13:56:18 +01:00
parent 6f3350156c
commit 275473853b
4 changed files with 22 additions and 12 deletions

View File

@ -4,7 +4,8 @@
* [Avant-propos](intro-01-prerequisites.md)
* [Une application Django](intro-02-create-django-app.md)
* [Avant d'aller plus loin](intro-03-before-going-further.md)
* [Gwift](gwift/specs.md)
* [Gwift](gwift/README.md)
* [Besoins](gwift/specs.md)
* [Modèle](gwift/01-models.md)
* [Vues](gwift/02-views.md)
* [URLs](gwift/03-urls.md)

View File

@ -30,6 +30,8 @@ class Part(models.Model):
Les classes sont créées, mais vides. Entrons dans les détails.
[Ajouter pourquoi on hérite de `models.Model`, etc.)
## Listes de souhaits
Comme déjà décrit précédemment, les listes de souhaits peuvent s'apparenter simplement à un objet ayant un nom et une description. Pour rappel, voici ce qui avait été défini dans les spécifications:
@ -71,7 +73,7 @@ A présent, notre classe
## Refactoring
On constate que chaque classe possède les propriétés `created_at` et `updated_at`, initialisées aux mêmes valeurs. Pour gagner en cohérence, nous allons créer une classe dans laquelle nous définirons ces deux champs, et nous ferons en sorte que les classes `Wishlist`, `Item` et `Part` en héritent. Django gère trois sortes d'héritage:
On constate que plusieurs classes possèdent les propriétés `created_at` et `updated_at`, initialisées aux mêmes valeurs. Pour gagner en cohérence, nous allons créer une classe dans laquelle nous définirons ces deux champs, et nous ferons en sorte que les classes `Wishlist`, `Item` et `Part` en héritent. Django gère trois sortes d'héritage:
1. L'héritage par classe abstraite
1. L'héritage classique

12
book/gwift/README.md Normal file
View File

@ -0,0 +1,12 @@
Gwift
=====
Pour commencer, nous allons nous concentrer sur la création d'un site ne contenant qu'une seule application, même si en pratique le site contiendra déjà plusieurs applications fournies pas django, comme nous le verrons plus loin.
Pour prendre un exemple concret, nous allons créer un site permettant de gérer des listes de souhaits, que nous appellerons `gwift` (pour `GiFTs and WIshlisTs` :)).
La première chose à faire est de définir nos besoins du point de vue de l'utilisateur, c'est-à-dire ce que nous souhaitons qu'un utilisateur puisse faire avec l'application.
Ensuite, nous pourrons traduire ces besoins en fonctionnalités et finalement effectuer le développement

View File

@ -1,16 +1,11 @@
Single App
==========
Besoins
=======
Pour commencer, nous allons nous concentrer sur la création d'un site ne contenant qu'une seule application, même si en pratique le site contiendra déjà plusieurs applications fournies pas django, comme nous le verrons plus loin.
[A remplir]
Pour prendre un exemple concret, nous allons créer un site permettant de gérer des listes de souhaits, que nous appellerons `gwift` (pour `GiFTs and WIshlisTs` :)).
La première chose à faire est de définir nos besoins du point de vue de l'utilisateur, c'est-à-dire ce que nous souhaitons qu'un utilisateur puisse faire avec l'application.
Ensuite, nous pourrons traduire ces besoins en fonctionnalités et finalement effectuer le développement
Besoins utilisateur du site gwift
---------------------------------
Besoins utilisateur
-------------------
Nous souhaitons développer un site où un utilisateur donné peut créer une liste contenant des souhaits et où d'autres utilisateurs, authentifiés ou non, peuvent choisir les souhaits qu'ils souhaitent réaliser.
Il sera nécessaire de s'authentifier pour :