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.