Haml — Une moteur de template génial

[Sephi-Chan]

C'est entendu, PHP est suffisant : le moteur de template ne fait que l'abstraire.

C'est tout de même plus simple de s'y retrouver dans un template Haml (et certains autres langages de template) que dans son équivalent PHP (ou Erb, dans le cas de Ruby on Rails). On a moins de risque de faire une connerie genre oubli de fermer une balise HTML, une accolade, etc. Cf. le code d'exemple proposé dans le premier message.

Enfin, cerise sur le gâteau pour les personnes regardante à propos du code HTML généré : celui produit par Haml est parfaitement indenté et bien formé.

Un éditeur permet de colorer le code et d'éviter les erreurs basiques, ce n'est pas qu'une question de compétence. Je me débrouille pas mal en PHP, pourtant j'utilise Eclipse pour colorer le code, et ça me signale des erreurs bêtes.

Comment les templates haml sont-ils validés ? Si on écrit une structure fantaisiste car mal indentée, que se passe-t-il ?

Ah, je pensais que tu parlais d'éditeurs HTML plus évolués, façon Dreamweaver et compagnie.

Je n'ai eu aucun mal à trouver un profil de coloration syntaxique Haml pour mon éditeur, Textmate. Voilà ce que ça donne :


Du côté de Rails, une exception est lancée si l'indentation est mauvaise : il est donc très simple de voir où ça foire. Exemple :




Sephi-Chan

[naholyr]

[mode="anti-fanboy"]Bof. Haml, RoR, Textmate, iPhone, toussa c'est tout des trucs pour kikoolol accroc aux buzz et soucieux de penser "innovation" tout en faisant du coup comme tout le monde.[/mode]

Ceci étant dit, je n'aperçois surtout pas d'innovation intéressante dans ce système...

Pour moi le seul moteur de template réellement innovant ça a été TinyButStrong car l'idée d'être compatible avec les éditeurs wysiwyg était réellement intéressante. N'en ayant pas besoin je me contente de faire du HTML, avec des marqueurs standard pour les variables et les structures de contrôle (que ce soit "<?php echo $variable ?>", "{{variable}}", ou "%variable%" franchement ça ne change pas grand chose).
L'autre avantage étant que ce n'est pas mon moteur de template qui décide du format de sortie de mes données : si je veux faire du XML, du JSON, du CSV, etc... je peux parce que mon moteur de template se contente de faire du remplacement de variable, pas de générer la structure. En ça je trouve qu'on se prive plus de liberté qu'autre chose

Ma première phrase était volontairement provocatrice mais c'est vrai : dans tous ces effets de mode il n'y a que du vent. Rails c'est vraiment "kikoo on a un truc super innovant qui révolutionne tout" mais il n'y a rien de nouveau (à part des raccourcis syntaxiques imbitables qui en font un langage write-only). Textmate tous les apple-maniac ne jurent que par ce super soft mais OMG : à part une bonne coloration syntaxique il n'y a rien sous le capot, go Vim à ce compte là... Et désolé Sephi je t'aime bien donc ça me fait de la peine d'être aussi cruel, mais franchement Haml ça fait partie du même package, touche les mêmes personnes, et propose les mêmes ingrédients (promesse de révolution, fausses innovations, et au final perte de fonctionnalités).


P.S pour ceux qui disent que les graphistes ne devraient pas avoir à apprendre un nouveau langage blablabla : Réveillez-vous, entre le développeur et le graphiste il y a un 3e larron qui s'appelle "intégrateur HTML". Soit c'est le graphiste et dans ce cas là il connait HTML (et en entreprise un mec qui connait HTML sans connaitre au moins les rudiments du PHP, il se cache tout rouge de honte), soit c'est le développeur (qui a une licence Photoshop pour faire les découpages, donc en général c'est plutôt le graphiste ) et du coup bah il connait bien aussi... Le coup du "ne pas faire apprendre de langage aux graphistes" c'est ridicule, parce que du moment que le graphiste a le rôle de l'intégrateur HTML, il doit connaitre un langage de balise qui s'appelle HTML. Et de toute manière même si c'est un vrai boulet, il sera au moins capable de mettre des bouts de texte clair ou des commentaires dans son HTML genre "<!-- répéter ce bloc pour chaque utilisateur -->" ou "{ici l'âge du capitaine}" que le développeur saura avec une dextérité déconcertante transformer en vrai template.
Faux débat donc, la réalité du terrain le montre chaque jour.

