[Oscss-develop] modules de configuration / drivers dans l'environement du BO

[aurelien <aur...@os...>]

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