Discussion :

[forstera]

Bonjour à tous ,

Pour ceux qui ont un peu suivi mes précédentes discussion, je dois donc créer une application de gestion des années scolaires et attribution de cours aux enseignants. Celle-ci avant bien et j'en suis à la phase d'affichage des plans d'études.

la problématique résidait dans le fait qu'à chaque nouvelle année , un nombre x de classes doit être créé. Pour chacune, un plan d'étude est utilisé est crée un ensemble de cours . Les cours eux-mêmes sont relativement complexes car ils se composent d'une ou plusieurs matières.

voici un exemple de cours (incomplet) qui montre les différents niveaux d'imbrications qu'un cours peut avoir, chaque couleur étant un 'niveau' et ceci pour chaque classe



L'idée est donc de pouvoir afficher toutes ces informations par classe. Je suis parti sur un tableau de bord et une fenêtre interne. Je crée autant de widgets basés sur ma fenêtre interne qu'il y a de classe. Cela fonctionne bien.
Maintenant, pour chaque classe, je suis censé représenter les données selon le schéma ci-dessus.

J'ai débuté par une zone répétée avec rupture pour mon premier niveau (zone bleue sur le schéma ci-dessus). Ensuite j'arrive à afficher les éléments en jaune sur mon schéma.

Le résultat se trouve dans l'image ci-dessous ((je suis en train de faire des essais donc le design ci-dessus n'est pas final, je teste juste les mécanismes). Mais ici je suis aux limites de l'outil me semble-t-il. J'avais pensé imbriquer d'autres zones répétés mais cela n'est , semble-t-il, pas possible. J'ai bien eu une leur avec la version 28 qui permet cela mais "seulement" en Webdev.

Selon-vous imbriquer une nouvelle fenêtre interne dans ma zone répétée serait envisageable ? le problème est que l'utilisateur final a besoin de toutes les infos en 1 seule fois lors de l'attribution des cours aux enseignants. Dans le cas contraire, je me serais tourné vers des filtres manuels sur le type d'info à afficher ...



Merci pour votre aide

[Voroltinquo]

Bonjour,
Il faut que tu regardes du côté des TCD (tableau croisé dynamique.)
Pour ce champ, il y a de nombreux réglages "cachés" (e.g. affichage des totaux horizontal/vertical, nommage des cellules) il ne faut pas hésiter à bien fouiller les descriptions.
Le fait de cliquer sur les "zones principales" offre de nouveaux réglages

[frenchsting]

+1 @ Vorloltinquo.

Ce que tu nous montres est un TCD.

[tbc92]

Dans le champ TCD, j'en étais resté à ceci :
Les entêtes de lignes et de colonnes peuvent être des champs Texte, mais la partie "corps du tableau" contient des données de type numérique.

Ca a changé ? Le corps du tableau peut être de type texte ?

[frenchsting]

Je ne pense pas que cela soit un souci.

Il suffit d'utiliser les Id des éléments lus en base : ex Matière(IdMatière, LibelléMatière)

EDIT : je viens de me rendre compte de l'énormité de ce que je viens d'écrire. Tu as raison tcb92 : si on ne peut avoir que des nombres affichés, ça va être compliqué avec le TCD

[Voroltinquo]

On a la possibilité d'ajouter des niveaux via les zones Ligne et Colonne.

[forstera]

Merci à vous pour toutes ces infos.
La problématique je pense est que par 'cellule finale' il y a plusieurs champs qui sont de type numérique mais également texte. Si j'ai bien compris, le TCD ne permettrait d'afficher "que" des valeurs totaux ?
De même, si vous regardez mon tableau, il peut y avoir 1 ou plusieurs enregistrements par 'sous-niveaux' ; c'est pour cette raison que je dois systématiquement créé qqchose comme des listes ou des zones répétées qui sont imbriquées.

Je pense être arrivé aux limites actuelles du logiciel, je vais donc voir avec l'utilisateur final si je peux créer plusieurs types d'affichage en fonction du besoin et me concentrer sur deux niveaux, ce que permet le logiciel

Merci encore à vous pour votre temps

[tbc92]

As-tu regardé les tables-hiérarchiques ?

Il y a un truc qui me pose problème dans ton image initiale, c'est la rubrique 'Latin'.
Pour toutes les premières lignes, on a une structure en arbre. La colonne en rose est un 'enfant' de la colonne en vert. Elle-même enfant de la colonne en jaune.
Mais pour la rubrique 'Latin', ce n'est plus le cas.
Donc non seulement en terme d'affichages, mais déjà, auparavant, en terme de stockage des données, je ne vois pas comment ces données sont organisées en base de données.

[forstera]

Oui le latin a été une prise de tête au niveau de la conception de mon MLD. J'explique :

Un cours peut être composé de plusieurs matières. Par exemple, un cours appelé OS Arts visuels sera composé d'une leçon d'histoire de l'art, de 3 leçons d'atelier et d'une leçon de théorie. Lorsque je parle de leçon, c'est une présence physique de x périodes pour lesquelles il faut avoir une salle de disponible.

