Salut à vous ! 😄
Quelques remarques préliminaires après un petit survol de votre code et test de votre projet en local. Sachant que c'est encore en cours de dev, je n'ai pas tout analysé en détail, il y a donc peut-être des éléments sur lesquels vous travaillez déjà. Toutes ces infos sont à titre indicatif.
Vous utilisez le framework correctement. Content de voir que vous avez pensé à utiliser les vues génériques basées sur les classes. Utilisation des forms, register de modèles sur l'admin django. Bonne utilisation des templates, etc. Globalement ça se passe bien c'est top 👍
Je vous mets ci-dessous quelques pistes/idées si vous voulez (et avez le temps) pousser les choses un peu plus loin :
Fixtures pour données de base
Pour Eduardo, un site avec une base de catégories sûrement communes à tous les utilisateurs, je vous recommanderais de faire des "fixtures" pour faciliter le seeding de la DB au premier setup. Pour rappel : python manage.py dumpdata. On pourrait même imaginer une seconde fixture avec des articles pour avoir des données d'exemple (!= des données de base, nécessaire au "fonctionnement" de l'app, comme les catégories).
Dépendances python
Comme vous le dites dans votre README, j'ai du réinstaller les dépendances python utilisées par votre projet avec des pipenv install django-crispy-forms et pipenv install pillow.
Pour rappel, le fichier requirements.txt (si vous utilisez virtualenv) ou Pipfile (si vous utilisez pipenv, recommandé) vous permet d'éviter à réinstaller les dépendances manuellement à chaque setup.
Pour ça, il faut freezer vos dépendances une fois qu'elles sont installées en local -> pip freeze > requirements.txt.
Comme ça, au lieu de faire des pip install ... pip install ... pip install ... on ne fait qu'un seul pip install -r requirements.txt
Cohérence dans views.py
C'est top d'avoir utilisé des generic views basées sur les classes. Cependant, vous avez des vues qui restent basées sur les fonctions (def register et def vendre). L'idée étant ici de rester cohérent et de passer toutes vos vues en class based (méthode recommandée par django dans la doc officielle)
(pseudo-code écris de tête) Ainsi, à la place de
def register(...)
if response.method == "POST":
...
On aura plutôt
Class Register(generic.View):
def post(self, request):
...
Et à la place de
def vendre(response):
return render(response, "eduardoApp/vendre.html")
plutôt
Class Vendre(generic.TemplateView):
template = "eduardoApp/vendre.html"
C'est aussi légèrement plus évolutif 😉
sqlite
Attention à ne pas utiliser sqlite en prod, ce n'est pas recommandé (db engine mono user) !
Dépendances frontend
Détail mais bootstrap induit 3-4 dépendances frontend (popper.js, jquery) que vous utilisez via cdn. C'est ok mais si vous deviez avoir plus de dépendances, il commencerait à devenir intéressant de passer par un gestionnaire de package js tel que npm pour les inclure à votre projet. Quelques infos.
Pour rappel, pas besoin de mettre en place tout ça dans votre projet mais si vous trouvez néanmoins le temps d'en faire qq uns, ce seront de grand plus 😉
à dispo si besoin
Excellente continuation à vous ! 😄
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent