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 John Perr on October 28, 2007 - 20:32:
Johan Cwiklinski a écrit :
De mon côté, je suis toujours sur le script d'install, il me demande pas
mal de taff...
    
Oui, sur ce sujet je me demandais s'il ne valais pas mieux un fichier sql
séparé qui intègre toutes les données de base (statuts, preferences,
mails automatiques etc) plutôt que d'avoir ces données en dur dans
le script d'install ?

J'en étais venu à la même conclusion, sauf que dans ce cas, il faudrait
un fichier pour chaque base de données supportée (le quoting par exemple
n'est pas toujours équivalent, ça reste gérable tant qu'on ne propose
que postgres et mysql, mais pour offrir un nouveau support, ce sera
autre chose...).

Du coup, j'ai plutôt géré un tableau des valeurs par défaut dans les
objets en question, j'espère pouvoir commiter tout ça avant la fin du
week end pour avoir des retours sur les changements que j'ai apportés...

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

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 :-)
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..

Bonsoir
-- 
John Perr
GPG Id 0xA83889EC



Related Messages


Powered by MHonArc, Updated Sun Oct 28 22:20:51 2007