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 !
Re: [Galette-devel] Plugins - L'heureux tour