Revue de l'application communication #7

Fred · 2020-10-19T21:44:44+02:00

Fred commented

2020-10-19 21:44:44 +02:00

Au niveau du modèle

Les champs message_body et message_title me posent problème, parce qu'on est déjà dans la classe Message. Pourquoi pas juste title et body ?
Le champ is_read est superflu. Si on veut savoir si le message est lu, il suffit de faire une méthode avec un décorateur @property et retourner si date_of_reading est vide.
Par convention, j'aurais appelé les champs writer et reader plutôt sender et recipient.
Pareil pour les champs "date" auto-remplis. J'aime bien les conventions type <nom_du_champ>_at.()
(Ici, written_at et read_at).
Est-ce qu'un message ne peut pas être envoyé à plusieurs personnes en même temps ?
Tes related_names ne sont pas corrects: have_write et have_read n'ont pas de signification. Quand on a une instance d'un utilisateur en main, ça reviendrait à faire user_instance.have_read.all.

Sémantiquement, c'est pas top. Il faudrait plutôt les appeler sent_messages et received_messages. Dans le code, cela donnerait user_instance.sent_messages.all() ou user_instance.sent_messages.filter(...).

Est-ce qu'un Message ne devrait pas être Markdownizable ? Mais alors le champ information devrait s'appeler content ou quelque chose de plus générique.

URLs

Attention à bien les nommer

Dans les vues

Il y a quelques points de simplication qui sont en lien avec le modèle.
Attention aussi à bien nommer les vues.
Est-ce que l'appli est en anglais ou en français ? Il y a certains messages qui sont mal traduits.
Voir aussi à utiliser les bons verbes Http, et à faire les vérifications correctes avant une action (une suppression, par exemple)

## Au niveau du modèle * Les champs `message_body` et `message_title` me posent problème, parce qu'on est déjà dans la classe `Message`. Pourquoi pas juste `title` et `body` ? * Le champ `is_read` est superflu. Si on veut savoir si le message est lu, il suffit de faire une méthode avec un décorateur @property et retourner si `date_of_reading` est vide. * Par convention, j'aurais appelé les champs `writer` et `reader` plutôt `sender` et `recipient`. * Pareil pour les champs "date" auto-remplis. J'aime bien les conventions type `<nom_du_champ>_at`.() (Ici, `written_at` et `read_at`). * Est-ce qu'un message ne peut pas être envoyé à plusieurs personnes en même temps ? * Tes related_names ne sont pas corrects: `have_write` et `have_read` n'ont pas de signification. Quand on a une instance d'un utilisateur en main, ça reviendrait à faire `user_instance.have_read.all`. Sémantiquement, c'est pas top. Il faudrait plutôt les appeler `sent_messages` et `received_messages`. Dans le code, cela donnerait `user_instance.sent_messages.all()` ou `user_instance.sent_messages.filter(...)`. * Est-ce qu'un `Message` ne devrait pas être `Markdownizable` ? Mais alors le champ `information` devrait s'appeler `content` ou quelque chose de plus générique. ## URLs * Attention à bien les nommer ## Dans les vues * Il y a quelques points de simplication qui sont en lien avec le modèle. * Attention aussi à bien nommer les vues. * Est-ce que l'appli est en anglais ou en français ? Il y a certains messages qui sont mal traduits. * Voir aussi à utiliser les bons verbes Http, et à faire les vérifications correctes avant une action (une suppression, par exemple)

Fred added the

enhancement

label 2020-10-19 21:45:05 +02:00

Sulley was assigned by Fred

2020-10-20 10:56:45 +02:00

Fred changed title from ~~[WIP] Revue de l'application `communication`~~ to Revue de l'application `communication`

2020-10-26 10:45:16 +01:00

Sulley closed this pull request

2020-10-26 10:45:41 +01:00

Sign in to join this conversation.

No reviewers