Bienvenue dans le volume de documentation de conception de BoardZ Version 2.

• Sur la problématique des séries temporelles (données historisées) et après une solidification de la mesure du cube, on voit désormais que les sous-dimensions temporelles sont bien routées vers les bonnes parties du cube, et que les étiquettes temporelles sont correctement calculées.

• Les travaux en cours concernent le passage entre un résultat boardz (à minima une association d'arité 1 ou une arité supérieure) vers une série de données compatible avec les axes de temps des rendus ChartJS.
• En effet, le cube enregistre des dimensions dissociées (year, year + month, year + month + day) là où les axes de temps attendent des instances de Date() (Javascript).
• Le plus simple étant de fabriquer ces dates à partir de timestamps unix Epoch, 1 Jan 1970) un adaptateur doit permettre de réagréger les composantes de date de tout type de structure de données vers une série de données timestampée (au moins une).

• Les Renderers de courbes, et notamment celui des courbes temporelles.

• Nouveaux éléments de formulaires destinés à faciliter l'usage de l'administration. Actuellement nous en avons identifié 2 :

1. Un elément colorpicker pour paramétrer les couleurs des renderers (étonnamment, cet élément de formulaire existe dans les “settings” d'administration de moodle, mais pas dans les éléments des formulaires moodle)
2. Un élément “liste multiple à choix ordonné” pour remplacer les champs de texte où on attend une liste d'id à virgule et dans un ordre précis (par exemple, lister les widgets d'un panneau, ou lister les sous-éléments d'un indicateur multiple ⇒ pour un rendu Radar)

• En réfléchissant sur l'adaptabilité des renderers aux changements d'arité, il apparaîtrait souhaitable de pouvoir composer un AdaptativeRenderer comme un assemblage de renderers plus simples répondant chacun à une arité ou structure de données particulière. Cela permettrait de passer de manière fluide d'un rendu scalaire (jauge) à un rendu de série (bargraph) ou matriciel, en suivant la variabilité du contexte d'entrée :

Je rappelle pour cela le résultat des travaux d'architecture sur les résultats :

Nos travaux nous ont conduit à proposer un modèle très unifié et homogène pour utiliser un même indicateur à plusieurs niveaux de profondeur (drill-down/up) par simple variabilité des paramètres passés dans l'URL d'invocation de l'indicateur.Un indicateur génériquement matriciel (arité 2) peut donc produire des résultats d'arité 2, 1, ou même 0 si on force certaines de ses dimensions, sans avoir rien à reconfigurer ni programmer dans le boardz. Aujourd'hui, l'implémentation monte jusqu'à l'arité 2 (matrice), et dans une bonne partie des opérateurs l'arité 3 (exemple : par cours / par semaine / par utilisateur). Des possibilités de monter encore en arité supportée sont tout à fait possibles. Tout est centralisé dans la seule classe boardz\data_processing\Result.class.php

A très bientôt pour continuer la mise en oeuvre.

Pour toi Amelie : il va me falloir savoir à quel niveau tu peux intervenir avec nous. Actuellement je dois me battre sur deux fronts, l'architecture et la mécanique générale, et de l'autre côté la mise en place des exemples d'indicateurs, à l'aide des outils disponibles (et l'augmentation des outils si l'indicateur coince

Sommaire du journal - Revenir au sommaire général