mailRe: [Galette-devel] Vers la V0.7


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Johan Cwiklinski on October 28, 2007 - 22:05:
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

Attachment: signature.asc
Description: OpenPGP digital signature


Related Messages


Powered by MHonArc, Updated Sun Oct 28 22:41:05 2007