Discussion :

[laurent1133]

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 ?

[Séb.]

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if( is_array($tdata) ){
if(!empty($this->titre)){

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 comme
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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

class TABLE{

Généralement on nomme les classes en PascalCase => class Table, le tout majuscule étant plutôt utilisé pour dénommer les constantes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function __construct( &$tdata = NULL, bool $Tinvers=false, array $op=null, string $title='' ){

Il faudrait donner la visibilité des méthodes => public function __construct(...), voir PSR
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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function verif_data(&$item, $key){

Pas fan de la fonction de fonction. En faire une méthode ou une fonction anonyme.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if( is_null($item) || (empty($item) && $item!=0) ){ 
    $item=" ";

Pas fan de la création de contenu initialement absent pour des motifs de rendu. Cela doit se gérer en CSS.
Peut-être à passer en paramètre à $options.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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';
    }

2 choses :
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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
}

Voilà je m'arrête là

[CosmoKnacki]

Ta classe et ton constructeur font trop de choses. Part plutôt sur quelque chose comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
    {}
}

de manière à déléguer un maximum. Tes méthodes doivent rester concises, lisibles, avec un rôle bien précis.

[laurent1133]

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.