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

_______________________________________________
Galette-devel mailing list
Galette-devel@gna.org
https://mail.gna.org/listinfo/galette-devel

Répondre à