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
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
----- 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,
>