Justification¶

Lors du développement initial, j'ai essayé d'éviter les duplications de codes en l'organisant avec de l'héritage et des widgets graphiques.

Après un an de développement, il s'avère qu'il y a encore trop de duplications. Il est temps de passer à un niveau d'abstraction plus poussé en basant l'architecture sur une auto-description des données. L'idée est d'utiliser les capacités d'auto description des bases de données pour en extraire les tailles et type des champs et de les compléter avec des descriptions applicatives. Par exemple un varchar peu contenir une chaine de caractères, ou une adresse email, ou une adresse IP, etc.

On doit pouvoir déterminer les caractéristiques d'affichage, de saisie et les règles de validation en utilisant le type et sous-type des données. De cette façon le code pour afficher un saisir les dates sera le même pour toutes les dates, pour agrandir un champ, il suffira d'élargir sa taille en base, etc.

Les vues ne devrait plus comprendre que la structure HTML et l'appelle de fonctions pour afficher les tables et les champs. Une première expérimentation m'a permit de supprimer une cinquantaine de ligne sur une vue table (divisée par 2). On passe d'une programmation ou l'on décrit des attributs graphiques, à une programmation ou l'on décrit des types de données. Le passage du type à sa représentation graphique n'ayant à être fait qu'une seule fois.

J'espère gagner environ 20 % de taille de code (donc 20 % de bugs en moins), augmenter la lisibilité et la productivité pour les futures évolutions.

Statique ou dynamique.¶

On peut explorer la structure de la base lors de chaque requête ou écrire un petit programme qui la lira une fois et générera les structures PHP à insérer dans le code. Tant qu'il n'y a pas de problème de performance avérés on fera l'analyse dynamiquement. On passera statique, si c'est utile plus tard.