Dans la vraie vie, et pour l'avoir pas mal pratiqué, ça se passe "artisanalement" :
- les designeurs font une maquette statique du site
- les développeurs modularisent et dynamisent le site, et font leur modif css perso dans un fichier css à part.
Changement du design ?
- les développeurs refabriquent une maquette statique intégrant leur css de développeurs (toujours dans un ou des fichiers à part) à coup de visite sur le site fichier > enregistrer sous.
- les designeurs modifient la maquette statique qu'on leur à fourni
- les developpeurs reintegrent la maquette statique modifiée par les designeurs : entre 2 et 4 jours de boulot, sans compter les "oubli" et les bug provoqués
Avec TAL on échappe énormément de cette complexité puisqu'on reste sur quelque chose de très proche de la maquette statique modifiable aussi bien par les dev que par les designeurs à tout moment.
Le seul véritable problème reste qu'en modularisant le site (mise en commun des header, footer, etc.) la page ne peut pas inclure les differents template sans qu'il soient partiellement intrepreté.
Je ne l'ai pas encore appliqué, mais la solution est assez simple, il suffit de rajouter un javascript (desactivé par TAL lors d'un vrai run) qui va s'occuper de parser rapidement le template et inclure les sous templates nécéssaires, comme ça le designeur peut le faire tourner en local sans même avoir un apache qui tourne (enfin sauf sur IE car le mode "file:///" est buggé pour l'Ajax, certains évènements ne sont pas levés du coup ça peut créer des problèmes).
Dans le cas d'un site utilisant pas mal le JS ceci oblige à utiliser un bon chargeur de fichier/gestionnaire de bootstrap en JS pour éviter les problèmes (genre les scripts se lancent lors de l'event window onload alors que tous les templates ont pas été tous ajoutés au DOM => ça ne marcherai pas).
Néanmoins, malgré ces petits problèmes à régler ça reste très faisable et on obtient alors le site parfait de collaboration dev/designeurs.
Pire, en utilisant un mercurial et en expliquant rapidement comment l'utiliser (avec TortoiseHg par exemple) au designeurs, qui n'ont souvent pas d'accès direct (studio externe, ou interne) au SVN/CVS/etc. on peut même travailler avec eux efficacement (en utilisant les patchs queue... pour lui c'est un click, pour nous des heures de gagnées), au lieu de travailler avec des échanges de zip par mail comme c'est souvent le cas...
[^] # Re: Evidemment que c'est interessant !
Posté par Temsa . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 3.
- les designeurs font une maquette statique du site
- les développeurs modularisent et dynamisent le site, et font leur modif css perso dans un fichier css à part.
Changement du design ?
- les développeurs refabriquent une maquette statique intégrant leur css de développeurs (toujours dans un ou des fichiers à part) à coup de visite sur le site fichier > enregistrer sous.
- les designeurs modifient la maquette statique qu'on leur à fourni
- les developpeurs reintegrent la maquette statique modifiée par les designeurs : entre 2 et 4 jours de boulot, sans compter les "oubli" et les bug provoqués
Avec TAL on échappe énormément de cette complexité puisqu'on reste sur quelque chose de très proche de la maquette statique modifiable aussi bien par les dev que par les designeurs à tout moment.
Le seul véritable problème reste qu'en modularisant le site (mise en commun des header, footer, etc.) la page ne peut pas inclure les differents template sans qu'il soient partiellement intrepreté.
Je ne l'ai pas encore appliqué, mais la solution est assez simple, il suffit de rajouter un javascript (desactivé par TAL lors d'un vrai run) qui va s'occuper de parser rapidement le template et inclure les sous templates nécéssaires, comme ça le designeur peut le faire tourner en local sans même avoir un apache qui tourne (enfin sauf sur IE car le mode "file:///" est buggé pour l'Ajax, certains évènements ne sont pas levés du coup ça peut créer des problèmes).
Dans le cas d'un site utilisant pas mal le JS ceci oblige à utiliser un bon chargeur de fichier/gestionnaire de bootstrap en JS pour éviter les problèmes (genre les scripts se lancent lors de l'event window onload alors que tous les templates ont pas été tous ajoutés au DOM => ça ne marcherai pas).
Néanmoins, malgré ces petits problèmes à régler ça reste très faisable et on obtient alors le site parfait de collaboration dev/designeurs.
Pire, en utilisant un mercurial et en expliquant rapidement comment l'utiliser (avec TortoiseHg par exemple) au designeurs, qui n'ont souvent pas d'accès direct (studio externe, ou interne) au SVN/CVS/etc. on peut même travailler avec eux efficacement (en utilisant les patchs queue... pour lui c'est un click, pour nous des heures de gagnées), au lieu de travailler avec des échanges de zip par mail comme c'est souvent le cas...