Un fichier par modèle pour la lisibilité et l’organisation.
Cf assets/diagramme_1.png pour l’héritage des modèles.
Attention, quelques changements qui n’ont pas encore été pris en compte :
il a été décidé que les tests hériteront aussi de Post.
La gestion des permissions des différents forums se fera au travers de la classe Forum.
Il est préférable de créer des primitives qui ne checkent pas les droits, puis ensuite d’ajouter des méthodes “safe”, pour une question de logique/lisibilité.
Liste des modèles à créer :
- [x] `Comment`
- [x] `Topic`
- [ ] `Tutorial`
- [ ] `Program`
- [ ] `Test`
Un fichier par modèle pour la lisibilité et l'organisation.
Cf `assets/diagramme_1.png` pour l'héritage des modèles.
Attention, quelques changements qui n'ont pas encore été pris en compte :
- il a été décidé que les tests hériteront aussi de `Post`.
La gestion des permissions des différents forums se fera au travers de la classe `Forum`.
Il est préférable de créer des primitives qui ne checkent pas les droits, puis ensuite d'ajouter des méthodes "safe", pour une question de logique/lisibilité.
Concernant les interactions entre les topics, programmes, tutoriels et autres assets graphiques, on est tombés d’accord avec Darks sur les mécanismes suivants.
Les topics sont les sujets les plus généraux, ils peuvent être promus en programmes, tutoriels ou assets graphiques par publication. L’idée est qu’on projet qui démarre comme un topic peut ensuite être publié sans perdre son fil de commentaires. Objectif un seul thread par projet (sauf projets majeurs faisant couler beaucoup d’encre et de publications.)
Lors d’une promotion, l’URL du topic originel est toujours accessible et redirige vers le nouveau contenu. (On peut également continue de lister le topic dans son forum d’origine - à discuter.)
Pour l’implémentation, ça se passe comme suit.
Les programmes, tutoriels et assets graphiques possèdent un Thread en attribut qui est destiné à accueillir soit un nouveau thread, soit le thread d’un topic existant lors de la création.
Lors d’une promotion de topic, l’objet Topic est conservé mais est affublé d’une référence au contenu qui l’a remplacé vu comme un Post polymorphe. La vue de topic produit une redirection si cette référence existe (possiblement avec une petite note, comme les redirections sur les Wikis).
Concernant les interactions entre les topics, programmes, tutoriels et autres assets graphiques, on est tombés d'accord avec Darks sur les mécanismes suivants.
* Les topics sont les sujets les plus généraux, ils peuvent être promus en programmes, tutoriels ou assets graphiques par publication. L'idée est qu'on projet qui démarre comme un topic peut ensuite être publié sans perdre son fil de commentaires. Objectif un seul thread par projet (sauf projets majeurs faisant couler beaucoup d'encre et de publications.)
* Lors d'une promotion, l'URL du topic originel est toujours accessible et redirige vers le nouveau contenu. (On peut également continue de lister le topic dans son forum d'origine - à discuter.)
Pour l'implémentation, ça se passe comme suit.
1. Les programmes, tutoriels et assets graphiques possèdent un `Thread` en attribut qui est destiné à accueillir soit un nouveau thread, soit le thread d'un topic existant lors de la création.
2. Lors d'une promotion de topic, l'objet `Topic` est conservé mais est affublé d'une référence au contenu qui l'a remplacé vu comme un `Post` polymorphe. La vue de topic produit une redirection si cette référence existe (possiblement avec une petite note, comme les redirections sur les Wikis).
Note supplémentaire concernant les backrefs vers les Post, Topic, Program etc. Il n’est pas acceptable de backref tous les posts vers Member.post puis d'écrire des choses comme [p for p in member.posts if p.type == 'program'] parce que la complexité est terrible.
À la place, il faut mettre en place une backref dédiée de (par exemple) Program vers Member.programs, sachant qu’une existe déjà de vers Member.posts puisque Program est une variante polymorphe de Post.
Deux solutions sont envisagées à ce stade :
Créer une nouvelle relation dans Program, par exemple program_author. Dans ce cas Member.posts continue de contenir tous les programmes.
Remplacer le author dans Program pour écraser la version héritée de Post et backref vers Member.programs. Dans ce cas Member.posts ne contient plus les programmes.
Comme les programmes, tutoriels et autres ne peuvent pas être publiés par des invités (contrairement au topic), on veut remplacer à la fois author_id et author dans les sous-classes de Post qui ne sont accessibles qu’aux membres.
Dans ce cas, Post.author peut être un User ou un Member, mais dans le contexte des posts génériques on s’en moque car les deux se comportent comme des User grâce à l’héritage de Python, et dans le contexte des programmes spécifiquement on a la garantie qu’on a un Member parce que le modèle est défini de cette façon.
Pour citer Darks :
C’est subtil le beau code hein ?
Note supplémentaire concernant les backrefs vers les Post, Topic, Program etc. Il n'est pas acceptable de backref tous les posts vers `Member.post` puis d'écrire des choses comme `[p for p in member.posts if p.type == 'program']` parce que la complexité est terrible.
À la place, il faut mettre en place une backref dédiée de (par exemple) `Program` vers `Member.programs`, sachant qu'une existe déjà de vers `Member.posts` puisque `Program` est une variante polymorphe de `Post`.
Deux solutions sont envisagées à ce stade :
1. Créer une nouvelle relation dans `Program`, par exemple `program_author`. Dans ce cas `Member.posts` continue de contenir tous les programmes.
2. Remplacer le `author` dans `Program` pour écraser la version héritée de `Post` et backref vers `Member.programs`. Dans ce cas `Member.posts` ne contient plus les programmes.
Comme les programmes, tutoriels et autres ne peuvent pas être publiés par des invités (contrairement au topic), on veut remplacer à la fois `author_id` et `author` dans les sous-classes de `Post` qui ne sont accessibles qu'aux membres.
Dans ce cas, `Post.author` peut être un `User` ou un `Member`, mais dans le contexte des posts génériques on s'en moque car les deux se comportent comme des `User` grâce à l'héritage de Python, et dans le contexte des programmes spécifiquement on a la garantie qu'on a un `Member` parce que le modèle est défini de cette façon.
Pour citer Darks :
> C'est subtil le beau code hein ?
La question des backrefs des types spécialisés de posts vers les utilisateurs est a priori réglée, Darks ayant trouvé que
my_programs = db.relationship("Program")
collecte automatiquement tous les programmes en relation avec l’utilisateur considéré, ce qui implémente élégamment la solution envisagée avec l’héritage.
La question des backrefs des types spécialisés de posts vers les utilisateurs est a priori réglée, Darks ayant trouvé que
```
my_programs = db.relationship("Program")
```
collecte automatiquement tous les programmes en relation avec l'utilisateur considéré, ce qui implémente élégamment la solution envisagée avec l'héritage.
Voilà un début, le modèle des programmes avec promotions de topics devrait être bon. Il faut encore tester, ce qui sera plus facile une fois qu’on aura complété le forum (et notamment de quoi modifier les commentaires et topics) donc on y reviendra un peu plus tard.
Voilà un début, le modèle des programmes avec promotions de topics devrait être bon. Il faut encore tester, ce qui sera plus facile une fois qu'on aura complété le forum (et notamment de quoi modifier les commentaires et topics) donc on y reviendra un peu plus tard.
127c121eb4 implémente l'édition des commentaires pour les cas les plus simples. C’est juste la fonctionnalité pure, il manque pas mal de détails :
Modification pour les invités
Redirection propre (on ne peut pas savoir quel Topic/Program/etc contient le Comment actuellement)
Gestion des permissions d’accès au forum où le topic se trouve, si Topic (pour le modérateur qui tente d’accéder à l’URL)
Support des topics/programmes/etc
https://gitea.planet-casio.com/devs/PCv5/commit/127c121eb4d1986e006e8b270ba1fd98fcb7274a implémente l'édition des commentaires pour les cas les plus simples. C'est juste la fonctionnalité pure, il manque pas mal de détails :
* Modification pour les invités
* Redirection propre (on ne peut pas savoir quel Topic/Program/etc contient le Comment actuellement)
* Gestion des permissions d'accès au forum où le topic se trouve, si Topic (pour le modérateur qui tente d'accéder à l'URL)
* Support des topics/programmes/etc
Darks
Lephenixnoir
Liste des modèles à créer :
Un fichier par modèle pour la lisibilité et l’organisation. Cf
assets/diagramme_1.pngpour l’héritage des modèles.Attention, quelques changements qui n’ont pas encore été pris en compte :
Post.La gestion des permissions des différents forums se fera au travers de la classe
Forum.Il est préférable de créer des primitives qui ne checkent pas les droits, puis ensuite d’ajouter des méthodes “safe”, pour une question de logique/lisibilité.
Je commence à créer les modèles
CommentetTopic.Ah, tu m’as pris de court du coup. Je vais attendre que tu commites pour y aller...
Mis à jour. Il reste les programmes tuto et tests à faire. Éventuellement les assets si on part sur un truc du style
Concernant les interactions entre les topics, programmes, tutoriels et autres assets graphiques, on est tombés d’accord avec Darks sur les mécanismes suivants.
Les topics sont les sujets les plus généraux, ils peuvent être promus en programmes, tutoriels ou assets graphiques par publication. L’idée est qu’on projet qui démarre comme un topic peut ensuite être publié sans perdre son fil de commentaires. Objectif un seul thread par projet (sauf projets majeurs faisant couler beaucoup d’encre et de publications.)
Lors d’une promotion, l’URL du topic originel est toujours accessible et redirige vers le nouveau contenu. (On peut également continue de lister le topic dans son forum d’origine - à discuter.)
Pour l’implémentation, ça se passe comme suit.
Les programmes, tutoriels et assets graphiques possèdent un
Threaden attribut qui est destiné à accueillir soit un nouveau thread, soit le thread d’un topic existant lors de la création.Lors d’une promotion de topic, l’objet
Topicest conservé mais est affublé d’une référence au contenu qui l’a remplacé vu comme unPostpolymorphe. La vue de topic produit une redirection si cette référence existe (possiblement avec une petite note, comme les redirections sur les Wikis).Note supplémentaire concernant les backrefs vers les Post, Topic, Program etc. Il n’est pas acceptable de backref tous les posts vers
Member.postpuis d'écrire des choses comme[p for p in member.posts if p.type == 'program']parce que la complexité est terrible.À la place, il faut mettre en place une backref dédiée de (par exemple)
ProgramversMember.programs, sachant qu’une existe déjà de versMember.postspuisqueProgramest une variante polymorphe dePost.Deux solutions sont envisagées à ce stade :
Program, par exempleprogram_author. Dans ce casMember.postscontinue de contenir tous les programmes.authordansProgrampour écraser la version héritée dePostet backref versMember.programs. Dans ce casMember.postsne contient plus les programmes.Comme les programmes, tutoriels et autres ne peuvent pas être publiés par des invités (contrairement au topic), on veut remplacer à la fois
author_idetauthordans les sous-classes dePostqui ne sont accessibles qu’aux membres.Dans ce cas,
Post.authorpeut être unUserou unMember, mais dans le contexte des posts génériques on s’en moque car les deux se comportent comme desUsergrâce à l’héritage de Python, et dans le contexte des programmes spécifiquement on a la garantie qu’on a unMemberparce que le modèle est défini de cette façon.Pour citer Darks :
À documenter sur https://gitea.planet-casio.com/devs/PCv5/wiki/H%C3%A9ritage-des-contenus une fois que ce sera traité.
La question des backrefs des types spécialisés de posts vers les utilisateurs est a priori réglée, Darks ayant trouvé que
collecte automatiquement tous les programmes en relation avec l’utilisateur considéré, ce qui implémente élégamment la solution envisagée avec l’héritage.
Voilà un début, le modèle des programmes avec promotions de topics devrait être bon. Il faut encore tester, ce qui sera plus facile une fois qu’on aura complété le forum (et notamment de quoi modifier les commentaires et topics) donc on y reviendra un peu plus tard.
127c121eb4implémente l'édition des commentaires pour les cas les plus simples. C’est juste la fonctionnalité pure, il manque pas mal de détails :