Wow !!!
D'abord : Merci !
Ensuite : Bravo !
Il faut admettre que mettre les mains dans le code d'OpenSondage n'est pas chose facile, parce qu'on a toujours été un peu les doigts entre deux touches concernant ce projet.
D'abord un fork de STUdS, il a été hébergé sur le compte github perso d'un de nos membres :
https://github.com/leblanc-simon/OpenSondageEnsuite quand Framasoft a ouvert son compte Github, on l'a forké dessus :
https://github.com/framasoft/OpenSondageEt là, comme c'était mon premier projet sur github, j'ai un peu merdé entre les branches (master et framasoft).
Enfin, une refonte from scratch était prévue dans le cadre d'un mécénat de compétence avec la SSLL Alterway, mais le projet a traîné, et cette option semble aujourd'hui plutôt enterrée.
Bref, c'est un peu le parcours du combattant pour savoir vraiment où en est ce projet.
C'est d'ailleurs l'objet du message
https://github.com/framasoft/OpenSondage/issues/52Dit autrement : on a forké le projet STUdS, mais on a jamais pensé que Framadate fonctionnerait aussi bien et qu'on souhaiterait l'améliorer dans le temps (oui, c'est stupide, mais que le premier qui n'a jamais développé un truc Quick & Dirty parce qu'il était préssé et ne pensait pas voir son projet utilisé par d'autres que lui me jette la première pierre).
Evidemment "Yakafokon" ("repartir de zero", "prendre du temps pour nettoyer tout ça", "nommer un nouveau mainteneur", etc...)
Le souci, c'est que le mainteneur par défaut, ben c'est moi
(parce que j'ai participé activement au fork de studs, et que je suis salarié de Framasoft). Mais que je n'ai absolument pas demandé cela, et surtout, j'ai aujourd'hui bien d'autres missions qui m'empêchent d'y consacrer du temps. Je suis évidemment prêt à passer la main à qui la voudrais (suffit de proposer quelques patches pour commencer), ou que je m'y recolle, mais ça ne pourra pas être avant septembre 2014, car on a beaucoup d'autres projets dans les tuyaux.
Alors forcément, je ne te cache pas que ta proposition m'interessse !
Maintenant, les réponses à tes questions :
- Pourquoi utiliser une couche d'abstraction pour l'accès aux SGBD sachant que le SQL d'installation est uniquement conçu pour MySQL ?
C'est une erreur qui ne devrait pas exister : en forkant STUdS, on s'est aperçu qu'il y avait des manques. Par exemple par de possibilité de "désactiver" un sondage (on peut juste les supprimer). On a donc rajouté un champs dans le schéma mysql, mais pas PgSQL & co. Et du coup, ça générait une incohérence. C'est pas grand chose à fixer, mais c'est un peu de temps, et pas mal de tests dans des environnements différents.
- La traduction en plusieurs langue est-elle utile ?
J'aurai pu te répondre non, mais j'ai reçu la semaine dernière des pull-requests d'un allemand
https://github.com/framasoft/OpenSondag ... 4056d8be45 . Donc, c'est utilisé "ailleurs".
Alors, maintenant, on fait quoi ?
Ben je te propose déjà de jeter un oeil aux "issues" ouvertes sur
https://github.com/framasoft/OpenSondag ... state=openTu y trouvera sans doute de quoi améliorer "ton" fork à moindre frais.
Ensuite, je te propose de partager le code de ton application (sur github si tu l'utilise, ou via un autre moyen), histoire qu'on puisse collectivement regarder, commenter et expérimenter.
Au pire, je peux en faire une nouvelle branche sur notre Github.
Si les modifs sont interessantes, on pourrait envisager alors de substituer le code de Framadate avec celui de ton application (en passant évidemment par une instance de tests avant).
Qu'en dis-tu ?