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.
Cordialement,
Stephen Larroque
Le 9 septembre 2012 19:47, Laurent
Destailleur <address@hidden>
a écrit :
J'ai jeté un coup d'oeil voici le bilan:
Le module est opérationnel et semble bien "non
intrusif", parfait.
Le module offre des fonctions avancées qui nécessite
des notions techniques (clé étrangères, requetage sql,
voir php). Il faudra donc mettre ce point en évidence
car une grande partie de la cible de
Dolibarr sont des utilisateurs qui ne connaissent meme
pas le vocabulaire. Ce point peut se régler
facillement par de l'information dans les écrans et
intitulés des modules.
Il faut aussi résoudre la question de la licence.
Actuellement propriétaire. Pour cela, est-il posible
de refournir le zip envoyé, avec les entetes modifiés
par un entete trouvé dans n'importe quel fichier php
de dolibarr. Ceci pour des raisons de traçabilités. En
effet, on ne peut modifier par nous meme les entetes
de licences de fichier reçu pour les mettre en GPL.
Cela signifierait que celui qui commit viole la
licence. Il faut donc envoyer au commiteur (moi) les
fichiers corrigés.
A mon avis, c'est un bon module pour etre mis sur
dolistore (possède des fonctions un peu trop technique
pour etre en standard) et offre une plus value qu'il
reste intéressant de fournir.
Si toutefois la question de la licence peut etre
résolu, et compte tenu du caractère "non intrusif" du
module, on ne prend pas de risque à le commiter en
standard.
Toutefois, dans un premier temps, il serait intégré
avec un niveau "experimental".
De plus, sa plus-value restant faible (pour un
utilisateur lambda j'entend, la cible de dolibarr) par
rapport à la fonction déjà existante en standard.
Aussi, sa présence générant une multiplication du code
à maintenir je ne sais pas si il ne vaut mieux pas le
laisser comme module "complémentaire". La politique
étant que tout fonction un peu avancé qui peut etre
fourni par module externe doit etre en module externe,
afin de décharger le projet dolibarr meme.
Le 08/09/2012 22:34, Stephen LARROQUE a écrit :
La dernière branche v3 n'a
pas été publiée sur GitHub, il n'y a seulement que
d'anciennes versions là-bas.
Voici la dernière version stabilisée
(v1.3.0.47b4), ci-jointe à ce mail.
Cordialement,
Stephen Larroque
Le 8 septembre 2012
16:29, Laurent Destailleur <address@hidden>
a écrit :
J'ai essayé de récupérer le module
CustomFields
depuis
https://github.com/lrq3000/dolibarr_customfields.git
mais je ne trouve pas le répertoire de
ce module.
Peux-tu m'envoyer le code récent du
module par un zip mail ?
Le 06/09/2012 18:27, Stephen LARROQUE a
écrit :
Très bien,
j'attends votre réponse.
Le 6
septembre 2012 15:49, Destailleur
Laurent <address@hidden>
a écrit :
J'essaie de regarder ce week
end.
Le 6
septembre 2012 15:23, Régis
Houssin <address@hidden>
a écrit :
j'attends la réponse
de Laurent à ce
sujet
sinon en attendant
il est toujours
possible de le
placer sur un projet
doliforge en accès
public et nous
verrons pour
l'intégrer dès qu'on
aura un moment
Le 06/09/12
14:31, Stephen
LARROQUE a écrit :
Bonjour,
Avez-vous
pris une
décision quant
à
l'intégration
de mon module
? Je suis en
effet en
attente de
votre réponse
sous peu afin
que je puisse
clôturer ce
projet et
migrer vers
d'autres
projets.
Cordialement,
Stephen
Larroque
Le
29 août 2012
18:35, Stephen
LARROQUE <address@hidden>
a écrit :
Le
wiki de
CustomFields
est maintenant
en ligne. Il y
a 2 docs: une
utilisateur
(en fait
implémenteur,
car les
utilisateurs
ne voient même
pas le
module), et
l'autre pour
les devs.
Il manque
juste les cas
d'exemples que
je m'apprête à
faire:
J'espère
qu'il est
assez clair et
qu'il vous
donnera une
bonne idée du
fonctionnement
du module.
Cordialement,
Stephen
Larroque
Le
28 août 2012
21:38, Stephen
LARROQUE <address@hidden>
a écrit :
Bonjour
Laurent,
Voici la
version finale
de
CustomFields.
Le Readme
n'est pas à
jour, et je
n'ai pas de
changelog
propre (à part
le mien qui
est en
franglais).
Donc voici
quelques
infos:
- Elle
est
normalement
super
optimisée en
terme de
performances
(utilisation
de caches et
requêtes SQL
super
optimisées),
et le code
aussi a été
refactoré au
maximum (j'ai
mergé les
fonctions qui
avaient des
fonctionnalités
similaires).
- Elle
injecte un
onglet dans
les panneaux
admins des
modules qui le
supporte
(comme
products,
members et
company, pour
les autres il
n'y a pas de
hooks pour les
onglets donc
en attendant
ce n'est pas
implémenté,
mais c'est
juste quelques
paramètres à
rajouter dans
le
conf_customfields.lib.php).
-
Surcharge des
fonctions
d'affichage et
de gestion des
customfields
dans
/customfields/fields/customfields_fields_extend.lib.php
(ça a été
testé par des
utilisateurs).
- Testé
et fonctionne
parfaitement
avec Dolibarr
v3.3 github
(dossier
custom aussi),
Dolibarr
v3.2.0 sans
aucun
changements,
et Dolibarr
v3.1.0 en
modifiant les
includes mais
sans aucun
autre
changement du
code de
CustomFields
(par contre il
faut rajouter
les hooks dans
les fichiers
core de
Dolibarr, mais
c'est juste un
test qui
montre que
CustomFields
est bien
indépendant).
- Pour
avoir une
première
approche du
code de
CustomFields,
je te
conseille de
regarder le
fichier
/customfields/conf/conf_customfields.php,
c'est le
fichier où
toute la
configuration
de
CustomFields
réside, car
presque tout
est
paramétrable
dans ce
fichier, ça te
donnera un bon
aperçu.
-
/customfields/class/customfields.class.php
est la classe
principale de
CustomFields
qui gère la
base de
données.
Ensuite,
/customfields/lib/customfields_aux.lib.php
est une Facade
(design
pattern) qui
simplifie
l'usage de
CustomFields
en ajoutant
les champs
dans $object.
Si tu veux
voir comment
CustomFields
s'utilise,
c'est un bon
exemple.
-
CustomFieldsPDFTest
est un module
additionnel
qui rajoute
une page dans
les pdf. Elle
n'est
pas nécessaire au
fonctionnement
de
CustomFields.
Bon
voilà, c'est
une assez
grosse classe
et très
modulaire,
mais j'ai
réduit le code
au minimum (le
code est même
plus petit que
la première
version de
CustomFields:
maintenant 242
Ko contre 230
Ko, alors
qu'il y a
infiniment
plus de
commentaires!),
et il y a pas
mal de
commentaires.
Par
contre le
Readme n'est
pas à jour,
elle ne parle
pas des toutes
dernières
fonctionnalités
et fonctions
de
simplification.
Je suis en
train de faire
une page sur
le wiki, ainsi
qu'une page de
cas
d'exemples.
Dernière
note:
l'archive que
je t'envois
n'est pas sous
licence open
source, mais
si le module
est accepté
dans Dolibarr,
je le mettrai
bien entendu
en GPLv2+
comme
Dolibarr.
Je te
remercie
d'étudier la
proposition.
Je me tiens à
ta disposition
si tu as
besoin de plus
d'informations.
Cordialement,
Stephen
Larroque
Le
27 août 2012
17:50, Stephen
LARROQUE <address@hidden>
a écrit :
Ok mais je
voudrais finir
deux/trois
derniers
changements
avant, je te l
envois demain.
Le
27 août 2012
17:31, Laurent
Destailleur <address@hidden>
a écrit :
Peux tu me
fournir un zip
du module
compatible
avec la
version dev ?
Le 27/08/2012
17:17, Stephen
LARROQUE a
écrit :
Bonjour,
Je
reviens vers
vous
concernant ma
proposition
d'intégration
de
CustomFields à
Dolibarr.
Je
souhaiterais
savoir votre
décision le
cas échéant,
et sinon
sachez que je
me tiens à
votre
disposition si
vous avez
besoin de plus
d'informations
concernant
CustomFields
et son
fonctionnement.
Cordialement,
Stephen
Larroque
Le
21 août 2012
14:30, Stephen
LARROQUE <address@hidden>
a écrit :
Oui
il est
multilangue,
dans tous les
aspects: que
ce soit pour
l'interface
admin, le nom
des champs, et
les valeurs
des champs.
Par contre il
n'a pas
d'ajax, c'est
possible de le
rajouter mais
j'ai préféré
le laisser
comme une
option pour le
futur, car
l'avantage de
ne pas avoir
d'ajax est que
c'est aussi
pleinement
fonctionnel
avec tous les
appareils
mobiles tels
que tablettes
et téléphones.
Merci de
me tenir
informé de
votre
décision.
Le
21 août 2012
12:17, Régis
Houssin <address@hidden>
a écrit :
comme je te
l'avait dit
j'avais aussi
développé un
module externe
de
champ perso
il fonctionne
en ajax et est
pleinement
multi-langue
(nom des
champs,
nom des
options de
champs, aucune
perte lors de
la
réorganisation
des
champs)
je n'ai pas
testé ton
module, est-il
multi-langue ?
Le 21/08/12
12:10, Stephen
LARROQUE a
écrit :
>
Bonjour,
>
> Je
souhaiterais
vous soumettre
à nouveau la
proposition
d'intégrer
>
CustomFields
dans Dolibarr
afin de
combiner nos
efforts dans
>
l'implémentation
d'une
fonctionnalité
d'extension
facile des
champs
> pour les
utilisateurs.
>
>
CustomFields,
avec la
branche V3,
est arrivé à
un point où il
est très
> stable,
rapide,
fonctionne
avec des
versions de
php et mysql
inférieur
> à celles
requises par
Dolibarr, et
même
fonctionne
avec
d'ancienne
> versions
de Dolibarr
(il faut
biensûr
modifier les
fichiers core
de
> Dolibarr
pour les
anciennes
versions, mais
ça marche très
aisément, et
> montre
l'intéropérabilité
de
CustomFields).
Il est
également très
>
extensible et
automatisé, il
est donc très
aisé de
rajouter le
support
> d'un
nouveau module
de Dolibarr si
besoin est
dans le futur,
mais
> également
le support de
modules de
développeurs
tiers. De
plus, il
> supporte
déjà en natif
la plupart
(quasi tous)
les modules de
Dolibarr.
>
> Qu'en
pensez-vous?
>
>
Cordialement,
> Stephen
Larroque
Cordialement,
--
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de
Gigny
71240 MARNAY
FRANCE
VoIP: +33
1 83 62 40 03
GSM: +33
6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden
Dolibarr
developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development
platform: https://doliforge.org/
---------------------------------------------------------
--
-----------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
Messenger GTalk/Jabber: address@hidden
Tel: 0662724322
Cordialement,
--
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden
Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------
--
Laurent
EMail: address@hidden
--
Laurent
EMail: address@hidden
Web: http://www.destailleur.fr
Messenger GTalk/Jabber: address@hidden
Tel: 0662724322
|