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.