Ce que vous devez faire lorsque vous commencez à développer avec Django. Il sera difficile de le changer plus tard, il peut donc être préférable de le régler au stade initial, mais pas toujours. ** Créez "Paramètres de nom de répertoire de paramètres contenant settings.py" ** et ** "Modèle utilisateur étendu" **.
Il peut y avoir beaucoup d'autres choses, mais sous forme de mémorandum à ce stade.
――Les personnes qui viennent de terminer le matériel didactique de Django et sont sur le point de commencer à créer des applications.
Il s'agit d'une mesure pour faciliter la compréhension de la structure des répertoires du projet.
Si vous démarrez normalement la création de projet en tant que $ django-admin startproject myproject, le nom du répertoire de base et le nom du répertoire de réglage seront créés avec le même nom ( myproject dans ce cas), il sera donc difficile de les distinguer. Je vais.
Cela signifie que lorsque vous commencez à créer un projet avec cette commande, vous aurez une structure de répertoires comme celle-ci.
myproject <-Répertoire de base
|-- manage.py
`-- myproject <-Répertoire de configuration
|-- __init__.py
|-- settings.py
|-- urls.py
|-- manage.py
`-- wsgi.py
Il existe un répertoire de base avec le même nom que le nom du projet (myproject dans ce cas), et un répertoire de configuration avec le même nom y est créé.
(Soit dit en passant, [manuel Django << bases >> qui peut être utilisé sur le terrain] utilisé pour l'apprentissage [https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81] % A7% E4% BD% BF% E3% 81% 88% E3% 82% 8B-Django-% E3% 81% AE% E6% 95% 99% E7% A7% 91% E6% 9B% B8% E3% 80% 8A% E5% 9F% BA% E7% A4% 8E% E7% B7% A8% E3% 80% 8B-% E6% A8% AA% E7% 80% AC-% E6% 98% 8E% E4% Dans les livres de BB% 81 / dp / 4802094744), il est facile de distinguer
--Base directory = Répertoire du projet créé par django-admin startproject
--Settings directory = Répertoire avec settings.py
Puisqu'il est appelé, je suivrai ce nom)
Lors de la création d'un projet, créez un répertoire de base avec un nom arbitraire (nom du projet), déplacez-le vers le bas du répertoire de base, spécifiez le nom du répertoire de configuration (ici config) dans le premier argument et spécifiez . dans le deuxième argument. Ensuite, lancez start project.
$mkdir myproject (entrez le nom du projet ici)
$ cd myproject/
$ django-admin startproject config .
En faisant cela, la structure de répertoires
myproject <-Répertoire de base
|-- manage.py
`-- config <-Répertoire de configuration*Ce nom change
|-- __init__.py
|-- settings.py
|-- urls.py
|-- manage.py
`-- wsgi.py
C'est ainsi que la structure est facile à comprendre.
Django a un modèle User par défaut, ce qui facilite l'implémentation des fonctions de connexion et ainsi de suite. Cela seul est très pratique, mais afin de rendre le modèle utilisateur plus facile à utiliser, il est [officiellement recommandé] de créer un modèle utilisateur personnalisé [https://docs.djangoproject.com/ja/2.0/topics/ auth / customizing / # using-a-custom-user-model-when-starting-a-project).
Il existe trois manières principales d'étendre le modèle utilisateur.
Chaque méthode a ses avantages et ses inconvénients, Si le développement progresse et qu'il y a déjà des données dans la base de données, la méthode 3 semble bonne. 1 ou 2 est recommandé à la première étape du démarrage de la production de l'application, mais 1 semble être difficile pour les débutants aux débutants, il est donc prudent de s'habituer à la méthode 2 au début.
La méthode 2 vous permet d'ajouter vos propres colonnes à votre modèle utilisateur.
Il est facile de créer un modèle utilisateur personnalisé.
① Décrit dans ʻapp / models.py (ʻapp est le nom du répertoire de l'application)
② Définissez ʻAUTH_USER_MODEL dans config / settings.py (config` est le nom du répertoire de configuration créé lors de la création du projet)
③ Migrer
models.pyDéfinissez ici un modèle utilisateur personnalisé. (Puisque les informations qui sont à la base du modèle utilisateur sont définies dans le modèle appelé ʻAbstractUser`, elles seront héritées et utilisées.)
Ici, vous pouvez spécifier le nom de la table et les colonnes que vous souhaitez ajouter.
Par exemple, vous pouvez définir une table appelée custome_user avec une colonne appelée Calendar avec une clé externe.
app/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models
class CustomUser(AbstractUser):
class Meta(AbstractUser.Meta):
db_table = 'custom_user'
swappable = 'AUTH_USER_MODEL'
calendar = models.ForeignKey(Calendar, verbose_name='Calendrier actif', on_delete=models.PROTECT, blank=True, null=True)
Puisqu'il s'agit d'un exemple de mon code réel, j'ai lié un modèle appelé «Calendrier» au modèle utilisateur, mais si vous souhaitez que le modèle utilisateur ait le sexe, l'âge, l'adresse e-mail, le mot de passe, etc., spécifiez la colonne ici. Je pense que tu devrais me le donner. Étant donné que la colonne est ajoutée au modèle utilisateur par défaut, la colonne d'origine reste (voir MEMO à la fin de cet article pour le contenu du modèle utilisateur par défaut).
dans settings.py`Définissez ici le modèle utilisateur personnalisé à utiliser. Décrire comme "nom de l'application.nom du modèle"
config/settings.py
AUTH_USER_MODEL = app.CustomUser
Si vous modifiez le modèle, vous pouvez migrer la base de données standard.
$ Python manage.py makemigrations
$ Python manage.py migrate
Concernant la version à spécifier, il ne semble pas y avoir d'erreur si vous adoptez la version qui correspond à ** LTS (Long-Term Support) ** (= version avec support de sécurité à long terme).
--2.2 => Support jusqu'en avril 2022 --1.11 => Support jusqu'en avril 2020
À propos, la série Django 3 est sortie en décembre 2019, mais la version 3.2, qui correspond à LTS, devrait sortir en avril 2021.
S'il n'y a pas de raison particulière, est-il correct de commencer avec la dernière LTS pour le moment? C'est une impression. (Si la destination de déploiement a été choisie, il peut être nécessaire de vérifier si le serveur la prend en charge)
Django a le concept de «projet» et d '«application», alors organisons-le un peu.
projet
Toute l'application WEB à réaliser.
$ django-admin startproject myproject
Celui créé par la commande (myproject est le nom du projet)
application
Un groupe de petites fonctions appartenant à un projet
python3 manage.py startapp myapp
Celui créé par la commande (myapp est le nom de l'application)
Lors de la création d'un service WEB, créez un projet et, s'il s'agit d'un petit service, créez-y une application et implémentez-la. Au fur et à mesure que l'échelle d'un projet augmente, il est possible de créer et d'exploiter plusieurs applications dans un même projet.
Lors de la création de plusieurs applications, il semble que la maintenance soit plus facile si vous considérez cela.
Après avoir terminé le matériel pédagogique de type tutoriel, je l'ai présenté en cours de route.
[Manuel Django << bases >> utilisable sur le terrain](https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81%A7%E4%BD%BF% E3% 81% 88% E3% 82% 8B-Django-% E3% 81% AE% E6% 95% 99% E7% A7% 91% E6% 9B% B8% E3% 80% 8A% E5% 9F% BA % E7% A4% 8E% E7% B7% A8% E3% 80% 8B-% E6% A8% AA% E7% 80% AC-% E6% 98% 8E% E4% BB% 81 / dp / 4802094744)
Ce livre est très simple à comprendre et fait progresser votre étude!
Il couvre un large éventail de bases et est bon pour établir et comprendre les connaissances. Vous pouvez lire en mangeant une pincée. Bon nombre des meilleures méthodes résumées cette fois-ci sont publiées, et elles sont très utiles.
Pour référence, les champs du modèle User confirmé dans Django 2.1.7 sont listés. Le modèle User par défaut hérite du modèle AbstractUser, de sorte que les noms de colonne dans le modèle AbstractUser seront hérités lorsque vous créez un modèle utilisateur personnalisé.
lib/django/contrib/auth/models.py
class AbstractUser(AbstractBaseUser, PermissionsMixin):
"""
An abstract base class implementing a fully featured User model with
admin-compliant permissions.
Username and password are required. Other fields are optional.
"""
username_validator = UnicodeUsernameValidator()
username = models.CharField(
_('username'),
max_length=150,
unique=True,
help_text=_('Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only.'),
validators=[username_validator],
error_messages={
'unique': _("A user with that username already exists."),
},
)
first_name = models.CharField(_('first name'), max_length=30, blank=True)
last_name = models.CharField(_('last name'), max_length=150, blank=True)
email = models.EmailField(_('email address'), blank=True)
is_staff = models.BooleanField(
_('staff status'),
default=False,
help_text=_('Designates whether the user can log into this admin site.'),
)
is_active = models.BooleanField(
_('active'),
default=True,
help_text=_(
'Designates whether this user should be treated as active. '
'Unselect this instead of deleting accounts.'
),
)
date_joined = models.DateTimeField(_('date joined'), default=timezone.now)
objects = UserManager()
EMAIL_FIELD = 'email'
USERNAME_FIELD = 'username'
REQUIRED_FIELDS = ['email']
class Meta:
verbose_name = _('user')
verbose_name_plural = _('users')
abstract = True
def clean(self):
super().clean()
self.email = self.__class__.objects.normalize_email(self.email)
def get_full_name(self):
"""
Return the first_name plus the last_name, with a space in between.
"""
full_name = '%s %s' % (self.first_name, self.last_name)
return full_name.strip()
def get_short_name(self):
"""Return the short name for the user."""
return self.first_name
def email_user(self, subject, message, from_email=None, **kwargs):
"""Send an email to this user."""
send_mail(subject, message, from_email, [self.email], **kwargs)
class User(AbstractUser):
"""
Users within the Django authentication system are represented by this
model.
Username and password are required. Other fields are optional.
"""
class Meta(AbstractUser.Meta):
swappable = 'AUTH_USER_MODEL'
Recommended Posts