Je trouve les échanges très riches et très constructifs.
A la vue des écrans de Pascal, j'ai l'impression que nous avons tous des développements que nous faisons et qui n'apparaissent pas dans dolibarr.
Pour ma part j'ai refondu, avec l'école de commerce de Clermont-fd, les parties CRM, gestion commerciale et gestion d'activités (cf. ecrans ci-joint). Je travaille actuellement sur la partie gestion d'équipes avec visions managers.
Pour faire ces modifications je n'ai pas eu le choix, j'ai du modifier le coeur de dolibarr et modifier des parties de code html. Certains blocks (notamment les graphiques) demandent à apparaitre à différents endroits.
Je ne suis pas assez expert template pour savoir si les templates vont simplifier ou complexifier les merges de ce type de modifications dans le coeur de dolibarr. Mais je pense qu'il faut aussi le prendre en compte.
Aujourd'hui toutes mes modifications (disponible sur github dans une branch dédiée) ne sont pas rapides à intégrer car il y a de nombreux changements à divers endroit. Un modèle "MVC" sera-t-il un atout et un accélérateur d'ajout de fonctionnalités et de merge ? Peut être que cela peut aussi simplifier la création d'affichage en fonction des profils d'utilisateurs et remplacer les nombreuses variables ?
Bonne journée à tous,
Hervé
PDG Symeos
158 avenue Léon Blum
F-63000 Clermont-Ferrand
Tel : +33 4 27 46 39 60
address@hidden
De: "Pascal Aubry" <address@hidden>
À: "Jean Heimburger" <address@hidden>
Cc: "Maxime Longuet" <address@hidden>, address@hidden, "Hervé Prot" <address@hidden>, "Régis Houssin" <address@hidden>, "Cyrille delambert" <address@hidden>
Envoyé: Mercredi 17 Août 2011 10:47:00
Objet: Re: [Dolibarr-foundation-board] Installation wizard
À: "Jean Heimburger" <address@hidden>
Cc: "Maxime Longuet" <address@hidden>, address@hidden, "Hervé Prot" <address@hidden>, "Régis Houssin" <address@hidden>, "Cyrille delambert" <address@hidden>
Envoyé: Mercredi 17 Août 2011 10:47:00
Objet: Re: [Dolibarr-foundation-board] Installation wizard
Bonjour à tous,
Oui je pense effectivement qu'une réunion serait la bienvenue.
J'imagine Maxime, que je dois prendre pour moi : "Certains ont alors dérivé avec "ergonomie"" :)
Chez TECLIB' nous avons réalisé plusieurs ajout d'interface type tableaux ou graphiques basés sur ExtJS et JQuery que nous avons présenté à Laurent lors de Solutions Linux, cf screenshots ci-dessous. Je ne dis pas que c'est la solution à l'avenir, c'était pour répondre rapidement à nos besoins internes.
Je rejoint Cyrille sur "Pour une application modulaire, une couche MVC digne de ce nom est
indispensable. Mettre en place un système MVC n'est pas une histoire du puriste "
Réduire la complexité (et le temps de débug et maintenance du code) par subdivision et sérialisation du code est nécessaire dans une application ayant atteint un développent significatif mais elle doit obligatoirement être accompagnée par la constitution d'une documentation solide permettant de s'y retrouver (à plusieurs !) dans tous ces nouveaux morceaux.
Mais je pense comme Laurent qu'il faut rester le plus simple possible et ne pas réaliser une usine à Gaz, des étapes intermédiaires ou une séparation partielle pourraient donc être la bonne solution (entre Full MVC, Templating ou simple séparation de l'affichage et le traitement des données il y a de la marge).
Quoi qu'il en soit, je pense indispensable de garder un seul projet pour préserver la notoriété et la crédibilité de la solution. Je suis persuadé que nous pouvons nous entendre malgré les petits pics que je perçois ça et là.
Un projet libre et une aventure collaborative !
Bonne journée
pascal
----- Mail Original -----
De: "Jean Heimburger" <address@hidden>
À: "Régis Houssin" <address@hidden>
Cc: "Maxime Longuet" <address@hidden>, address@hidden, "Pascal Aubry" <address@hidden>, "Hervé Prot" <address@hidden>
Envoyé: Mercredi 17 Août 2011 07:55:56
Objet: Re: [Dolibarr-foundation-board] Installation wizard
Salut à tous,
Oui il faut une réunion pour éclaircir et trouver ue synthèse.
Le mail accentue toujours les positions et peut paraître plus violent et
dur que la réalité qui est exprimée.
Dans ce débat, il y a pas mal d'éléments à reprendre. Pour arriver à les
transformer en une synthèse, à partir de laquelle on peut prendre des
décisions puis lancer des actions. Il ne fautpas que la réunion soit
juste une tribune où les diverses positions se retranchent.
Alors, pour préparer, on devrait bien relire les différents messages, ne
pas s'arrèter à ce qui nous a peut être un peu agacé ou agressé, pour
prendre les idées exposées et pour chercher ce qui nous paraît important
et utile pour le projet dolibarr, son présent et son futur.
@+
Jean
Régis Houssin a écrit :
> mon message a été coupé suite à une mise à jour d'un logiciel open
> source qui c'est mis à jour ! (ça c'est pour la petite histoire...)
>
> Respect Maxime !
>
> Il sera bon de se parler de vive voix début septembre pour dissiper les
> diverses incompréhensions d'un dialogue de sourd mailisé...
>
> http://rdv.dolibarr.fr/meeting/showua/h/66h7m
>
> nous ferons le point à ce moment là car beaucoup de choses sont a
> prendre et à laisser dans toutes les situations et tous les sens du
> termes...
>
> Je tenais à m'excuser d'avoir lancé une polémique sur le sujet, parfois
> je suis dépassé par l'ampleur du projet et par les demandes des clients,
> c'est très compliqué de mixer les deux...
>
> Malgré la lenteur de conversion du code, je reste persuadé qu'un fork
> nuirait considérablement, à moyen ou à court terme, à la réputation de
> l'application.
>
> Nous allons trouver un compromis... c'est notre force !!!
>
>
>
>
>
>
> Le 16/08/11 20:14, Maxime Longuet a écrit :
>
>> Bonsoir,
>>
>> Je vous livre mon petit avis sur la question. Cet avis repose sur l'expérience d'autres développements ; je ne connais pas assez bien le coeur de dolibarr pour donner un avis tranché. Et je pense également que ce genre de point ne peut-être débattu par simple échange de mail.
>>
>> Les premiers mail étaient sur la mise en place d'un système de template. Sur ce point là je rejoint Laurent sur la difficulté d'un "Vrai" système de template pour la maintenance, le debugage : direction usine à Gaz assuré. Ce n'est pas pour rien que de nombreux logiciels open source ne disposent pas de système de template pour la partie BackOffice.
>>
>> Après il faut savoir ce qu'on appelle mise en place de "système de template".
>> - Est-ce qu'on parle ici d'un vrai modèle MVC ? Et là au secours... Les puristes seront contents, mais accrochez-vous en dev, faudra du gros niveau pour avoir des contributeur (cf magento).
>> - Ou simplement un peu plus de séparation dans des fonctions d'affichage de page ? Et là il y a peut-être des choses à faire et à mettre en place niveau box, construction de liste, tableau....
>> - La page facture.php avec ces 3200 lignes est effectivement un peu lourde à lire. Mais c'est plus dans la rationalisation du code et sortir peut-être certains bout dans les classes qu'on gagnera en lisibilité plus que dans la mise en place d'un template.
>>
>> Si on parle niveau design pour la mise en place de plus de compatibilité css. Jean a raison, le développement de dolibarr aujourd'hui n'empêche absolument pas d'améliorer le code html produit et de disposer de plus de souplesse dans les CSS. C'est pas parce qu'on aura un système de template que d'un seul coup on va voir des nouveaux design super sexy arrivés.
>>
>> Un point été soulevé sur les interfaces mobiles. Là je pense clairement qu'utiliser des css ou des simples template web distinct pour un accès mobile c'est un peu passé de mode. Si vous voulez profiter pleinement de l'interface d'un android, d'un iphone ou d'un ipad il faut développer en direct avec les SDK. Par contre continuer le travail du module web service avec son API SOAP permet de dialoguer avec le moteur de dolibarr, là ça devient intéressant pour développer une interface mobile. Et dans ce cas là il n'y a pas trop de duplication de code.
>>
>> Certains ont alors dérivé avec "ergonomie". Effectivement pas mal de point d'ergonomie peuvent être réfléchis et travaillé mais sans forcement le développement d'un socle MVC. Par exemple les tableaux avec des colonnes paramétrable : des solutions existent. Je pense comme cela rapidement à une class de génération d'un grid qui permet d'avoir des colonnes paramétrables. Ou encore la génération d'un grid avec un affichage via Json par une bibliothèque JS type EXT permet aussi de faire de la préférence de colonne suivant les choix de l'utilisateur... Pour l'exemple d'une ligne tronquée dans les tableaux je ne pense pas qu'il serait résolu avec un système de template.
>>
>>
>> Donc Je pense que ceux qui veulent faire une séparation et une mise en place d'un système de template expliquent techniquement à quoi ils ont pensé (MVC, smarty pour des boxes, smarty sur toute les pages, système de template fais maison, de simple classe de génération de contenue.... ). Et à partir d'une proposition technique détaillé, on pourra débattre sur ce point précis, car à partir de simples généralités on se retrouve à dériver et débattre en dehors de la proposition initiale.
>>
>>
>>
>>
>
>
> Cordialement,
>
Oui je pense effectivement qu'une réunion serait la bienvenue.
J'imagine Maxime, que je dois prendre pour moi : "Certains ont alors dérivé avec "ergonomie"" :)
Chez TECLIB' nous avons réalisé plusieurs ajout d'interface type tableaux ou graphiques basés sur ExtJS et JQuery que nous avons présenté à Laurent lors de Solutions Linux, cf screenshots ci-dessous. Je ne dis pas que c'est la solution à l'avenir, c'était pour répondre rapidement à nos besoins internes.
Je rejoint Cyrille sur "Pour une application modulaire, une couche MVC digne de ce nom est
indispensable. Mettre en place un système MVC n'est pas une histoire du puriste "
Réduire la complexité (et le temps de débug et maintenance du code) par subdivision et sérialisation du code est nécessaire dans une application ayant atteint un développent significatif mais elle doit obligatoirement être accompagnée par la constitution d'une documentation solide permettant de s'y retrouver (à plusieurs !) dans tous ces nouveaux morceaux.
Mais je pense comme Laurent qu'il faut rester le plus simple possible et ne pas réaliser une usine à Gaz, des étapes intermédiaires ou une séparation partielle pourraient donc être la bonne solution (entre Full MVC, Templating ou simple séparation de l'affichage et le traitement des données il y a de la marge).
Quoi qu'il en soit, je pense indispensable de garder un seul projet pour préserver la notoriété et la crédibilité de la solution. Je suis persuadé que nous pouvons nous entendre malgré les petits pics que je perçois ça et là.
Un projet libre et une aventure collaborative !
Bonne journée
pascal
Bien cordialement,
Pascal Aubry
Directeur TECLIB'
tél. : 01 79 97 02 78 mob. : 06 37 87 92 30 fax : 01 72 70 31 18
teclib' technologies libres au service de l'entreprise
Pascal Aubry
Directeur TECLIB'
tél. : 01 79 97 02 78 mob. : 06 37 87 92 30 fax : 01 72 70 31 18
teclib' technologies libres au service de l'entreprise
----- Mail Original -----
De: "Jean Heimburger" <address@hidden>
À: "Régis Houssin" <address@hidden>
Cc: "Maxime Longuet" <address@hidden>, address@hidden, "Pascal Aubry" <address@hidden>, "Hervé Prot" <address@hidden>
Envoyé: Mercredi 17 Août 2011 07:55:56
Objet: Re: [Dolibarr-foundation-board] Installation wizard
Salut à tous,
Oui il faut une réunion pour éclaircir et trouver ue synthèse.
Le mail accentue toujours les positions et peut paraître plus violent et
dur que la réalité qui est exprimée.
Dans ce débat, il y a pas mal d'éléments à reprendre. Pour arriver à les
transformer en une synthèse, à partir de laquelle on peut prendre des
décisions puis lancer des actions. Il ne fautpas que la réunion soit
juste une tribune où les diverses positions se retranchent.
Alors, pour préparer, on devrait bien relire les différents messages, ne
pas s'arrèter à ce qui nous a peut être un peu agacé ou agressé, pour
prendre les idées exposées et pour chercher ce qui nous paraît important
et utile pour le projet dolibarr, son présent et son futur.
@+
Jean
Régis Houssin a écrit :
> mon message a été coupé suite à une mise à jour d'un logiciel open
> source qui c'est mis à jour ! (ça c'est pour la petite histoire...)
>
> Respect Maxime !
>
> Il sera bon de se parler de vive voix début septembre pour dissiper les
> diverses incompréhensions d'un dialogue de sourd mailisé...
>
> http://rdv.dolibarr.fr/meeting/showua/h/66h7m
>
> nous ferons le point à ce moment là car beaucoup de choses sont a
> prendre et à laisser dans toutes les situations et tous les sens du
> termes...
>
> Je tenais à m'excuser d'avoir lancé une polémique sur le sujet, parfois
> je suis dépassé par l'ampleur du projet et par les demandes des clients,
> c'est très compliqué de mixer les deux...
>
> Malgré la lenteur de conversion du code, je reste persuadé qu'un fork
> nuirait considérablement, à moyen ou à court terme, à la réputation de
> l'application.
>
> Nous allons trouver un compromis... c'est notre force !!!
>
>
>
>
>
>
> Le 16/08/11 20:14, Maxime Longuet a écrit :
>
>> Bonsoir,
>>
>> Je vous livre mon petit avis sur la question. Cet avis repose sur l'expérience d'autres développements ; je ne connais pas assez bien le coeur de dolibarr pour donner un avis tranché. Et je pense également que ce genre de point ne peut-être débattu par simple échange de mail.
>>
>> Les premiers mail étaient sur la mise en place d'un système de template. Sur ce point là je rejoint Laurent sur la difficulté d'un "Vrai" système de template pour la maintenance, le debugage : direction usine à Gaz assuré. Ce n'est pas pour rien que de nombreux logiciels open source ne disposent pas de système de template pour la partie BackOffice.
>>
>> Après il faut savoir ce qu'on appelle mise en place de "système de template".
>> - Est-ce qu'on parle ici d'un vrai modèle MVC ? Et là au secours... Les puristes seront contents, mais accrochez-vous en dev, faudra du gros niveau pour avoir des contributeur (cf magento).
>> - Ou simplement un peu plus de séparation dans des fonctions d'affichage de page ? Et là il y a peut-être des choses à faire et à mettre en place niveau box, construction de liste, tableau....
>> - La page facture.php avec ces 3200 lignes est effectivement un peu lourde à lire. Mais c'est plus dans la rationalisation du code et sortir peut-être certains bout dans les classes qu'on gagnera en lisibilité plus que dans la mise en place d'un template.
>>
>> Si on parle niveau design pour la mise en place de plus de compatibilité css. Jean a raison, le développement de dolibarr aujourd'hui n'empêche absolument pas d'améliorer le code html produit et de disposer de plus de souplesse dans les CSS. C'est pas parce qu'on aura un système de template que d'un seul coup on va voir des nouveaux design super sexy arrivés.
>>
>> Un point été soulevé sur les interfaces mobiles. Là je pense clairement qu'utiliser des css ou des simples template web distinct pour un accès mobile c'est un peu passé de mode. Si vous voulez profiter pleinement de l'interface d'un android, d'un iphone ou d'un ipad il faut développer en direct avec les SDK. Par contre continuer le travail du module web service avec son API SOAP permet de dialoguer avec le moteur de dolibarr, là ça devient intéressant pour développer une interface mobile. Et dans ce cas là il n'y a pas trop de duplication de code.
>>
>> Certains ont alors dérivé avec "ergonomie". Effectivement pas mal de point d'ergonomie peuvent être réfléchis et travaillé mais sans forcement le développement d'un socle MVC. Par exemple les tableaux avec des colonnes paramétrable : des solutions existent. Je pense comme cela rapidement à une class de génération d'un grid qui permet d'avoir des colonnes paramétrables. Ou encore la génération d'un grid avec un affichage via Json par une bibliothèque JS type EXT permet aussi de faire de la préférence de colonne suivant les choix de l'utilisateur... Pour l'exemple d'une ligne tronquée dans les tableaux je ne pense pas qu'il serait résolu avec un système de template.
>>
>>
>> Donc Je pense que ceux qui veulent faire une séparation et une mise en place d'un système de template expliquent techniquement à quoi ils ont pensé (MVC, smarty pour des boxes, smarty sur toute les pages, système de template fais maison, de simple classe de génération de contenue.... ). Et à partir d'une proposition technique détaillé, on pourra débattre sur ce point précis, car à partir de simples généralités on se retrouve à dériver et débattre en dehors de la proposition initiale.
>>
>>
>>
>>
>
>
> Cordialement,
>