[wild-D]

haml , c'est yaml version html ? (désolé la flemme d'aller voir la doc ou quoique ce soit d'autre pour vérifier par moi-même).

le jour ou on pourra prototyper l'application complète avec ce genre de proto-langage de manière unifiée je dis pas non.(l'idée d'utiliser le formatage comme élément du langage me paraît intéressante, ça permet d'avoir quelque chose d'unifié niveau codage et cohérent entre la présentation et ce qu'on a "fonctionnellement") Mais j'avoue que se retrouver à utiliser un langage de plus pour une bribe de l'appli ça en réduit fortement l'attrait.(que ce soit sous symfony pour des éléments de config/déf de modèle, ou bien là avec haml pour un template)

[Sephi-Chan]

Je me permets de dévier puisque j'ai fais ma présentation et que tout le monde s'en fout.

Désolé Naholyr, mais je ne suis vraiment pas d'accord avec toi sur l'effet Fanboy. Ça me déçoit un peu venant de toi que tu penses qu'on utilise forcément les choses parce que c'est à la mode et pas parce que ça nous plaît.

Je me suis intéressé à Ruby on Rails suite au buz qu'il y a eu (un peu plus tard, en fait) et parce que j'ai pu voir quelques aperçu qui m'ont plu (de la part de Oxman, notamment). J'ai donc essayé, appris, et maintenant je suis fan.

