khana/khana/planning
Trullemans Gregory 16486064ce Minor improvement 2021-12-05 12:43:30 +01:00
..
migrations Minor improvement 2021-12-05 12:43:30 +01:00
tests Here we go again... 2021-10-04 21:39:37 +02:00
ExpertSystem.md Here we go again... 2021-10-04 21:39:37 +02:00
README.md Here we go again... 2021-10-04 21:39:37 +02:00
__init__.py Here we go again... 2021-10-04 21:39:37 +02:00
admin.py Fixing small bugs that prevent using the application 2021-10-19 20:56:38 +02:00
apps.py Here we go again... 2021-10-04 21:39:37 +02:00
forms.py pylint khana --errors-only says it's OK 2021-10-05 19:25:57 +02:00
models.py Fixing small bugs that prevent using the application 2021-10-19 20:56:38 +02:00
urls.py Here we go again... 2021-10-04 21:39:37 +02:00
views.py pylint khana --errors-only says it's OK 2021-10-05 19:25:57 +02:00

README.md

Application Planning

Saison

Une saison est déinie par :

  • un id,
  • un label,
  • une date de début et
  • une date de fin.

La date de début est très souvent le : 01/09/xxxx La date de fin est très souvent le : 31/08/xxxy Exemple : 1/9/2015 - 31/8/2016

NOTE: Le fait que la date de début soit très souvent le 01 septembre indique sans doute une date par défaut (modifiable) au niveau du modèle. Idem pour la date de fin.

NOTE: je ne comprends pas la méthode week_number_from_begin. Si cela fait référence à la date de début, alors il faut le mentionner dans le nom de la fonction.

Course

Un cours est un ensemble d'entraînements (training) (récurrents ?) défini par :

  • une heure de début et une heure de fin,
  • une date de début et une date de fin
  • est associé à un ou plusieurs entraineurs,
  • est associé à un club
  • est associé à un jour de la semaine (numéro du jour dans la semaine : 0 = lundi, 6 = dimanche).

Réflexions/questions :

  • les cours devraient-ils être liés à une saison ?
  • un cours est considéré comme donné hebdomadairement entre la date de début et la date de fin (hérite de la classe Temporizable), mais est-ce une bonne idée ? Est-ce une bonne manière de faire ?

NOTE: Je dirais que oui. D'un côté, tu n'aurais pas de possibilité de déduction entre un cours et le moment où il y a réellement lieu - de ce que je comprends, le cours correspond en fait à quelque chose qui est prévu selon une récurrence donnée - eg. "tous les mardis (deuxième jour de la semaine), entre 10h et 12h, avec Machin, Chose et Brol". La saison va juste indiquer la date de début et de fin des cours qui y sont liés.

Même s'il y a moyen de le représenter différement, je pense surtout que le concept de saison parle à beaucoup de monde.

NOTE: la réflexion va surtout être "est-ce qu'un cours est différent entre deux saison ?" A priori, oui, puisque Bidule peut devenir entraineur pour la saison 2020-2021.

L'avantage, c'est que Machin pourrait se connecter sur son profil et dire "ah ouais, cette année, je donne cours le jeudi et le samedi."

Training

Un entraînement est une occurence d'un cours pendant lequel des gmnastes sont présents.

Un objet de cette classe lie donc :

  • un cours,
  • des gymnastes présents et
  • une date.

NOTE: Techniquement, tu peux ici mettre une contrainte ou un avertissement si l'entrainement est situé à une date différente de ce que la saison devrait autoriser.

NOTE: dans la classe Training, il est question d'une ForeignKey vers Gymnast, mais ce devrait être un ManyToManyField.

NOTE: De la même manière, je reprendrais aussi l'heure de début et de fin. Entre ce qui est prévu (le cours) et la réalité (l'entraintement), il pourrait y avoir des différences.

Cela permettrait aussi de planifier les cours - dire en gros que, en début d'année, tu (l'appli) planifies les jours fériés, et projette les entrainements pour la saison, sur base de ce qui est prévu.

Round

Classe représentant les passages des élèves lors d'un entrainement. Chaque record représente un passage. Il est donc lié à un record de la classe Training.

NOTE: Est-ce qu'il est important de savoir qui est l'entraineur qui a donné une évaluation ?

NOTE: au niveau du round, il y a un ensemble d'informations chronologiques: nb_of_realisations (au pluriel...), nb_of_success, ... mais c'est incohérent avec le round_number, puisque je suppose qu'il pourrait faire un tour de A, puis B, puis revenir à A. Cette partie-ci me semble très complexe - sans oublier qu'il va falloir la remplir: si tes entraineurs chipotent sur une tablette ou sur un écran pour chaque action que réalise un gymnaste, ça va pas être sympa pour eux.

Group

Classe représentant les groupes (Loisir, D1, D2, A, B, …). Un groupe appartient à un club.

NOTE: pourquoi garder un champ active ? Il y a un risque qu'un groupe soit désactivé ? Si oui, ne vaut-il pas mieux garder le moment où il l'a été ?

NOTE: est-ce que le champ name n'est pas un dictionnaire fini ? Loisir, D1, D2, ... ?

NOTE: est-ce que tu n'as pas une contrainte sur le nom, le club et la saison ?

Subgroup

Classe représentant les sous-groupes.

Un sous-groupe appartient à un groupe (pour rappel, lui-même lié à un club).

De cette manière, quand un gymnaste est mis dans un sous-groupe, en remontant via le groupe, nous pouvons connaître le(s) club(s) du gymnaste pour chaque saison.

NOTE: re-question sur le name. A mon avis, si le nom du groupe est fini, tu peux te passer d'une des classes Group ou Subgroup, et cela simplifierait pas mal la gestion du club.

Unavailability

Classe représentant les indisponibilités.

NOTE: avec la réflexion ci-dessous, cela pourrait ne plus être utile. Les Courses correspondent à la modélisation tandis que les entrainements représentent le planifié/réalisé. Du coup, il suffit qu'un entrainenemnts n'existe pas pour qu'il ne soit pas planifié.

PlanningLine

Classe représentant les passages prévisionnels (incubating idea).

NOTE: en gros, tu veux proposer un entrainement personnalisé pour chaque gymnaste ;) Je ne vois pas la valeur ajoutée. Le mieux serait d'avoir une forme de proposition au niveau des Rounds et des Trainings, quitte à la modifier pendant l'entrainement. Sinon, je ne vois pas trop l'idée.

EventType

Classe représentant les types d'évènements.

C'est un dictionnaire fini : - compétiton qualificative, - compétition finale, - démonstration, - …

NOTE: tu peux utiliser un champ de type Choice, si le dictionnaire est fini. Cela te fera gagner une jointure. Si le dictionnaire a une chance d'avoir une nouvelle valeur, garde la table.

Event

Classe représentant les évènements.

Un évènement est caractérisé par :

  • un nom,
  • un lieu (place),
  • un type (compétition, démonstration, …),
  • des gymnastes (participation prévue).

Je ne me rapelle plus à quoi sert le club.

NOTE: alors, retire le club :-p

Event_Participation

NOTE: Dans Event, tu as déjà un lien avec des gymnastes, que tu reprends dans la classe EventParticipation (pas de "_"). Autant ne garder qu'une seule liaison entre un évènement et des gymnastes, et compléter ces enregistrements après (ou pendant) pour dire si Choupidou étant bien placé ou pas (quitte à laisser le rank vide si Choupidou n'est finalement pas venu ou s'il a sauté comme une bouse - oui, ça arrive).