|
Salut à tous Contrairement aux habitudes je ne vais pas répondre dans le texte pour plus de clarté et faire court (enfin essayer :-) ). Concernant l'encapsulation des appels à la base de données : il est vrai que cela ne nécessite pas un framework en soi. par contre l'intérêt de disposer de "connecteurs" sur des bases autres que mysql est intéressant. Je citais Postgres car je pensais à une passerelle vers PhpCompta (j'utilise dolibarr et l'utilisation conjointe avec phpcompta n'est pas possible parceque dolibar n'est pas porté et ne peut pas être simplement porté sur postgres). Dans le cas d'une assoc., je pense que Galette devrait rester sur la partie Gestion des adhérents, sans aller construire un plugin de compta. L'intérêt de plugins permettant d'activer des fonctionnalités à la demande est effectivement nécessaire. Là aussi un framework n'est pas nécessaire. Mais les principes d'une approche MVC devront être respectés. Prenons l'exemple du reporting : - En tant qu'utilisateur final, l'export CVS n'est pas satisfaisant : Qu'est ce que je fais une fois l'export effectué ? il faut importer dans un tableur, mettre en forme, ... : c'est lourd quand il faut le faire toutes les semaines pour plusieurs tableaux (par exemple en début d'année quand il faut surveiller le remplissage des cours, faire les relances sur les certificats médicaux, ... ) - de plus, des exports CVS qui génèrent un fichier par table ce n'est pas top : il faut ensuite refaire des jointures dans le tableur. Pas à la portée de tous. Donc il faut une approche plus adaptée aux besoins des utilisateurs qui nécessitera : - de prévoir plusieurs type de listings : Adhérents, Licences, Cours, Equipes, Compétitions, ... - l'alimentation de ces listing doit être faite à partir d'objets métiers interfaçant la base de données et collectant les données à partir de plusieurs tables si nécessaire (remarque : ces objets métiers ont les retrouvera aussi dans les différents écrans de l'IHM) - et finalement avec un export CVS (ou autres : PDF, ... ) pour une reprise dans un tableur Pour la partie reporting : je comparerai ces "objets" ou "vues" métier aux univers de l'outil de reporting Business Objets. Ne serait-il pas possible de proposer des écrans de reporting (ou d'export) pour chacune de ces vues, dans lesquels on sélectionne ses données. A partir des données sélectionnées, un listing est dynamiquement construit. D'ailleurs avez vous jeté un oeil sur des classes PHP qui proposent de construire rapidement des listings à partir de requêtes SQL ? et si on généralise, on pourrait sélectionner des données de "vues métier" différentes, par exemple : - la vue Adérents : pour avoir le nom, prénom, coords. téléphonique - la vue Cours : pour avoir le numéro, le jours et le nom de l'animateur du cours afin de construire un listing des enfants des cours à remettre aux animamteurs. Ceci est réalisable si les jointures entre les objets (en fait les tables) sont déjà connues de l'applicatif. Si vous êtes intéressés je vous mettrai en ligne une version de la '0.63 customisée' pour mes besoins, suite à quoi en fonction de vos retours je m'attaquerai à un doc regroupant les différents besoins de gestion des adhérents et des activités d'une association, sportive ou non. Il est clair que ce type de doc devra ensuite être complété par d'autres personnes. A+ Christophe Sylvain VRIGNAUD a écrit : Re ! contact a écrit : -- Président de la section "Montagne et Escalade" du Trait d'Union de Verrières le Buisson (TUVB) email : contact@xxxxxxxxxxxxxxxxx Site Web : www.tuvb-escalade.org Membre de l'April - « promouvoir et défendre le logiciel libre » http://www.april.org |