Crois-tu que c'est parce que c'est à la mode que les gens l'utilisent ?
Je pense (et c'est mon cas) que c'est simplement parce que c'est bien. Finalement, on s'en fout que ce soit ou non en plein buzz, l'essentiel n'est-il pas que ce soit efficace et que ce soit utile ?

J'ai essayé plusieurs frameworks pour PHP : Code Igniter, Copix, Jelix, CakePHP, Zend Framework (avec pas mal de temps passé sur les deux derniers cités), j'étais tenté d'utiliser Symfony. Et finalement, j'ai vu Ruby et j'ai essayé. Au final, je suis plus productif que jamais : Rails m'a vraiment apporté quelque chose (en plus d'enseigner des bonnes pratiques).

Donc le fin mot de l'histoire, c'est qu'il faut arrêter de juger les gens parce qu'ils utilisent telle ou telle application/OS :

• J'utilise un Mac parce que j'ai voulu tester et que j'aime bien Mac OS X et la machine que j'ai (après certains diront "on s'en fout de la gueule de la machine", ben mois je m'en fous pas, j'aime avoir de belles choses) ;
  
• Je développe avec Textmate (ou XCode pour les langages compilés) parce que j'apprécie sa légèreté, ses snippets, sa coloration, que je n'aime pas les éditeurs en console et que de pouvoir le lancer depuis le CLI me plaît.
  
• J'utilise Ruby on Rails parce que le langage Ruby est très bien fichu, que le code est compact et clair, ainsi que plein d'autres raisons que j'ai cité (ou pas) ;
  

Sephi-Chan, énervé par les préjugés

[Roworll]

Je me permets de dévier puisque j'ai fais ma présentation et que tout le monde s'en fout.

Houla. c'est pas un poil réducteur ?

C'est pas évident d'amener les gens à de nouveaux langages/méthodes.
Il y a la barrière de l'apprentissage, des habitudes et la résistance naturelle au changement.
Apprendre un nouveau langage ou se pencher sur un nouvel environnement prend du temps. Tout le monde n'en dispose pas. Vient ensuite la question de l'intérêt.

Si je prends mon cas par exemple, j'ai déjà deux-trois trucs en PhP sur les bras, plus le boulot, plus la famille. Si je réussis à dégager 2H par jour pour mes projets, je suis déjà content. Je me vois mal m'investir dans un truc tout à fait nouveau... Et pour en faire quoi ?
Refaire le dev de mon projet à partir de 0 ? Cela implique au passage de trouver un hébergeur de serveurs mutualisés capable de supporter ce langage.
Repartir sur autre chose ? J'ai déjà assez de trucs en cours.

Curieux par nature, je suis allé voir les différents liens. Effectivement, ça semble sympa. J'aurai du temps ou je démarrerai quelque chose, je me renseignerai plus en profondeur. Mais en l'état actuel, je ne crois pas que ma femme accepte de me voir passer des heures sur le PC a apprendre un nouveau langage et mon employeur verrait surement d'un mauvais oeil que je me pointe à la bourre et fatigué parce que j'ai codé jusqu'à pas d'heure.

Partager ce que tu trouves d'intéressant dans le haml/ruby est une bonne chose, j'ai fait de même avec le XSLT. Ensuite, c'est aux lecteurs de pousser leurs recherches plus avant. Il n'y a pas de "croisade" à faire.

Inutile de t'attendre à un engouement massif même si tu trouves ce système génial. Soit objectif, parle des points forts et des points faibles, aides les gens à démarrer en leur expliquant les erreurs classiques à éviter. Ce sera plus profitable de donner des exemples et des tutos plutôt que de lancer au bout d'une dizaine de posts que "tout le monde s'en fout".

Je le répète, les gens sont par nature résistants au changement.

[pascal]

Je me permets de dévier puisque j'ai fais ma présentation et que tout le monde s'en fout.

Ne boude pas
Il y a plus de 14 réponses à ton post initial

Les + de haml :
- lisibilité

Les - de haml :
- remplace le html, qui est normalement connu
- yet another templating system
- une couche de plus entre langage de script et rendu html

(de manière générale, je n'aime pas les surcouches, je préfère que ça reste simple)

Je crois que la meilleure manière de faire la pub pour haml serait de sortir oursons garous avec du html qui roxxe

A+

Pascal

[keke]

Oursons garous ? Connais pas ^^. Un pote à Winnie qui a mal tourné ?

Kéké

[naholyr]

J'étais méchant j'ai trollé honteusement il est vrai Mais je suis désolé je pense sincèrement que ce "modèle" qu'on voit partout (en gros : dév sous Apple qui fait du RoR) n'est que le résultat d'un effet de mode désolant.
Cet avis très discutable et hautement subjectif mis à part, on peut avoir une vraie discussion sur le Haml.

En l'occurrence en mettant de côté tout avis parasite, je trouve sincèrement qu'il n'apporte pas d'innovation particulière, et surtout je trouve que la génération du HTML est plutôt un frein pour un moteur de template qui devrait toujours rester le moins magique possible, surtout que dans le domaine des chartes graphiques on a toujours des surprises qui se cachent dans des détails, et il vaut mieux toujours avoir une maîtrise totale du code (les intégrateurs avec qui j'ai pu travailler sont de cet avis en tous cas). C'est cet aspect qui me rebute le plus.
Et je ne trouve pas de réel avantage pour contrebalancer ça, du coup forcément je ne comprends pas...

Peut-être qu'avec une exemple de ce bidule à base de sélecteur CSS ça aiderait (mais j'avoue que je suis pas convaincu d'avance).

[Sephi-Chan]

Quand je dis que les gens s'en foutent, c'est pas du boudin, c'est un constat ! Moi je m'en fous, je l'utilise et j'aime ça. Mais je trouve que les critiques sont dures et pas toujours justifiées. J'ai jamais vu un aussi bon outil : ça surclasse clairement Smarty ou même TinyButStrong (dont la lisibilité est très moyenne avec ses crochets partout, dès qu'il y a des tableaux ça devient imbuvable).

C'est super sympa des templates si lisibles (donc facilement modifiables). De plus, on a une maîtrise totale du code : Haml n'ajoute rien. Ça permet donc de générer tout type de document XML (XHTML inclus, et même SVG pourquoi pas ).

Les + de haml :
- lisibilité

Les - de haml :
- remplace le html, qui est normalement connu
- yet another templating system
- une couche de plus entre langage de script et rendu html

Pourquoi mettre yet another templating system dans les moins ? Il apporte une vision différente et des choses en plus, en particulier dans sa version Ruby puisqu'il embarque Sass en complément.

Je rajouterai dans les plus que le code produit est impeccable : aussi bien dans l'esthétique que dans la validité (Haml ne risque pas d'oublier pas de fermer une balise).

Je crois que la meilleure manière de faire la pub pour haml serait de sortir oursons garous avec du html qui roxxe

C'est précisément ce que je compte faire. Publier le code source de Oursons Garous afin de faire connaître Rails par l'exemple.

Ensuite, je ne présentais que Haml, puisque son complément Sass n'existe que pour Ruby. Pourtant c'est génial aussi puisque ça permet de créer des feuilles de styles qui embarquent des constantes, des expressions, etc.

!main_container_width = 90

!link_hover = #666

!thumb_width = 50



=generic_link

  :color #333



a

  +generic_link

  :font-weight bold

  :text-decoration none



  &:hover

    :text-decoration underline

    :color = !link_hover



  &:visited

    +generic_link

    :font-weight normal



#main

  :width = !main_container_width + "%"



  #sidebar

    :float left

    :margin-left 20%



    .ie6 &

      :margin-left 40%



img.thumb

  :width = (!thumb_width + 10) + px

  /:border 1px solid red

Est compilé en :

a {

  color: #333;

  font-weight: bold;

  text-decoration: none;

}

a:hover {

  text-decoration: underline;

  color: #666666;

}

a:visited {

  color: #333;

  font-weight: normal;

}



#main {

  width: 90%;

}

#main #sidebar {

  float: left;

  margin-left: 20%;

}