Il y a dans notre école plusieurs types de cours : disciplines fondamentales, Options spécifiques (OS), Options complémentaires (OC), etc. A chaque type est donc relié des cours avec leur(s) leçon(s).

Il y a maintenant le cas du Latin qui est dispensé dans deux types de cours : les Disciplines fondamentales (au même titre que l'anglais, l'allemand, le français) et en tant qu'OS. Mais comme le nombre d'étudiants en latin étant très réduit, la leçon en présentielle dans une salle de cours est partagée par les deux types de cours. Dans mon MLD,je dois donc pouvoir lier une leçon physique à plusieurs cours de types différents. Cela m'a donné le schéma suivant :

j'ai mis en rouge les fichiers nécessaires à cette opération

[tbc92]

Bon, c'est compliqué. Tu sais où tu vas, je ne vais pas faire l'effort d'éplucher cette dernière image.
Mais c'est le coeur de l'histoire. Est-ce que le MLD permet de stocker les liens entre toutes ces informations.

Mais je pense que à cause de cette particularité, les champs classiques ne vont pas pouvoir fonctionner. Il va falloir mettre les mains dans le cambouis.
Peut-être un simple champ table, et jouer beaucoup avec les fusions de cellules. Beaucoup de travail dans tous les cas.
Ou au pire, un champ image.
Malheureusement, le champ organigramme ne permet de gérer que les cas où un parent a plusieurs enfants, mais un enfant a un seul parent. Donc le cas particulier du latin n'est pas compatible.

Le problème n'est pas : 'on a 4 niveaux hiérarchiques, c'est trop'. Le problème est : 'on a un truc qui ressemble à un truc hiérarchique, mais pas totalement'.

Dans la toute première image, il y a une 'réflexion humaine' qui a conduit à afficher la cellule Latin-Rose au milieu entre les 2 lignes 'Latin Vert'... comment cette réflexion humaine peut-elle être stockée en base de donnée, comment peut-elle être restituée à l'écran.
Pareil, dans cette toute première image, on a 2 cellules jaunes DF-Latin, elles ne sont pas fusionnées, c'est probablement volontaire. Tout ça est compliqué, et ne pourra probablement pas être restitué tel quel avec juste le choix du bon champ et 10 ou 20 lignes de code.

[forstera]

Bon, c'est compliqué. Tu sais où tu vas, je ne vais pas faire l'effort d'éplucher cette dernière image.
Mais c'est le coeur de l'histoire. Est-ce que le MLD permet de stocker les liens entre toutes ces informations.

Mais je pense que à cause de cette particularité, les champs classiques ne vont pas pouvoir fonctionner. Il va falloir mettre les mains dans le cambouis.
Peut-être un simple champ table, et jouer beaucoup avec les fusions de cellules. Beaucoup de travail dans tous les cas.
Ou au pire, un champ image.
Malheureusement, le champ organigramme ne permet de gérer que les cas où un parent a plusieurs enfants, mais un enfant a un seul parent. Donc le cas particulier du latin n'est pas compatible.

Le problème n'est pas : 'on a 4 niveaux hiérarchiques, c'est trop'. Le problème est : 'on a un truc qui ressemble à un truc hiérarchique, mais pas totalement'.

Dans la toute première image, il y a une 'réflexion humaine' qui a conduit à afficher la cellule Latin-Rose au milieu entre les 2 lignes 'Latin Vert'... comment cette réflexion humaine peut-elle être stockée en base de donnée, comment peut-elle être restituée à l'écran.
Pareil, dans cette toute première image, on a 2 cellules jaunes DF-Latin, elles ne sont pas fusionnées, c'est probablement volontaire. Tout ça est compliqué, et ne pourra probablement pas être restitué tel quel avec juste le choix du bon champ et 10 ou 20 lignes de code.

Oui c'est compliqué effectivement, d'où ma question à l'utilisateur finale de pouvoir séparer les affichages en fonction des différents besoin et de ne montrer qu'une partie des informations.

Pour ce qui est de ta remarque : "..Pareil, dans cette toute première image, on a 2 cellules jaunes DF-Latin, elles ne sont pas fusionnées" tu as mis le doigt sur une erreur de ma part car effectivement cette présentation n'est pas logique. Une des deux lignes ne devrait pas s'intituler 'DF Latin' mais 'OS Latin'.

Sinon, pour l'affichage de ces cas particuliers, je n'aurais pas d'autre choix de les afficher pour chaque cours concerné avec un mention ou un code couleur qui avertit l'utilisateur que cette dernière concerne plusieurs cours.

J'ai ajouté à cette effet un champ qui prendra les valeurs des noms des classes concernées par une éventuelle fusion de leçon


s'il y a un intérêt, je peux vous afficher ce que j'arrive à faire dès que j'ai qqchose de cohérent