[Intermédiaire] Skin : moteur de template (PHP)

Bonjour à tous !
D'habitude, lorsque je viens sur alsacréations, c'est pour chercher des renseignements, apprendre de nouvelles techniques et découvrir de nouvelles technologies. Je n'ai jamais été déçu et n'ai même jamais eu à ouvrir un topic moi-même, vu que, bien souvent, la réponse à ma question s'y trouvait déjà.
Aujourd'hui, je viens vers vous pour vous présenter un projet qui m'a demandé plusieurs mois de travail : Skin, un moteur de template (pour le moment exclusivement en PHP, mais j'ai bien l'intention de le porter en JS).

Pourquoi le poster ici ? Hé bien tout simplement parce que j'aimerais avoir la possibilité d'avoir des retours sur ce projet, des retours concrets de développeurs qui seraient capables d'émettre des critiques concrètes et intéressantes, ce dont je manque cruellement à cette étape de développement.

J'ai créé ce projet dans le but de faciliter au mieux l'utilisation des vues (MVC ou non), de ne plus s'embêter avec les balises PHP dans le HTML et, cerise sur le gâteau, de s'émanciper des balises HTML elles-même.

Malheureusement, j'ai découvert entre-temps l'existence d'un moteur de template en JS, Jade, qui repose sur le même principe d'indentation et d'abstraction du HTML. On notera cependant quelques différences concernant les deux moteurs de template. J'avais déjà bien avancé lorsque je l'ai découvert et, dans un premier temps, j'ai fortement été découragé par mon idée en me disant qu'il y avait trop de similitudes. J'ai finalement décidé de poursuivre le projet en y apportant des fonctionnalités différentes (que je ne détaillerai pas ici parce que ce serait évidemment un peu long).

Je vous invite donc à juger mon travail (le moteur de template bien sûr, pas le tuto en lui-même) et me dire ce que vous en pensez !

Voici le tuto que je suis en train de créer, dans lequel je l'espère, vous pourrez contempler la simplicité d'utilisation et son intérêt.

-> le tuto : http://skin.laegel-developpement.fr/
-> le repo : https://bitbucket.org/Laegel/skin/

Merci d'avoir lu !
Modifié par Laegel (21 Aug 2016 - 15:51)

Bonjour,

Avant tout je salue l'initiative : chapeau bas...

Laegel a écrit :
Malheureusement, j'ai découvert entre-temps l'existence d'un moteur de template en JS, Jade, qui repose sur le même principe d'indentation et d'abstraction du HTML.

C'est exactement à Jade que je pensais moi aussi en lisant le paragraphe précédant ce propos :

Laegel a écrit :
J'ai créé ce projet dans le but de faciliter au mieux l'utilisation des vues (MVC ou non), de ne plus s'embêter avec les balises PHP dans le HTML et, cerise sur le gâteau, de s'émanciper des balises HTML elles-même.

Laegel a écrit :
On notera cependant quelques différences concernant les deux moteurs de template. [...]. J'ai finalement décidé de poursuivre le projet en y apportant des fonctionnalités différentes (que je ne détaillerai pas ici parce que ce serait évidemment un peu long).

Et bien moi, en tant que "JadeUser" inconditionnel ce sont justement ces différences qui m'intéressent : Quelles sont-elles ?

Personnellement j'ai trouvé la syntaxe Jade facile à retenir, d'autant plus qu'elle est directement tirée de CSS. En ce qui concerne votre approche, c'est moins évident, il faut d'emblée apprendre une nouvelle syntaxe.

Par exemple, pour obtenir ceci :

<table class="table table-striped table-hover">

En Jade on fera ceci :

table.table.table-striped.table-hover

La même chose avec votre moteur de template :

table .(table table-striped table-hover)

Un autre exemple dans la même veine avec votre moteur :

p #paragraph .p-one;p-two

Et maintenant - cas d'école - comment procéder avec Skin si je veux obtenir ceci ? :

<span>div > span</span>