.ie6 #main #sidebar {

  margin-left: 40%;

}



img.thumb {

  width: 60px;

}

C'est donc très pratique, notamment pour nous qui utilisons souvent des maps : changer les dimensions des blocs n'aura jamais été aussi simple et pratique avec ces constantes et expressions.

Voici la référence complète de Sass.


Sephi-Chan

[Ter Rowan]

bon moi perso, j'aime pas trop mais pas pour des raisons d'effet de mode ou pas (comme je ne suis pas la mode je ne sais même pas si ça en fait partie ^^)

simplement, un système basé sur l'indentation est un système qui m'impose une mise en page de mon texte alors que j'ai mes propres conventions de "lisibilité"

ainsi j'utilise l'indentation avec deux significations :

0) même niveau d'indentation que la ligne supérieure = instruction suivant (en séquence) l'instruction du dessus

1) indentation simple = instruction dépendant de la condition du dessus

2) indentation double = même instruction qu') la ligne précédente (dans le cas où l'instruction est plutôt longue,j'évite d'avoir des ascenseurs à manipuler dans tous les sens, je place un retour chariot)

==> autant 0) et 1) ça colle, autant 2) ne fonctionne pas

donc perso , je conteste tes avis positifs :

- la lisibilité, car contrairement à toi, l'indentation me perturbe et j'aime avoir le couple ouvrant/fermant, que ce soit une accolade ou une balise
mais l'ouvrant/fermant, comme la double indentation c'est un argument tout personnel

- fournir un code standard n'est pas un plus : ne pas fournir un code standard est un moins --> ce n'est pas un avantage que d'être correct, c'est juste normal
(mais si je devais absolument choisir entre haml et un autre qui ferait un code un peu foireux, clairement je choisirais haml, la j'ai le choix entre haml et notepad, je choisis notepad^^)


par contre je trouve pas mal le SASS, j'avais du mal à comprendre l'intérêt d'utiliser des expressions, mais après un peu de réflexion, ça donne de bonnes possibilités pour la maintenance en particulier


voilà mon avis, sachant que je me base uniquement sur ce que tu nous a montré (je n'ai pas cherché plus loin que dans tes exemples / argumentations)


et ce n'est pas parce que je ne suis pas convaincu, ou pas écrit avant que je me fous du sujet