|
From: aurelien <aur...@os...> - 2011-09-22 20:56:17
|
3 évolutions importantes sur le trunk, 1: Nom des module de configuration 2: nouveau drivers ds le backoffice 3: changement approche dans la gestion du moteurs pdf 1: Nom des module de configuration l'amelioration de la gestion du nom des modules de configuration. les fichier de modules/configuration . Jusqu'a present le nommage dudit fichier et le la class de ce fichier etait nommé cfg_xx et xx corresspondait au group_id contenu dans l'url sous la forme de gID La nouvelle forme d'ecriture exploite la colonne configuration_group_ket de la table configuration_group. L'usage actuel de cette colonne représente la clef de groupe, utilisé lors d'insertion de nouvelle ligne dans la table configuration l'orientation premiere ne devant pas être modifié, la valeur (string) de cette colonne fournis donc le nom du module/class. Pour le moment la premiete methode fonctionne toujours, toutefois pour des quetsion de lisisbilité du code, la seconde methode doit être priviligié. 2: nouveau drivers ds le backoffice Second point, L'ajout d'un type de class, destinée a traité de l'insertion / update / fetch / delete sur une table(s) Le repertoire est situé dans classes/drivers Les fichier doitvent comencer par sqlxxxxx ou xxxx correspond au nom du driver. Il s'agit de fichier/class, donc le fichier et la class qu'il contient portent le même nom Un interface a été ajouté a class.interface pour definir les methodes de ces class Une drivers de ce type à été ajouté, pour traité les modifications de la table configuration. A terme celle ci devrait être utilisé a travers tous le backoffice. Les drivers de ce type ne sont accesible que dans le backoffice. Il devrait centraliser les interaction sur les table de données, et offrir des appels normaliser exploitable plus simplement à travers les page et modules De plus, il sera certainement judicieux d'y integrer la liaison vers les enregsitrement/modification via les modules aca Cette etape franchis, il sera alors possible d'ajuster le code de sortie vers un affichage ou un webservice beaucoup plus simplement, l'ensemble des module de tyep page ne devenant que de simple gestionnaires de pages, sans touch vers le sql 3: changement approche dans la gestion du moteurs pdf Une variable de conf à été ajouté pour permettre d'activer/desactiver la gestion des pdf en local. ( descative aussi la page batch_printer (BO), qui gener les pdf) L'idée de cette approche et de permettre de fournir les webservice correspondant pour autoriser une application tiers à fournir les pdf. Dans une idée de coherance de document comptable, le crm fournis les fichier pdf. Le moteur interne n'est donc pas utilisé, et osCSS ne fait que fournir une liaison vers les fichiers que ce soit dans le BO ou le FO. La liason vers les fichier pdf ne sera pas stocké, aussi il est absoluement necessaire d'utilier la class de manipulation des DataFile afin de garantir l'unicité. Voila pour ce soir |