getModifiers

Pour continuer sur ma lancé d'hier, voici quelques constats du moment.

Hier je parlais des ArrayObject, sorte de fourre-tout sans nom et sans type. Un exemple de son utilisation est le passage de paramètres aux méthodes qui servent à faire des requêtes sur la base de données. On les traites à coup de tests pour savoir si une propriété des paramètres est vide, est un tableau, et un tableau d'entier, etc... Je me suis dis, tiens bonne occasion de passer par une mini class qui permette de faire ça.

On crée une instance d'un class Param, on lui balance tous les paramètres qu'on veut, et ensuite la class qui gère les requêtes sur la base transforme Param à sa guise pour avoir en retour toujours le bon type de paramètres. Bon. Ca fonctionne. Mais ça utilise une class générique (Param), une classe par type de requête (LogParam, NoticeParam, UserParam, etc...) ce n'est pas plus court, ce n'est pas plus lisible (enfin si mais c'est plus long). Bref, je ne sais pas si je garde ça…

Tiens, au passage, j'ai essayé de me passer de ce Param et d'utilisé uniquement les sqlStatement déjà présent dans quelques class et qui devront à terme être présent partout. Ben ce n'est pas possible car il est quasi impossible de savoir ce qu'on a déjà mis dedans (on a parfois besoin de modifier un paramètre déjà existant ou de le tester pour ajouter une autre options) et on ne peut pas nom plus passer un SelectStatement a deux requêtes consécutives (ou alors peut-être avec un clone mais ça va devenir compliqué) car si on ajoute par exemple un ->from() dans le première requête, il se retrouve dans la seconde alors qu'on l'y ajoute aussi (cette deuxième requête pouvant être faite sans la première)

Bref, j'ai mal à la tête et je n'arrive pas encore à la bonne solution.

Ajouter un commentaire

Les champs suivis d'un * sont obligatoires

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Ajouter un rétrolien

URL de rétrolien : https://chez.jcdenis.fr/trackback/50

Haut de page