Pour info
Le 10/09/2012 13:46, Stephen
LARROQUE a écrit :
Bonjour Laurent,
Je te remercie d'avoir étudié ma proposition avec
sérieux.
Je vais ici répondre point par point à tes
interrogations:
- Au sujet de la licence, aucun soucis, j'avais
indiqué dans un mail précédent que je suis tout à fait
d'accord de mettre le module en licence GPLv2+ comme
Dolibarr.
- Je suis aussi tout à fait d'accord avec le fait que
le module devrait être committé en experimental en
premier lieu.
- J'ai déjà étudié la solution de mettre le module
sur Dolistore et n'ai pas retenu cette solution.
- Le module n'est destiné à la fois à l'utilisateur
lambda et à l'intégrateur (mais surtout à l'intégrateur)
et aussi au développeur: il y a des niveaux de
fonctionnalités et de complexité pour chacun. Pour
l'utilisateur lambda, il n'y a aucune notion nécessaire,
ils peuvent créer leurs champs simplement dans
l'interface et les utiliser dans leur modèles ODT sans
aucune connaissance technique. Les fonctionnalités
avancées sont réservées à ceux que veulent plus
d'options et sont décrites dans le wiki.
Certes, mais le seul fait de "voir" des fonctons avancées
avec des notions non comprises (comme clé étrnagère, ou
requete sql), suffit our ne pas etre compris par
l'utilisateur, meme si c'est optionnel, c'et genant.
- Au sujet de rajouter des écrans d'information,
effectivement j'ai anticipé et ai déjà rajouté un petit
encart en haut de l'interface d'administration, qui
indique les actions basiques et pointe vers le wiki pour
plus d'informations sur les fonctionnalités avancées. Si
tu as d'autres idées d'aides à rajouter, je me ferai une
joie de les implémenter car je souhaite que le module
soit bien documenté et le plus facile possible à
utiliser.
- Le module peut également être mis dans la page
"complémentaire" si souhaité.
- Quant au fait que "le module n'apporte qu'une
plus-value faible par rapport à la fonction déjà
existante en standard" pour l'utilisateur lambda, je ne
suis pas de cet avis: CustomFields supporte déjà la
quasi-totalité des modules de Dolibarr, permet
d'utiliser un plus grand nombre de types de champs, gère
les champs contraints (ex: lié à une autre table
Dolibarr comme llx_user)
Ceci n'interesse pas l'utilisateur lambda, il ne sait pas ce
qu'est un lien.
et gère l'intégration dans les templates ODT et PDF;
ceci sera aussi dispo avec le module standard
sans compter les fonctionnalités de customization
avancées pour l'intégrateur et le développeur.
Ceci n'interesse pas non plus l'utilisateur lambda
C'est d'ailleurs pour cette raison que je me permet
de proposer à l'équipe de l'intégrer.
Et je t'en remercie.
Toutefois, il faut comprendre la stratégie. La cible est la
suivante :
* Ne mettre dans Dolibarr que les fonctions qui assure les
besoins types standard
* Ne pas mettre de fonctions en doublons sur les
fonctionnalité basiques, si la plus value ne concerne pas
les utilisateurs lambda.
* Ne mettre dans Dolibarr que des fonctions compréhensibles
par un utilisateur lambda. Même si une fonction qui n'est
pas pour lui est optionnelle, si on peut ne pas la faire
apparaitre pour ne pas lui faire peur, il vaut mieux.
* Et pour pouvoir malgré cela offrir un logiciel riche et
puissant et donc garder un compromis entre simplicité et
richesse, ce qui est hors de ce cadre doit être fourni en
module complémentaire (si possible).
Bon, c'et la base, dans la pratique, c'est dur de trouver le
bon compromis. Mais c'et justement la la supériorité
reconnue de dolibarr ar rapport au autres.
N'hésites pas à me dire ce que toi et l'équipe en
pensez, et si vous souhaitez toujours intégrer
CustomFields à Dolibarr.
On pourrait en effet, ajouter des tas de modules aux
fonctions avancées ou aux options variantes, mais cela
grossit dangereusement le code à maintenir. Hors la
politique est de le réduire pour rendre les choses plus
modulaires et externaliser les fonctions.
C'est certes un choix uniquement "tactique", et qui peut
etre discutable, mais dans la mesure ou les concurrents
prennent le chemin inverse (grossir leur coeur pour avoir
plein de fonctions), c'est une maniere de se démarquer et
d'être seul sur un segment abandonnée. C'était aussi
l'engagement pris quand l'auteur du projet m'a demandé de
reprendre son projet.
Ce choix de laisser et rendre encore plus simple (tout en
permettant une utilisation avancée mais sans forcément avoir
ces fonctions avancée maintenu par l'équipe principale) est
donc un choix sur le long terme (car comme toute stratégie,
cela n'a d'effet que sur le long terme), et seul l'avenir
sera capable de dire si il était bon. D'autant qu'il n'y a
pas qu'une seule bonne stratégie, il peut y en avoir
plusieurs. Mais pour un projet donnée, une seule ne peut
etre appliquée à la fois pour avoir un sens. Aussi il en
faut bien une, et l'évolution de popularité et
l'agrandissement de la communauté ces dernières mois avec
les dernieres versions, montre que meme si il y en a
d'autres, de bonnes stratégie, celle n'a semble faire partie
des payantes, même si c'est l'une des plus dur à suivre (la
facilité étant d'integrer chaque commit de chaque besoin de
chacun).
Ce que je propose, c'est que, comme ton modules est non
intrusif, son ajout mais aussi suppression pouvant se faire
sans risque, c'est de le mettre en experimental.
Je vais l'intégrer aussi dans une nouvelle section dont je
n'ai pas encore trouvé de nom pour signaler que le module
évoque des concepts techniques, a moins que je ne fasse une
rubrique "experimental" pour y mettre les modules
experimental plutot que dans leur rubrique dédiée. Hum, y
aura surement des retours à mon mail pour me faire trancher.
Je te dirais quand c'est commité (j'espere faire cela cette
semaine).
On verra apres comment cela évolu.
J'ai mis le bureau en copie, car pour une fois que
j'explique certais letimotiv, cela ne peut pas faire de mal.