Question subsidiaire : quid du support de php (j'ai cru comprendre que le code était échappé "par sécurité") ?
Modifié par Olivier C (21 Aug 2016 - 20:37)

Bonjour Olivier C,
Merci pour votre premier retour.

(question HS : où se trouve la possibilité d'ajouter un blockquote dans l'éditeur du message ?)

Olivier C a écrit :
Personnellement j'ai trouvé la syntaxe Jade facile à retenir, d'autant plus qu'elle est directement tirée de CSS.
---

Skin s'inspire aussi fortement du CSS concernant les attributs "id" et "class".
On peut s'en servir de la manière suivante :

div id(div-id) class(div-class1 div-class2)

div #div-id .div-class1;div-class2

En fait, les valeurs d'attributs sont séparées par des espaces ou des points-virgules lorsque l'attribut est écrit avec des parenthèses (écriture longue), et uniquement par des points-virgules lorsqu'il n'y a pas de parenthèses (écriture courte).

Si on écrit comme dans Jade :

div .div-class1.div-class2

on obtiendra

<div class="div-class1.div-class2"></div>

Je n'avais effectivement pas pensé à ce cas de figure, c'est malheureusement le seul cas où la répétition de l'attribut peut se produire et où elle a un sens (#id1#id2 serait bien sûr inconcevable).

Olivier C a écrit :
Et maintenant - cas d'école - comment procéder avec Skin si je veux obtenir ceci ? :

<span>div > span</span>
---


Il suffit d'écrire :

span
    div > span

Explication : le moteur reconnaît automatiquement une syntaxe d'élément valide d'un texte simple.
Un élément est de la forme suivante :

tagname
//ou
tagname attribute(value)

Il est bien sûr toujours possible d'écrire du HTML à même le template, mais Skin en perd son intérêt.

Olivier C a écrit :
Question subsidiaire : quid du support de php (j'ai cru comprendre que le code était échappé "par sécurité") ?
---


En effet. Je me suis documenté sur plusieurs moteurs de template (Twig, Smarty, Mustache ...) qui existaient déjà quand je me suis lancé et il m'a semblé que le fait d'échapper automatiquement le contenu des variables était un impératif. Il est bien entendu possible d'annuler l'échappement automatique :

{{ myVariable | unescape }}
//ou "ue" à la place de "unescape", son alias

Modifié par Laegel (22 Aug 2016 - 10:53)

Laegel a écrit :
Il suffit d'écrire :

span
    div > span

Explication : le moteur reconnaît automatiquement une syntaxe d'élément valide d'un texte simple.

Pardon, je pensais à un cas de figure bien particulier : celui où des tags et des noeuds de textes à la syntaxe proche des tags sont imbriqués les uns dans les autres. Comment feriez-vous par exemple pour écrire ceci :

<div>div<div>div</div></div>

En Jade je ferais :

div div
  div div

Sinon : Skin a-t-il des points forts par rapport aux autres moteurs de template ?

Envisagez-vous à terme la possibilité de créer des layout patterns comme pour Jade (élément important me semble-t-il ; j'ai vu qu'il existait déjà des @extends et @partial) ?

Olivier C a écrit :

Comment feriez-vous par exemple pour écrire ceci :

<div>div<div>div</div></div>

En Jade je ferais :

div div
  div div

Je trouve cette syntaxe plus perturbante qu'autre chose. J'ai fait en sorte de séparer chaque élément par ligne pour éviter absolument toute confusion dans les templates et faire en sorte de repérer plus facilement les éléments.
Ce code (celui pour Jade) ne donnerait donc rien de plus que du texte avec Skin.
Pour écrire la même chose, cela nécessite de dire au moteur de ne pas considérer les éléments suivants comme des tags mais comme du texte :

//sktext (ou "*") annonce que toutes les éléments enfants de l'élément courant seront du texte simple
div 
    div sktext(true)
    div
        div sktext(true)

Olivier C a écrit :

Sinon : Skin a-t-il des points forts par rapport aux autres moteurs de template ?

Hé bien j'ai essayé de faire quelque chose de simple au possible en limitant au maximum l'injection de logique dans la vue (n'est-ce pas le but du moteur de template, après tout ?).
Par exemple, les boucles et les conditions qui sont toujours indispensable pour rendre le code dynamique sont sous forme d'attribut.
On oublie donc la syntaxe encombrante de Twig :

{% if users %}
    <ul>
        {% for user in users %}
            <li>{{ user.username|e }}</li>
        {% endfor %}
    </ul>
{% endif %}

voici l'équivalent pour Skin :

//skif (ou l'alias "?") est l'attribut pour tester une variable (truthy/falsy)
//skloop (ou l'alias "%") est l'attribut pour effectuer une boucle
//le code est échappé par défaut, pas besoin de rajouter le filtre "escape"

ul skif(users)
    li skloop(users=>user)
        {{user.username}}

Ce n'est bien sûr pas son seul avantage. J'ai créé Skin dans un but bien particulier : le fait de changer de layer (d'où le nom "Skin"). Il est possible de passer du HTML5 au XHTML ou bientôt du HTML5 au HTML6 sans toucher à la moindre ligne du template, simplement en modifiant le type de layer dans la configuration, ce qui rend la maintenabilité des templates d'une grande simplicité.

Il y a aussi un moteur de traductions, il suffit de passer un tableau de données à Translator et d'afficher la valeur désirée dans le template et tout sera fait facilement.

//en_GB.php
return [
    translations: [
        'HELLO' => 'Hello %s !'
    ]
];

//La variable "variable" vaut "world"
{=HELLO | variable=}
//Donnera :
Hello world !

Olivier C a écrit :

Envisagez-vous à terme la possibilité de créer des layout patterns comme pour Jade (élément important me semble-t-il ; j'ai vu qu'il existait déjà des @extends et @partial) ?

C'est déjà à l'oeuvre, en effet.
L'héritage de template, l'inclusion de fragments, tout ceci est déjà fonctionnel et expliqué dans le tutoriel.

J'ai cependant ajouté un petit quelque chose que les autres moteurs n'ont pas : les composants personnalisés.
Ça fonctionne comme un part, sauf que les données restent dans le scope du composant et ne sont pas globales.
Exemple :

//Fichier component.skln
div .component
    {{content}} - {{test}} !

//Fichier main.skln
div
    component content(Hello World !) test({{variable}})

C'est une sorte de macro pour éviter de copier-coller des bouts qui servent à plusieurs endroits, en utilisant les variables contextuelles passées à travers les arguments de l'élément appelant (ici, "component").


Merci encore pour votre attention, Olivier C !

Bonjour, je suis un peu dubitatif, j'ai l'impression de voir un n-ième moteur de template qui reprend les concepts qui ont fait le succès des autres, sans être complètement abouti.

Laegel a écrit :

On oublie donc la syntaxe encombrante de Twig :
…
voici l'équivalent pour Skin :

Pourtant la lisibilité de la syntaxe Twig est bien plus évidente, on la comprend du premier coup d'oeil.
Et comment fait-on pour inclure plusieurs éléments dans la boucle (au lieu d'un li, un div.bar et div.foo qui se répètent). Ou pour donner une classe au li toutes les trois li (ou en fonction des données)?

a écrit :
div
div sktext(true)
div
div sktext(true)

La syntaxe jade est certes perturbante, mais la vôtre est carrément indigeste.

a écrit :
Il est possible de passer du HTML5 au XHTML ou bientôt du HTML5 au HTML6 sans toucher à la moindre ligne du template, simplement en modifiant le type de layer dans la configuration, ce qui rend la maintenabilité des templates d'une grande simplicité.

Et comment on serait passé de div à article / main / section … de HTML 4 à 5? Quant à HTML 6 on attendra que la spec soit commencée pour en juger De toute façon un des avantages des moteurs de templates est de bien séparer logique et structure/présentation, de sorte qu'une évolution est simple. De plus on profite généralement d'une refonte du site pour changer de techno.

a écrit :
J'ai cependant ajouté un petit quelque chose que les autres moteurs n'ont pas : les composants personnalisés.

ça ressemble pourtant à s'y méprendre à des macros en twig par exemple.

kustolovic a écrit :
Bonjour, je suis un peu dubitatif, j'ai l'impression de voir un n-ième moteur de template qui reprend les concepts qui ont fait le succès des autres, sans être complètement abouti.

En effet, je travaille seul dessus, je prends le temps pour m'en occuper et je réfléchis aux fonctionnalités que je peux lui apporter. Si je vous ai fait part de mon projet, c'est aussi pour voir ce que je pourrais faire pour l'améliorer, bien évidemment !
Bien sûr que je me suis inspiré de ce qui existait déjà, je n'allais pas leur tourner le dos alors que c'est ce qui fait leur intérêt. Il faut voir Skin comme une sorte de melting pot des fonctionnalités intéressantes des concurrents et ajouter à cela des fonctionnalités qui lui sont propres.
Skin va encore évoluer, je ne sais aujourd'hui pas exactement en quoi mais c'est mon intention.

kustolovic a écrit :

Et comment fait-on pour inclure plusieurs éléments dans la boucle (au lieu d'un li, un div.bar et div.foo qui se répètent). Ou pour donner une classe au li toutes les trois li (ou en fonction des données)?

Je ne suis pas sûr d'avoir saisi cette question.

kustolovic a écrit :

La syntaxe jade est certes perturbante, mais la vôtre est carrément indigeste.

Je ne suis pas non plus satisfait de cette fonctionnalité, je n'ai pour l'instant rien de mieux à proposer pour rendre ça plus sympa, je l'avoue.

kustolovic a écrit :

De toute façon un des avantages des moteurs de templates est de bien séparer logique et structure/présentation, de sorte qu'une évolution est simple. De plus on profite généralement d'une refonte du site pour changer de techno.

Je pense que Skin fait correctement son travail en terme de séparation de la logique de l'affichage. Si je prends Smarty comme exemple, on est loin de ce résultat.

Bien sûr, une refonte consiste à tout refaire. Mais quid d'une mise à jour importante, un passage vers une nouvelle version du HTML ?

kustolovic a écrit :
ça ressemble pourtant à s'y méprendre à des macros en twig par exemple

Mea culpa dans ce cas, je ne les avais pas vus. J'ignorais même jusqu'à leur existence.
Cela fonctionne plus ou moins de la même manière, oui, au détail près qu'on enlève les balises Twig.

Merci pour votre (ferme mais juste) retour, kustolovic !

Laegel a écrit :

Je ne suis pas sûr d'avoir saisi cette question.

En reprenant votre exemple:

ul skif(users)
    li skloop(users=>user)
        {{user.username}}

comment je gère ces cas là:

<ul>
  <li>kustolovic</li>
  <li>Laegel</li>
  <li class="disabled">Le_Troll</li>
  <li>Olivier C</li>
</ul>
ou
<ul>
  <li><h3>bar</h3></li>
  <li><h3>foo</h3></li>
  <li><h3>fee</h3></li>
</ul>

ainsi: ??

ul skif(users)
    li skloop(users=>user) {.disabled if user.disbled}
        {{user.username}}

ul skif(users)
    li h3 skloop(users=>user)
        {{user.username}}

a écrit :
au détail près qu'on enlève les balises Twig.

Je ne suis pas fan de twig. Mais twig se vend en «enlevant les balises php». J'ai toujours trouvé ça un non-sens comme raisonnement.

a écrit :
Mais quid d'une mise à jour importante, un passage vers une nouvelle version du HTML ?

Je n'ai jamais vu de site faire de «passage vers une nouvelle version du HTML». Par contre, la plupart au bout de 4 à 6 ans refont au minimum le visuel du site, et refont tous les templates / CSS.

kustolovic a écrit :

comment je gère ces cas là:

<ul>
  <li>kustolovic</li>
  <li>Laegel</li>
  <li class="disabled">Le_Troll</li>
  <li>Olivier C</li>
</ul>
ou
<ul>
  <li><h3>bar</h3></li>
  <li><h3>foo</h3></li>
  <li><h3>fee</h3></li>
</ul>

Via Skin :

//Il n'existe pas de test sur l'attribut, je n'avais pas d'idée pour rendre ça simplement. Ici, on part du principe que chaque "user" a avoir une propriété "disabled". Si ça n'est pas le cas, ça n'affiche rien.
//Voici la syntaxe simplifiée, avec les alias :
ul ?users
    li %users=>user .{{user.disabled}}
        {{user.username}}

//Le loop répète tout l'élément courant, ses enfants y compris, comme un "foreach"
ul skif(vars)
    li skloop(vars=>var)
        h3 
            {{var.value}}

kustolovic a écrit :

Je ne suis pas fan de twig. Mais twig se vend en «enlevant les balises php». J'ai toujours trouvé ça un non-sens comme raisonnement.

J'y vois un énorme intérêt en terme d'échange de templates entre les languages. Je vais faire une version JS, qui permettra de n'avoir aucune duplication de code entre serveur et client.
J'ai toujours trouvé ça fastidieux d'avoir à écrire les balises PHP dans le HTML, même si c'était son objectif principal. C'est un des inconvénients les plus soulignés de PHP.

kustolovic a écrit :

Je n'ai jamais vu de site faire de «passage vers une nouvelle version du HTML». Par contre, la plupart au bout de 4 à 6 ans refont au minimum le visuel du site, et refont tous les templates / CSS.

Bien, ce n'était qu'un exemple d'utilisation des layers parmi d'autres. Il y a la possibilité de customiser ces layers.
Ils permettent aussi de produire du code valide W3C sans se poser de questions, en ne traitant que des tags existants dans les layers. En gros, ce sont comme des lexiques de HTML.

Laegel a écrit :

Je trouve cette syntaxe plus perturbante qu'autre chose.

On s'habitue très bien, surtout avec une coloration syntaxique.

Par contre je trouve ceci très difficile à la lecture :

div sktext(true)

Sinon voici une syntaxe que j'ai adapté pour faire supporter le php à Jade (exemple de template) : lien
Pour ce faire je passe par une surcouche de regex en javascript qui parse le code à la suite de Jade.
Modifié par Olivier C (24 Aug 2016 - 12:40)

Olivier C a écrit :

On s'habitue très bien, surtout avec une coloration syntaxique.

En effet, j'aimerais d'ailleurs créer la coloration pour Skin. Enfin, si ça en vaut vraiment la peine.

_if $errorLogin
_php $errorLogin
_endif

Que donne ceci ?

Laegel a écrit :
Que donne ceci ?

Les accolades sont des raccourcis pour insérer les variables php. Les _if et _else (etc) seront remplacés par des conditions php, tout simplement.

Ce dispositif ne recouvre que mes besoins les plus courants, mais m'évite d'avoir recours à des plugins pour Jade plus ou moins bien soutenus (Tale-Jade, JadePHP, Jade4php, etc) et ne me coûte que quelques regex : Gulpfile.js

Exemple d'un fichier source créé pour WordPress (Jade + modification maison de la syntaxe pour php) : single.php.jade
Le pattern layout sur lequel s'appuit le template : PatternLayouts.jade
Résultat de la compilation : single.php
Modifié par Olivier C (24 Aug 2016 - 22:59)

Olivier C a écrit :

Les accolades sont des raccourcis pour insérer les variables php. Les _if et _else (etc) seront remplacés par des conditions php, tout simplement.
Ce dispositif ne recouvre que mes besoins les plus courants, mais m'évite d'avoir recours à des plugins pour Jade plus ou moins bien soutenus (Tale-Jade, JadePHP, Jade4php, etc) et ne me coûte que quelques regex : Gulpfile.js
Exemple d'un fichier source créé pour WordPress (Jade + modification maison de la syntaxe pour php) : single.php.jade
Le pattern layout sur lequel s'appuit le template : PatternLayouts.jade
Résultat de la compilation : single.php

Boudiou... quelle usine à gaz !!!
Soyons clair, je ne conteste ni la compétence ni le savoir faire, mais un tel empilement d'outils et "patches" me laisse quand même dubitatif quant à Jade et consorts.
Toujours curieux de découvrir d'autres méthodes de travail, j'ai jeté un oeil sur les fichiers passés comme exemple et cela m'a bien refroidi quant à l'ensemble.
Pour ceux qui manipulent le bouzin quotidiennement, nul doute que "c'est facile" (le nombre de fois où on a entendu cet argument dans une équipe de dev est incalculable...).
Pas sûr pour autant que la réalité soit aussi simple.
Je note au passage que tu es confronté au problème récurrent des "plugins" : efficaces mais sujets à leur maintenance dans le temps et d'une cohabitation parfois difficile.
En parcourant le code, je me suis demandé quelle était la plus value qu'apportait cette syntaxe par rapport à un "vrai" langage de programmation tel que Java, C# ou autre, puisqu'on retrouve ici la notion de variables, instructions de branchement, imports, etc.
Tout un écosystème qu'il faut appréhender et qui, à mon sens, dépend trop de concepts / frameworks pour certains à pérennité non garantie.
Tout ce que j'ai lu sur le sujet du post et les commentaires tend à démontrer que le Saint-Graal recherché vise à s'affranchir des balises HTML pour simplifier la génération du code.
J'ai bien dit "génération" car ces boîtes à outils entrent bien dans la catégorie des générateurs, prenant quelque chose en entrée et produisant quelque chose en sortie...
Or, dans les bouts de code fournis en exemple, on trouve tout de même des mots clés issus des spécifications HTML, même si ils ont été débarrassés de leurs chevrons (ex. DIV).
Ceci requiert donc l'apprentissage desdites balises et diminue d'autant, selon moi, le gain apporté par ces outils.
À mon sens, des instructions plus agnostiques telles que "newComment("xxx") sont préférables et détachées de l'environnement cible.
Bref, c'est peu dire que je ne suis pas convaincu par Jade et ses dérivés, tout en reconnaissant le travail accompli par les adeptes dudit langage.

sepecat a écrit :
Je note au passage que tu es confronté au problème récurrent des "plugins" : efficaces mais sujets à leur maintenance dans le temps et d'une cohabitation parfois difficile.

Le principe de node.js est d'utiliser des dépendances. C'est donc effectivement un choix philosophique à la base (mais qui n'utilise pas imageMagik et consort via php ou autre langage dynamique ?). Mais pour Jade je n'ajoute que des regex...

sepecat a écrit :
En parcourant le code, je me suis demandé quelle était la plus value qu'apportait cette syntaxe par rapport à un "vrai" langage de programmation tel que Java, C# ou autre, puisqu'on retrouve ici la notion de variables, instructions de branchement, imports, etc.

L'avantage ? Une fois compilées les variables Jade deviennent du code statique, le php (ou autre langage dynamique) restera du php. Le langage soutenant Jade est javascript et ce dernier peut aussi être utilisé pour la compilation.

C'est donc ici qu'il faut faire la part des choses : ce que l'on compilera une bonne fois pour toute, évitant ainsi du travail inutile au serveur, et ce qui doit absolument rester dynamique au chargement d'une page par l'utilisateur.

sepecat a écrit :
Tout un écosystème qu'il faut appréhender et qui, à mon sens, dépend trop de concepts / frameworks pour certains à pérennité non garantie.

Comme tout framework. Un dev' peut s'investir dans un Symfony premier du nom, puis se décourager devant la version 2 (la v.3 pointe son nez...).

sepecat a écrit :
Tout ce que j'ai lu sur le sujet du post et les commentaires tend à démontrer que le Saint-Graal recherché vise à s'affranchir des balises HTML pour simplifier la génération du code.

Ça permet surtout de créer et modifier facilement des sites de plusieurs centaines de pages qui au final peuvent tout aussi bien n'être que statiques, sans recours à une quelquonque bdd.

sepecat a écrit :
Or, dans les bouts de code fournis en exemple, on trouve tout de même des mots clés issus des spécifications HTML, même si ils ont été débarrassés de leurs chevrons (ex. DIV).
Ceci requiert donc l'apprentissage des dites balises et diminue d'autant, selon moi, le gain apporté par ces outils.

Normal, ce sont des outils de templating. Le but n'est pas de faire l'economie de l'apprentissage du html, bien au contraire : ces outils sont justement créés à destination de ceux qui le manipule. Manquerait plus que l'intégrateur ne puisse plus créer ses templates par lui-même !

Notons que si l'on veut pousser l'abstraction jusqu'au bout Jade permet de stocker les contenus en data en les parsant ensuite dans un pattern layout qui, lui, contiendra les tags. À chaque besoin son niveau d'abstraction...

sepecat a écrit :
À mon sens, des instructions plus agnostiques telles que "newComment("xxx") sont préférables et détachées de l'environnement cible.

Donc, au final et là aussi, une nouvelle syntaxe à apprendre...

Il existe une multitude d'outils sur le net. À chacun de choisir en fonction de ses affinitées et des besoins d'un projet.
Modifié par Olivier C (25 Aug 2016 - 09:23)

Olivier C a écrit :

Il existe une multitude d'outils sur le net. À chacun de choisir en fonction de ses affinitées et des besoins d'un projet.

Je suis d'accord. C'est ce qu'il y a de bien avec le fait d'avoir plusieurs logiciels sur le marché : on a le choix. Le choix est un luxe : qui ne s'est jamais retrouvé devant un cas de figure où le choix n'était pas possible ? Dans ce cas on fait quoi, on prend quand même, en traînant des pieds, ou on laisse tomber parce que c'est décourageant ?
J'apporte ici une nouvelle solution, si ça ne plaît à personne tant pis, je continuerai à m'en servir de mon côté. Mais si quelqu'un y trouve son intérêt, alors je serai content que ça lui plaise.

sepecat a écrit :

Or, dans les bouts de code fournis en exemple, on trouve tout de même des mots clés issus des spécifications HTML, même si ils ont été débarrassés de leurs chevrons (ex. DIV).
Ceci requiert donc l'apprentissage des dites balises et diminue d'autant, selon moi, le gain apporté par ces outils.

sur ce point, je rejoins l'avis d'Olivier C :

Olivier C a écrit :

Normal, ce sont des outils de templating. Le but n'est pas de faire l'economie de l'apprentissage du html, bien au contraire : ces outils sont justement créés à destination de ceux qui le manipule. Manquerait plus que l'intégrateur ne puisse plus créer ses templates par lui-même !

Nous sommes obligés de connaître un minimum le HTML pour créer une page web (je dis "un minimum", parce qu'on pourrait très bien la composer exclusivement de div et de span, ça serait dégueulasse mais c'est possible).
Nul n'a jamais prétendu que les moteurs de template aient été créés pour se passer totalement du HTML ; ils ont été créés pour accélérer le workflow, bien que certains prennent du temps pour en acquérir la maîtrise complète.
C'est ce que j'ai cherché à réduire au maximum, éviter d'avoir trop d'éléments nouveaux par rapport à du HTML standard (c'est aussi la raison pour laquelle il est impossible de chaîner les classes dans Skin, on n'écrit l'attribut qu'une seule fois) pour ne pas déstabiliser les habitués.
Le plus compliqué dans le fait de créer du code, c'est pas tellement le rendu final que ça peut avoir, mais la façon dont les autres doivent pouvoir s'en servir par la suite, comme dans l'UX (ici, plutôt du "developer experience").

sepecat a écrit :

Tout ce que j'ai lu sur le sujet du post et les commentaires tend à démontrer que le Saint-Graal recherché vise à s'affranchir des balises HTML pour simplifier la génération du code.

Bien sûr que c'est généré, c'est tout l'intérêt du truc ! Le preprocessing est un moyen génial d'améliorer le quotidien du développeur. On met en cache les fichiers générés pour ne pas consommer de ressources inutilement en recompilant à chaque fois et le résultat final est le même que si tout avait été fait à la main. Le développeur est feignant, c'est aussi ça qui me plaît, dans ce job.

Laegel a écrit :
J'apporte ici une nouvelle solution, si ça ne plaît à personne tant pis, je continuerai à m'en servir de mon côté. Mais si quelqu'un y trouve son intérêt, alors je serai content que ça lui plaise.

Certes...
Ceci dit, pour mémoire :

Laegel a écrit :
Pourquoi le poster ici ? Hé bien tout simplement parce que j'aimerais avoir la possibilité d'avoir des retours sur ce projet, des retours concrets de développeurs qui seraient capables d'émettre des critiques concrètes et intéressantes, ce dont je manque cruellement à cette étape de développement.

Je n'ai donc apporté que des réponses de développeur et mon point de vue factuel sur l'environnement en question, comme demandé de prime abord.

Laegel a écrit :
Bien sûr que c'est généré, c'est tout l'intérêt du truc !

Heu... pas sûr que je découvre ce qu'est un générateur en lisant ce sujet.
@Laegel et @OlivierC
Je (re) précise que je ne mets en doute ni les compétences, ni l'investissement de qui que ce soit dans la mise en oeuvre ou le développement de surcouches / substituts de Jade et consorts.
La question initiale était d'avoir un avis de développeur sur Skin.
J'ai donné mon point de vue technique en retour (Jade / Skin mélangés puisqu'ils sont proches par leur concept).
Bien évidemment, personne n'est contraint de le partager et chacun choisit sa route, en fonction de ses affinités, avec les outils qu'il connait / souhaite apprendre.
Je considère toujours Jade / Skin comme trop hétérogènes par rapport à mes besoins, mais je ne suis en aucun cas un évangéliste dispensant la bonne parole auprès de ses ouailles.
Pour tout dire, en ce moment, je développe sous VBA / Excel au boulot et je gratifie l'éditeur intégré de tous les noms d'oiseaux, tellement il est primaire, mal adapté, foireux, rustique... pourtant je l'utilise, parce que la demande est celle-ci.
A titre personnel, VBA ne passerait pas le pas de ma porte, mais en milieu professionnel l'analyste / développeur s'adapte, et puis basta.
Ceci n'a pour autant jamais été contradictoire avec le fait d'avoir un avis sur un logiciel ou une boîte à outils... ou alors il faudrait fermer d'urgence de nombreux blogs

Laegel a écrit :
J'apporte ici une nouvelle solution, si ça ne plaît à personne tant pis

Mode passage éclair : Ne concluez pas trop vite, nous sommes nombreux à suivre ce sujet avec intérêt, mais à ne pas y participer pour diverses raisons (manque de compétences, vacances, travail, participants au sujet suffisamment pointus...)

sepecat a écrit :

Je n'ai donc apporté que des réponses de développeur et mon point de vue factuel sur l'environnement en question, comme demandé de prime abord.

Et je vous en remercie. Cependant, il y a plus de critiques sur Jade que sur Skin. Alors bien sûr, ils ont deux gros points communs mais tout l'intérêt de Skin ne réside pas exclusivement là-dedans.
Toutes les parties sur les boucles, les conditions, les attributs et l'affichage des variables sont différentes.

sepecat a écrit :

A titre personnel, VBA ne passerait pas le pas de ma porte, mais en milieu professionnel l'analyste / développeur s'adapte, et puis basta.

Et je suis d'accord. Mais quitte à devoir s'adapter, autant le faire avec des logiciels bien conçus, faciles d'utilisation plutôt que de devoir apprendre des tas de nouveaux trucs et découvrir deux semaines plus tard que la mise à jour du-dit logiciel nécessite de changer une bonne partie des connaissances qu'on avait déjà dessus, non ? Et pour cela, il faut qu'il y ait plus de choix parmi les outils.

Manhattan a écrit :

Mode passage éclair : Ne concluez pas trop vite, nous sommes nombreux à suivre ce sujet avec intérêt, mais à ne pas y participer pour diverses raisons (manque de compétences, vacances, travail, participants au sujet suffisamment pointus...)

Merci à vous Manhattan, ce n'était pas un constat mais plutôt ce que je pense.
Je n'ai pas développé ceci dans l'espoir d'en faire le prochain moteur de template à la mode, c'était à l'origine pour m'améliorer en PHP et me créer un outil sympa (parce qu'écrire du HTML, c'est un peu barbant, 'faut dire ce qu'il en est).
C'est la première fois que je soumets un projet personnel à la critique publique et que je me mêle activement à une communauté de développeurs, j'ai ressenti le besoin de m'exprimer et d'échanger sur un sujet qui me passionne !

Laegel a écrit :
Je n'ai pas développé ceci dans l'espoir d'en faire le prochain moteur de template à la mode, c'était à l'origine pour m'améliorer en PHP et me créer un outil sympa

J'ai été dur, mais en jugeant le résultat comme un produit à insérer dans un workflow pro. Sinon je ne doute pas que le travail est intéressant en terme de progression personnelle, et le résultat est très aboutit pour un projet de ce genre

sepecat a écrit :

Pour ceux qui manipulent le bouzin quotidiennement, nul doute que "c'est facile" (le nombre de fois où on a entendu cet argument dans une équipe de dev est incalculable...).
Pas sûr pour autant que la réalité soit aussi simple.

En effet. C'est aussi un argument souvent mis en avant par les moteurs de templates, mais c'est généralement un leurre.

Un moteur de template est nécessaire pour faire du web, nul ne le conteste. Par contre, en php, utiliser un moteur de template dans un moteur de template le premier écrit avec le second peut paraître peu utile. Ceux-ci n'améliorent pas la lecture du code, ni les performances, et ne rend pas «plus facile» (hormis dans quelques contextes particuliers). Cela augmente la maintenance et la complexité de l'application. Au final, on se retrouve toujours à une limite du moteur ou son apparente simplicité devient un obstacle qui augmente la complexité.

L'avantage principal, est de sandboxer le php. Pour d'une part forcer à faire des templates propres, et qui empêche d'accéder à certaines couches du logiciel. Le but est bien entendu de limiter les possibilités du php, ce qui n'est un aucun cas une facilité ou une aide. L'avantage est dans la répartition du travail et des ressources humaines dans du travail en équipe. Si les fameux frameworks raffolent de ce genre de technologies c'est qu'ils sont principalement développés par et pour des grandes équipes de développement.

kustolovic a écrit :
L'avantage principal, est de sandboxer le php. Pour d'une part forcer à faire des templates propres, et qui empêche d'accéder à certaines couches du logiciel. Le but est bien entendu de limiter les possibilités du php, ce qui n'est un aucun cas une facilité ou une aide.

Intéressant...
N'étant pas un pro PHP, pourrais-tu me préciser l'aspect "limiter les possibilités du PHP". Ce point est en effet un poil obscur pour moi.
Merci d'avance.
Modifié par sepecat (27 Aug 2016 - 09:05)