Re: [Phpcompta-contrib] contributeur...

[Dany De Bontridder]

On Thursday 11 May 2006 23:22, herve couvelard wrote:
(...)
> > Il vaut mieux l'appeler autrement, parfois j'envoie des appels à des
> > fonctions à travers ExecSql ;-)
> > Donc function FetchArray($p_connection, $p_string) {
> >     $ret=pg_fetch_all($p_connection,$p_string);
> > /* http://be.php.net/manual/en/function.pg-fetch-all.php */
> >     return pg_fetch_array($ret);
>
> Lapin compris. Le but est de remplacer la boucle par un fetch_all puis
> fetch_array ? je ne saisie pas la subtilité,
Euh... Sorry, un drink trop arrosé :-)
Je voulais faire
-----------------------------------------------------
function FetchArray($p_connection, $p_string) {
$ret=pg_execute($p_connection,$p_string);
/* http://be.php.net/manual/en/function.pg-fetch-all.php */
        return pg_fetch_all($ret);
-----------------------------------------------------
(...)
> >>sorte, mais un bon filegetcvs ()... et hop directement un formulaire et
> >>hop directement un fputs... cela allègerait pas mal la bdd et
> >>simplifierais le code.
> >
> > J'essaie d'éviter de drop sortir des choses de la DB, sinon cela
> > complique un peu la stratégie de backup, et puis une db au moins c'est un
> > fichier qu'on accède avec des commandes SQL ;-) On peut en discuter au
> > cas par cas, mais il faudrait vraiment être convainquant ;-)
>
> INSERT INTO `user_global_pref` VALUES ('phpcompta', 'THEME', 'Light');
> INSERT INTO `user_global_pref` VALUES ('phpcompta', 'PAGESIZE', '50');
>
> j'adorerais être convaincu de l'utilité de cette table alors que l'on a
> un fichier de define de 10Ko :-) idem avec user_local_pref.
Parce qu'il pourrait y avoir beaucoup d'utilisateurs et les paramètre peuvent 
évoluer, on peut en ajouter, avec ces tables c'est facilement extensible et 
"patchable". Le insert c'est dans le cas d'une première connection et aucune 
préférence ne sont encore sauvées, préférence par défaut en somme.
(...)
> > Facile : mod1 = comptabilité Belge
> >     mod2 = comptabilité Française
> > Comme on peut adapter complètement un dossier, et après en faire un
> > modèle, pratique ;-) Les épiciers n'ont pas les mêmes postes comptables
> > que ceux vendant du matériel informatiques cela concerne les prestations
> > et la vente/achat de marchandises :)
>
> Pk, c'est pour faire des modifications a travers l'interface phpcompta
> et lee garder comme modèle pour un nouveau cas ? C'est juste un plan
> comptable ? Pourquoi construire les bases et pas juste laisser les
> script pour les construire et ensuite 'uploader' un plan comptable, Ansi
> cela permettrait aussi d'importer les plans comptable lors d'une migration.
> Ce que je ne comprenss c'est pourquoi les bases existent, même si on en
> a pas besoin.
Non pas seulement un plan comptable, il y a les rapports, les fiches 
(marchandises)...D'autres choses auquelles je ne pense pas pour le moment. 
Oui on en a besoin, il ne faut pas perdre de vue que c'est multi dossier et 
multi utilisateur, pense à une fiduciaire par exemple. Les clients ne doivent 
pas voir les dossiers des autres et surtout s'ils accèdent par ODBC (pour 
faire du mailing) ils ne doivent pas voir les données des autres.

Pour les modèles, disons qu'en faire un script oui pourquoi pas mais alors, 
imagne un modéle fait avec la version 1.2, mis sous forme de fichier, il ne 
sera pas patché par le setup.php pour arriver à une version plus récente ;-)

>
> Pour le modèle objet, je n'aime pas du tout le mode objet en php web. Je
> trouve que c'est pas adapté, même si il y a de bon coté. Pourquoi
> phpcompta va devenir programmée objet ?
Je ne pense pas que PhpCompta sera 100% programmé en objet, tout dépend de 
quelle partie on parle. Certaines parties ne pourraient pas être fait 
autrement qu'avec de l'objet, la charge en maintenance/développement/ analyse 
serait trop lourd

@+;

D.