John Perr a écrit : > Johan Cwiklinski a écrit : > >> Date: Sun Oct 28 19:21:41 2007 >> New Revision: 421 >> > > Dans ce que tu as commité aujourd'hui quelques remarques: > -Est ce que la class adherents est prévue pour des pages comme > gestion_adherent ? > Ce n'est pas le cas actuellement mais si cela devait, il faudrait faire une > requête pour chaque ligne du tableau ce qui ne serait pas trop efficace: > un objet adherents = 1 adherent = 1 accès à la bd >
Oui, je n'en suis pas encore là, il y aura sûrement des modifs à faire, sauf que je sais pas encore lesquelles... Si tu as des idées précises, je suis preneur, ces classes tiennent plus de l'ébauche qu'autre chose actuellement. > J'ai été confronté au pb en essayant d'utiliser cette class pour refaire > public/liste_membres.php -> donc j'ai rien touché :-) > En fait il faudrait que les objets adherent (un objet par adhérent) soit > remplis par des requetes qui ne sont pas incorporées aux méthodes de la > classe. Une solution c'est de faire de la classe adhérents un objet qui > peux contenir plusieurs adhérents correspondants à une requete. Comme > plusieurs pourra être égal à un ça répond aussi au besoin actuel. > En effet, je vais réfléchir à ça ;) Si tu te sens de commencer la modif de la classe dans ce sens, pas de soucis pour moi. D'ailleurs, la classe Adhérents actuelle ne fait que gérer la connexion, on peut envisager d'externaliser ces fonctions dans une autre classe. > Pour l'install, si c'est le code issu de phpbb qui lit et interprete le > code sql c'est a priori indépendant du sgbd non? (la je remet l'idée du > fichier sql unique sur la table :-) > Bah visiblement pas... Le souci ici, c'est que la syntaxe de création de table diffère énormément de MySQL à PostgreSQL, il ne sera pas possible de faire un seul et unique fichier .sql pour les deux moteurs. Actuellement, le sql_parser se contente grosso modo d'extraire les requêtes une à une et de les interpréter. L'avantage aussi, c'est que si l'install ne marche pas (ou ne plaît pas), on peut utiliser le fichier SQL pour créer les bases (ce qui n'est pas valable du coup pour l'initialisation des données par défaut par ailleurs). > Le remplissage initial des tables par les class comme preferences ou > statuts c'est un peu plus compliqué à gérer à cause de la répartition > dans les différentes class et rien qu'en ajoutant les modèles je vais > supprimer tous les détails des étiquettes et des cartes dans les > préférences, donc dans cette classe... Bref je trouve pas cette solution > très élégante.. > Oui je m'en rend compte. Le souci actuel étant de trouver une solution qui : 1- soit élégante et fonctionnelle 2- n'oblige pas à maintenir/modifier trop de fichiers Quid de les inclure directement dans les fichiers .sql de création des tables ? De toutes façons, on devra les modifier à chaque coup, mais il faudra faire gaffe à la syntaxe utilisée (postgres ne semble pas aimer les quotes inversées (`) que produit un dump mysql par défaut pour les noms des tables et des champs). Bref, pour le moment, soit on part de la gestion via les objets (qui se rapproche à ce qui était fait dans le fichier install/index.php) ; et on se fiche du moteur utilisé puisque c'est mdb qui va se gaufrer le travail ; soit on part des fichiers SQL mais en faisant super gaffe à la syntaxe... Je n'ai pas d'autre solution à proposer pour le moment... > Bonsoir > Puisque l'on cause des modifs que j'ai apportées... J'ai installé une démo svn chez tf en postgres, j'ai refait quelques commits du coup car il y avait des coquilles. L'install s'est bien passée, mais je me chope une erreur sur la conso mémoire de mdb, il va falloir que je voie d'où ça provient (mais pas ce soir, je suis crevé, j'ai galetté tout le week-end). Il suffit pour le moment d'avoir une limite de mémoire pour php qui soit assez conséquente mais bon, c'est tout de même anormal. Je pensais pouvoir mettre en route cette démo afin de tester correctement sur postgres, mais du coup, mes plans tombent un peu à l'eau :'( Voilà pour les quelques news :) Johan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Galette-devel mailing list Galette-devel@gna.org https://mail.gna.org/listinfo/galette-devel
