Re: [Galette-devel] Plugins - L'heureux tour -- June 02, 2009 - 22:22

Hello,

Le 10/03/2009 21:14, contact a écrit :
> Salut à tous
>
>
> Contrairement aux habitudes je ne vais pas répondre dans le texte pour
> plus de clarté et faire court (enfin essayer :-) ).

Ça ne devrait pas être un problème (moins que de top poster dans tous
les cas :-p).

> Concernant l'encapsulation des appels à la base de données : il est
> vrai que cela ne nécessite pas un framework en soi.

C'est clair. De plus, j'ai pu constater que Galette SVN tourne
parfaitement bien sous PHP 5.3, ce qui n'est pas tout à fait le cas de
pas mal de frameworks (je n'ai pas testé Zend, mais symphony et quelques
autres), ce qui me renforce dans ma position.
En tout état de cause, je suis pour l'instant l'un des seuls
contributeurs à Galette, personne n'est venu me proposer une idée basée
sur un framework (ou pas), et j'ai donc un peu tendance à faire ce que
je veux :p

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

Hum... Là, j'avoue ne pas te suivre. Galette est déjà compatible avec
MySQL et Postgres, d'autres pourraient suivre, mais c'est là bien trop
de travail pour moi (si seulement les SGBD respectaient le standard SQL...).

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

Je suis on ne peut plus d'accord ; et je pense d'ailleurs à ajouter une
partie au site qui concerne ce que Galette *ne fait pas* (la vaisselle,
la compta, la bouffe, etc...).

> 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, ... )

Je pense que dans le cas que tu cites ici, si l'export n'est pas
satisfaisant, il y a deux cas à considérer :
1- l'export est pourri, il faut le modifier. Ça profite à tous, c'est
bénéfique
2- on est tombés sur un cas assez particulier. Soit on fait avec, soit
il y a un dév spécifique, soit, bah... Ils iront voir la "concurrence",
si elle est mieux adaptée ;-) Je ne souhaite pas que Galette soit
utilisé par 100% des assoces francophones, les besoins diffèrent, les
résultats escomptés aussi, mais il semble que Galette répondent à
certains d'entre eux, ne compliquons pas trop les choses (c'est déjà
parfois assez compliqué comme ça).

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

Certes, je suis on ne peut plus d'accord. C'est pour ça que je pense
qu'avoir un panel d'exports « communs » serait une bonne chose. Il
suffit pour les développeur de générer la requête qui va bien, c'est
assez vite fait, ça peut être intégré à la version officielle, à un
patch, à un plugin, très facilement. bref, je vois là pas mal
d'avantages. L'export par tables et la jointure séparée seraient
réservées aux  « experts ». Je ne veux pas non plus brider les gens qui
sauraient faire :-)

> 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

J'avoue que mon approche objet dans Galette est plus liée à la
simplicité du développement et à l'utilisation de technologies «
actuelles » qu'à ce genre de considérations... Si ça peut servir, tant
mieux, mais je n'y aurai pas pensé au départ, c'est clair :-D

> Pour la partie reporting : je comparerai ces "objets" ou "vues" métier
> aux univers de l'outil de reporting Business Objets.

No comments, je ne connais pas.

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

Des exemples de ces fameuses classes ? je n'ai généralement pas le temps
de m'intéresser à tout ce qui se fait de nouveau en php ;-)

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

D'une façon générale, je ne pense pas que ce soit tout à fait réaliste
d'espérer ça... Je me trompe peut-être, mais toujours est-il que ça
demanderai un travail conséquent, de ça, je suis certain.

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

+1 pour le doc
-1 pour la 0.63 custom... Le trunk du SVN est déjà hyper loin de la
0.63, je la considère comme une version en maintenance, pas en dév.

> Il est clair que ce type de doc devra ensuite être complété par
> d'autres personnes.
>
> A+
> Christophe

Merci pour ces remarques, j'espère que mes réponses apporteront au
schmilblick !

See ya,
Johan

Attachment: signature.asc
Description: OpenPGP digital signature