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.