Évolution/refacto des paramètres du modèle
Le modèle présente 2 intérêts majeurs :
- Il surcharge l'apparence par défaut de la lib afin d'avoir de base un truc plus sympa : jeu de couleurs, etc.
- Il charge intelligemment la lib depuis 9bdeb4ed
Il doit permettre des utilisations simples mais également avancées : qu'on veuille générer un graphique vite fait en se satisfaisant de l'apparence par défaut, ou qu'on veuille vraiment pouvoir tout personnaliser dans les moindres détails : les axes, etc.
Et cela doit fonctionner que le modèle soit utilisé dans le texte d'un article ou dans un squelette.
C'est déjà le cas dans une certaine mesure dans la branche 2, mais je pense qu'on peut mieux faire. Ce qui nous amène aux paramètres.
Problématique
Historique et évolution de la lib
Originellement le modèle proposait une dizaine de paramètres qui correspondaient à ceux de la lib en v1, et permettaient de changer globalement les trucs les plus courants : couleur des lignes, couleur des points, etc.
Sauf qu'au passage à la v2 la lib a été refactorisée, et les paramètres ont complètement changé : leurs noms, leur nombre et surtout l'architecture a été repensée (en v3 c'est juste quelques adaptations).
Un exemple pour voir la structure actuelle.
Pour initialiser un Chart, on lui passe un objet avec 3 clés principales type
, options
et data
(qui contient les labels et les datasets) :
var myChart = new Chart('#truc', {
type: 'line',
data: {
labels: ["Janvier", "F\u00e9vrier", "Mars", "Avril"],
datasets: [
{
"label": "patates",
"data": [40,43,61,"50 "],
"borderColor": "#69D2E7",
"backgroundColor": "#69D2E7",
"fill": false
},
{
"label": "poireaux",
"data": [33,15,40,22],
"borderColor": "#E0E4CC",
"backgroundColor": "#E0E4CC",
"fill": false
}
]
},
options: []
});
On peut toujours changer globalement l'apparence de tous les éléments, mais aussi indépendamment pour chaque jeu de données.
Par exemple si je veux changer la couleur de la bordure de tous les points de tous les datasets, c'est fait dans Chart.defaults.elements.point.borderColor
.
Mais si je veux faire pareil mais juste pour le dataset n°3, c'est dans Chart.datasets.2.data.pointborderColor
.
Et il y a des tonnes d'options : de l'épaisseur de la bordure de chaque côté d'une barre, à la la police de chaque axe, etc.
Implémentation actuelle
Donc dans le modèle, le problème est double :
- Il faut continuer de faire fonctionner les anciens paramètres
- Et surtout, il faudrait idéalement permettre d'accéder à tous les nouveaux paramètres, que ce soit en appelant le modèle dans le texte d'un article, ou dans un squelette.
Pour le 1) c'est en partie ok, on reroute les anciens paramètres au bon endroit (strokeColor
devient borderColor
par ex.). Mais ça reste améliorable : comme il s'agit d'options globales, au lieu de les répéter dans chaque dataset on pourrait les mettre dans Chart.defaults
plutôt. Maif bref, c'est un détail.
Pour le 2) c'est aussi en partie ok, mais uniquement si appelle le modèle dans un squelette, donc peut mieux faire.
La solution retenue, c'est de pouvoir passer un array complet aux 2 paramètres data
et options
. À ce moment on les passe tels quels au script en les jsonifiant, et donc on a accès à toutes les options.
Un truc à corriger, c'est qu'on perd la surcharge de l'apparence par défaut (les couleurs et cie), on pourrait faire en sorte de les conserver même dans ce cas.
Exemple :
#SET{data, #LISTE{
#ARRAY{
label, Vitesse,
data, #GET{vitesses},
pointColor, transparent,
pointBorderColor, transparent,
fill, false,
borderColor, #GET{couleurs/0},
lineTension, 1,
},
#ARRAY{
label, Altitude,
data, #GET{altitudes},
pointRadius, 0,
borderColor, \#eeeeee,
fillColor, \#eeeeee,
showLine, false,
lineTension, 1,
yAxisID, altitude,
}
}}
#SET{options, #ARRAY{
scales, #ARRAY{
y, #ARRAY{
beginAtZero, true,
gridLines, #ARRAY{
display, false,
},
},
altitude, #ARRAY{
type, linear,
position, right,
beginAtZero, true,
},
},
}}
<INCLURE{fond=modeles/chart,
type=line,
data=#GET{data},
options=#GET{options},
labels=#GET{heures},
}>
Mais le problème, c'est qu'on ne peut pas utiliser cette solution en invoquant le modèle dans le texte d'un article, les paramètres sont forcément des chaînes de texte.
Proposition d'évolution
Bravo à celleux qui ont tenu jusqu'ici :p
Donc je rappelle, de base on garde une série de paramètres les plus courants pour avoir accès aux options générales.
Et donc il reste à s'occuper des utilisateur⋅ice⋅s avancé⋅e⋅s. Je n'aime pas l'idée "d'inventer" des paramètres imbuvables en camelcase pour essayer de tout prendre en compte. L'idée serait plutôt d'accepter la notation javascript pour les autres paramètres. Si on connaît la structure de l'objet attendu pour le script, alors ça permettrait d'accéder facilement à n'importe quelle propriété.
Par exemple si on veux changer la taille des points du 2ème dataset, on utiliserait data.datasets.1.data.pointRadius
.
Que ce soit dans le texte d'un article :
<chart
|type=line
|data="10,20,30 next 5,10,15"
|labels="2005,2006,2007"
|dataLabels="patates,poireaux"
|data.datasets.1.data.pointRadius=10
>
Ou dans un squelette :
#MODELE{
chart,
type=line,
data=#ARRAY{patates,#LISTE{10,20,30}, poireaux,#LISTE{5,10,15}},
data.datasets.1.data.pointRadius=10,
}
Pour changer le type de point par défaut : defaults.elements.points.pointStyle="cross"
Pour changer le titre : options.title="Mon super graphique"
Etc, etc.
Voilà l'idée. Des objections ? Sinon j'implémente ça, je passe le plugin en test et je fais un nouvel article pour la branche v2.
Ps. : ping @erational et @goonydev pour que vous receviez la notif