Il me semble que le débat lancé par Régis n'était pas d'utiliser de
connaitre le langage de template (consensus avec Laurent là dessus
depuis février il me semble) mais de décliner le système de template
PHP pour toute l'application.
Mais peut-être n'ai-je pas tous compris.
Le 15/12/2010 23:20, SR Infosystèmes a écrit :
Le 15/12/2010 21:24, Régis Houssin a écrit :
Ce qui m'étonne c'est que tout les projets connu sépare le code php du code html... Est-ce que tout le monde se trompe ? ;-)
Sur le principe, je ne crois pas. Je faisais déjà des trucs dans
ce
principe en... 1989 sans avoir l'impression d'avoir inventé l'eau
chaude. La seule différence était que le langage de template et le
langage de dev étaient... les mêmes (possibilité permise par les
propriétés du langage utilisé d'auto-contenir du code dans... des
variables, entres autres, un des "miracles" de l'interprété).
Il y a quelques temps, un débat important a juste eu lieu dans la
communauté php, sur le "langage" de template. A la fin du fin,
certains
kadors php/mvc ont fini par montrer que le plus approprié était...
php.
En démontrant que faire du php dans de l'html était faire du
template
de toute façon (ce qui n'est pas faux). Mais, on en conviendra,
c'est
du détail par rapport au principe qui semble admis, soit la
séparation
du code avec la présentation. Toutefois pour quel usage réel et
pratique, hein ? (voir plus bas).
Mon opinion, pour autant que j'en ai une (hi), est qu'il semble
souhaitable de séparer le code de la présentation.
Mais que ça doit être implémenté de façon modeste, afin que
Dolibarr
reste une application modeste.
D'un autre coté, il faut considérer quelques petites choses :
Les priorités fonctionnelles et les bonnes volontés disponibles
(pour
améliorer le fond ou rajouter des fonctionnalités ?)
Les performances à conserver et...
La surface disponible de l'affichage (certaines fonctions et/ou
modules
ne passeront pas sur un smartphone sans une re-conception complète
de
l'interface, et donc de la logique du module, ce qui me semble
aller au
delà du problème MVC).
Parce que, in fine, tout traiter en mvc, c'est pourquoi faire ?
simplifier quoi ? autoriser quelles évolutions ?
C'est pour faire "plus propre" seulement (si l'on peut dire) ou
s'ouvrir vers de nouvelles formes de travail, avec d'autres types
de
terminaux ?
Par ailleurs, la discussion me semble aussi (vous avez évoqué
aussi
cela, en dehors de l'aspect mvc) avoir des correspondances avec
les
discussions micro-kernel (mach, windows nt) ou kernel monolithique
(linux). Le micro-kernel est séduisant, en apparence plus souple,
en
pratique moins performant et pose des problèmes de cohérence. La
cohérence me semble le point le plus important, imho, car un
manque de
cohérence est la porte ouverte aux bugs et aux incompatibilités.
Je crois qu'il faut clairement réfléchir sur :
- ce qui doit être le "core" Dolibarr (bien monolithique imho)
d'un
coté et... le reste (modules périphériques)...
- la bonne méthode pour une interaction entre le "core" et... le
reste...
- les objectifs de présentation (se limiter aux écrans standard ou
s'ouvrir aux smartphones ? et dans ce dernier cas, comment
"généraliser" certains écrans comme ceux des propales/factures ou
les
tiers/contacts, plutôt prévus pour de grands écrans)
C'est vous les spécialistes, je ne suis qu'une arpette.
Pour ma part, j'en reste à la Compta comme évolution majeure, le
tout
accompagné d'un beau PDF formant un manuel utilisateur de qualité,
en
français et en anglais (bouh, le vilain terre à terre). J'espère
pouvoir un jour contribuer à ces deux objectifs.
Enfin, bon, c'étaient des réflexions de fin de soirée ;)
Bonne nuit à tous.
Amicalement,
Stéphane
_______________________________________________
Dolibarr-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
|