mailRe: [Galette-devel] Plugins - L'heureux tour


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by contact on March 10, 2009 - 21:32:
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 :
  
Bonjour à tous

je constate que nous sommes tous d'accord sur un point : il faut que 
l'application dispose d'une certaine souplesse pour s'adapter à des 
besoins variés qui vont de ceux d'un club de bridge (je n'ai contre le 
bridge) à ceux d'un club multi-sport avec plusieurs sections (ayant 
chacune des besoins différents).
    

Vu le nombre de personnes qui modifient galette à la rache, effectivement !

  
En tant qu'utilisateur, qu'importe la techno pourvu que :
 - la souplesse
 -et les perfs (temps de réponse)
sont là
    

La souplesse, je suis d'accord, c'est facile à maitriser, c'est du 
fonctionnel pur.
Les perfs un peu moins. Ca dépend aussi de la bécane qu'on met derrière. 
Pour une appli de la taille de galette, sommes nous réellement concernés 
par ce genre de problème?

  
En tant que technicien  (bien que j'interviens maintenant plus souvent 
en AMOA ou en gestion de projets que sur la partie technique), j'ai 
une préférence pour un framework :
    

Reste à ne pas mélanger les besoins d'un progiciel d'entreprise à celui 
d'une micro-application web...

  
 - certes il y a une phase d'apprentissage
 - et il est vrai que cette approche risque de faire appel "à une 
usine à gaz" comme le dit plus bas Sylvain
    

L'apprentissage, ça se résoud, si le framework est assez simple.
Un bon Symfony de base tape dans les 5.5 Mo, tout de même !

  
mais j'y vois les avantages suivants :
 - le framework encapsule un ensemble d'appels techniques : par 
exemple pour permettre un portage transparent sur mysql ou postgres 
==> plus de requêtes SQL car on appelle des objets
    
Ca se résoud simplement aussi sans framework. Maintenant les 
utilisateurs de postgres sont plutôt rares malheureusement... ainsi que 
les serveurs... "Bonjour monsieur Free, est-ce que je peux héberger mon 
site avec postgres?"

  
 - il dispose de nombreux plugins  :
    - antispam
    - formulaires
    - reporting
    - l'internationalisation
    - ...
    
Pour la taille, c'est quand même un minimum, je l'accorde ! Reste à 
savoir si c'est nécessaire de se trimballer tous les outils...

  
 - la sécurité est gérée par le framework ==> donc on repose sur lui 
pour les mises à jour
 - l'imortance d'une communauté
    
La sécurité du framework, tout le monde s'en fout. Si déjà les 
utilisateurs mettent à jour la galette, c'est un grand pas, alors le 
framework dedans... euh...
Pour info, y'en a qui mettent à jour adoDB dans leur galette?

La communauté du framework? quel rapport?


  
les 2 frameworks que j'ai regardé (de loin) sont Zend et Symfony.
    

J'ai regardé aussi, maintenant si on a une appli grosse comme un module 
du framework, ça frise presque le ridicule, non?

  
Par contre, je pense qu'il faut clairement aller vers l'utilisation 
des objets de Php 5 ; ce qui semble être le cas de la version 0.7 (?).

    

L'utilisation des objets semble inévitable dans tous les cas. J'ai du 
mal à concevoir quelque chose de simple sans... Mais là dessus, on est 
tous d'accord !

  
De par les outils que j'ai utilisés (lors de projets d'intégration de 
progiciels CRM), j'ai constaté qu'il est important de bien séparer les 
couches d'accès aux données et la couche de présentation. Ce que font 
maintenant la quasi totalité des progiciels.
évolutivité plus facile.
Est-ce qu'un framework permet cette approche plus facilement ? a 
priori oui.
    
La séparation des 3 couches est aussi très importante, elle se dessine 
faiblement à travers de la galette actuellement. On sent une couche 
"adoDB" et une couche "template", même si c'est assez léger. Savoir si 
l'approche dépend du framework, je demande à voir... C'est une question 
d'organisation après.

  
par contre, il faudrait probablement que des dvpeurs déjà aguerris  à 
ces outils rejoignent Galette.

    

Si déjà il y avait des développeurs simplement...

  
en tous cas, tant que la partie  "fonctionnelle" n'est pas plus 
avancée, et donc qu'on pas une meilleure vision de la richesse (et 
complexité) des besoins des utilisateurs, il est peut plus sage de 
rester sur la direction actuelle, au moins pour la 0.7 ?

    
Oui, fonctionnellement il faut pousser l'analyse. Le soucis avec la 0.7, 
c'est qu'on est clairement limité avec l'absence de plugins. Est-il 
vraiment utile de pousser le développement d'une branche qu'on sait déjà 
sans issue?

  
Quand on aura une liste des besoins, on pourra dire si oui ou non 
telle approche est meilleure et ensuite faire une roadmap.

    
Les besoins, on les connait déjà. On sait déjà par définition qu'ils 
sont tous différents suivant les associations. Je pense que certains 
seraient pas contre des petits plugins gérant les facturations ou alors 
la comptabilité, ou bien gérer des activités séparées. Les besoins 
arriveront d'eux même. On peut préparer une liste précise, mais faut pas 
commencer déjà par le fonctionnel?


  
d'ailleurs où peut on trouver un doc qui présente les grandes lignes 
des devs et objectifs de la 0.7 ?
a t-on une liste de "plugins" potentiels ?
    
cf mail de Johan ;)

  
Dans tous les cas, je suis prêt à aider.
    

On a toujours besoin de monde en gestion de projet, mais faut savoir 
proportionner les outils en fonction de l'application et de l'équipe ;)


A+

Sylvain

PS : j'ai quelques idées qui naissent au fur et à mesure du temps, les 
chosent commencent à se mettre en place progressivement. Suite au 
prochain épisode !

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

  


-- 
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

Related Messages


Powered by MHonArc, Updated Tue Mar 17 22:20:14 2009