Bonjour,
Je vous propose un nouvel élément à utiliser : Class table html5
Injectez vos datas directement dans une balise avec options de formatage.
Qu'en pensez-vous ?
Version imprimable
Bonjour,
Je vous propose un nouvel élément à utiliser : Class table html5
Injectez vos datas directement dans une balise avec options de formatage.
Qu'en pensez-vous ?
Merci pour la proposition !
Dans l'ordre de ma découverte...
C'est documenté, c'est bien. Par contre il y a beaucoup plus de CSS que de PHP.
La chasse des extraits de code n'est pas fixe. Le code est dur à lire.
Pourquoi utiliser array() quand [], plus concis, est disponible depuis 2012 ?
class_table2_15.php => Si tu tiens vraiment à intégrer la version dans le nom de fichier fais quelque chose comme Table@2.15.php, on comprend tout de suite qu'il s'agit de la version, et si tu ranges tes classes dans /classes ou /lib (ce qui devrait être le cas) alors le préfixe en "class_" est redondant
Le script est dur à lire, ne respecte pas les bonnes pratiques de présentation, et est inconsistant, ex.
Il faut se donner une règle de présentation et la tenir jusqu'au bout, l'idéal étant de suivre les règles généralement acceptées commeCode:
1
2 if( is_array($tdata) ){ if(!empty($this->titre)){
PSR-1 => https://www.php-fig.org/psr/psr-1/
PSR-12 => https://www.php-fig.org/psr/psr-12/
En temps normal quand le script est mal présenté je ne vais pas plus loin ;)
Généralement on nomme les classes en PascalCase => class Table, le tout majuscule étant plutôt utilisé pour dénommer les constantesCode:class TABLE{
Il faudrait donner la visibilité des méthodes => public function __construct(...), voir PSRCode:function __construct( &$tdata = NULL, bool $Tinvers=false, array $op=null, string $title='' ){
Pourquoi nommer ta variable $op ? $options est immédiatement compréhensible.
&$tdata : pourquoi & ? Les paramètres passés par référence sont généralement considérés comme une mauvaise pratique car c'est une porte ouverte à des effets de bord et un enfer à débuguer.
Pourquoi $tdata et $Tvision ? L'une en minuscule et l'autre en majuscule ? Pourquoi un préfixe t ?
Pourquoi un tableau d'options en 3e paramètre et $Tinvers en 2e paramètre ? $op sera plus souvent utilisé qu'un pivot il me semble, et pourquoi ne pas intégrer le pivot et le caption aux options ?
Pourquoi $title et $titre ? Il faut se tenir à 1 langue.
Pas fan de la fonction de fonction. En faire une méthode ou une fonction anonyme.Code:function verif_data(&$item, $key){
Pas fan de la création de contenu initialement absent pour des motifs de rendu. Cela doit se gérer en CSS.Code:
1
2 if( is_null($item) || (empty($item) && $item!=0) ){ $item=" ";
Peut-être à passer en paramètre à $options.
2 choses :Code:
1
2
3
4
5
6
7
8 function __construct( &$tdata = NULL, bool $Tinvers=false, array $op=null, string $title='' ){ if( is_array($tdata) ){ // Beaucoup // Beaucoup // Beaucoup de code }else{ $this->erreur='La variale n\'est pas un tableau'; }
Si tu veux que $tdata soit obligatoirement un tableau, alors laisse PHP gérer ça on précisant le type dans le constructeur => public function __construct(array $data, ...)
Il faut éviter les longs if(), éviter les else autant que possible et vérifier les situations anormales en entrée de fonction/méthode
Voilà je m'arrête là ;)Code:
1
2
3
4
5
6
7 public function __construct($data) { if (!is_array($data)) { throw new TypeError('$data doit être un tableau'); } // À partir de là on sait que $data est un tableau, pas besoin de else, pas besoin d'un niveau d'indentation supplémentaire }
Ta classe et ton constructeur font trop de choses. Part plutôt sur quelque chose comme ça:de manière à déléguer un maximum. Tes méthodes doivent rester concises, lisibles, avec un rôle bien précis.Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38 /* tout ce qui est information: titre, data, header, footer */ class TableData { public function __construct(array $data = []) { $this->setData($data); } public function setData(array $data = []) {} public function setTitle(string $title) {} public function setFooter() {} // etc. } /* tout ce qui est aspect de la table: transposé ou non, attributs html (id, class), colonnes ou lignes mises en évidence ...*/ class TableOptions {} class Table { public function __construct(TableData $tableData, TableOptions $tableOptions) {} /* display a la charge de produire le html en fonction des données et options dont l'instance dispose Au besoin ne pas hésiter à déléguer certaines tâches si cette méthode devient obèse: - une méthode qui s'occupent du titre - une autre pour les données - une pour le footer, etc. */ public function display() // ou buildHtml(): string {} }
Bonjour , vous avez raison ce code n'est pas très "élégant", (c'était urgent). En tous cas, merci pour réflexion expérimenté ! ce qui motive à progresser.