Accueil > Réalisations > Projets Libres > Un framework HTML est-il possible ?

Un framework HTML est-il possible ?

Je suis intervenu lors de la session 2010 de Paris-Web pour présenter une proposition de framework HTML.

Sous un titre un brin intriguant, j’ai présenté quelques propositions autour de l’industrialisation de la production des gabarits HTML sur les projets Web.

Ces propositions prennent la forme d’un Framework, qui s’inspire des travaux réalisés autour du projet Zpip. Il en reprend les solutions aux problèmes génériques indépendants du socle technique.

De ce projet fondateur, il a tiré son nom de « Framework Z », que vous pouvez retrouver sur GitHub

En attendant que je revienne plus en détail sur le sujet ici, la présentation est téléchargeable ci-dessous au format PDF.

J’attends vivement vos retours pour continuer la discussion amorcée par la présentation et faire progresser ce sujet qui me tient à cœur.

Documents joints

Vos commentaires

  • Le 15 octobre 2010 à 23:22, par Jacques Pyrat En réponse à : Un framework HTML est-il possible ?

    Il y a un point qui me manque dans ce qui a été présenté. D’après-moi, une caractéristique que doivent avoir des composants modulaires, c’est de pouvoir « communiquer » entre eux de manière à en modifier le comportement. Autrement dit : se passer des variables.

    Exemple type : j’ai 2 pages : une page d’article, et une page de plan. Pour ces 2 pages, je veux bien sûr un <title>Titre de page</title> différent.
    Le plus simple est depuis le content.php de chacune des page passer dans l’environnement une variable donnant la valeur de ce titre.

    Le fait avec Z de devoir dupliquer des fichiers de template pour reprendre le nom du template principal et mettre la variante spécifique à chaque type de page me semble être à l’opposé de la volonté d’avoir des « blocs » réutilisables.

    Mais peut-être suis-je passé à côté d’un élément qui résout cette question élégamment.

  • Le 16 octobre 2010 à 22:05, par Cedric En réponse à : Un framework HTML est-il possible ?

    Vouloir passer une variable directement d’un bloc à un autre est non pertinent d’un point de vue architectural.

    Comme si, dans un langage, tu voulais directement faire passer une variable d’une fonction A vers une fonction B. C’est une fausse bonne idée qui va exactement au contraire de la modularité et de la réutilisabilité, car cela créé une dépendance entre les deux fonctions.

    A contrario, dans le cas que tu souhaites résoudre, une information peut venir du contexte général et être partagée par A et B (content et meta dans ton cas). Ou le résultat de A peut être fourni à B. Ce sont deux schémas qui fonctionnent sans créer de dépendance.

  • Le 17 octobre 2010 à 13:52, par Loiseau2nuit En réponse à : Un framework HTML est-il possible ?

    Excellent résumé et PDF très concis, bravo !

    Je regrette sincèrement de n’avoir pu voir la prez’ en live mais je ne doute pas une seconde que ça a du très bien se passer :-)

  • Le 18 octobre 2010 à 11:19, par Cedric En réponse à : Un framework HTML est-il possible ?

    Je viens de regarder un peu http://jquerymobile.com/ qui est sorti en version alpha pendant Paris-Web. C’est très intéressant de voir comment cela s’emboite parfaitement avec l’approche du framework Z présentée ici.

    Il suffit de faire des pages en 3 blocs header, content, footer, d’écrire une fois pour toute la structure de la page, le header/dist, le footer/dist, et il n’y a plus ensuite qu’à enchainer les gabarits de content/.

    Tout cela permettant d’avoir des pages complètes, chargées en ajax sur le mobile, avec des urls permanentes fonctionnelles, et en se concentrant uniquement sur le contenu.

    Je crois que je vais très vite refaire la version mobile de http://www.cuisine-libre.fr/ sur cette base !

  • Le 23 octobre 2010 à 14:46, par Ben S. En réponse à : Un framework HTML est-il possible ?

    Tout d’abord, merci pour cette conférence donnée à Parisweb, synthétique et très claire. Et puis je trouve la démarche et la logique du framework Z très intéressante, inspirante.

    Cela dit je suis un peu dans la même situation que Jacques.
    Je comprends qu’à une nouvelle page page1.php créée dans le dossier content/, il faille créer également page1.php dans le dossier head/.
    En revanche, les appels aux js et aux feuilles de style sont bien souvent très similaires d’une page à l’autre. Or, ils sont actuellement placés dans les fichiers du répertoire head/. Donc si je veux par exemple appeler la librairie jquery, je suis obligé de recopier l’appel à la librairie dans tous les fichiers du répertoire.

    Comment t’y prends-tu dans ce cas ? J’aimerais connaître ta position sur ce problème : ferais-tu un répertoire includes/ dans chaque dossier head/, content/, footer/ etc... dans lesquels on placerait les portions de code communes aux fichiers des répertoires correspondants ?
    Ferais-tu un dossier style/ et js/ au même niveau que les dossiers content, head... (mais le problème se posera probablement pour d’autrs types de codes que des js et du CSS...) ?

  • Le 23 octobre 2010 à 15:16, par Cedric En réponse à : Un framework HTML est-il possible ?

    @Ben S. Merci beaucoup pour ton retour. J’ai eu du mal à trouver le compromis entre synthèse et détail pour ma présentation, cela me fait donc plaisir de savoir que j’y suis parvenu au moins pour quelques auditeurs :)

    Ta question est très bonne, car le <head> pose en effet plusieurs problèmes. Je n’ai volontairement pas fait de choix ni préconisé quoi que ce soit dans le framework Z que j’essaye de garder aussi général que possible pour pouvoir s’appliquer à toutes les situations.

    Néanmoins, je peux te faire un retour d’expérience de ce que je pratique avec, en production, autour de SPIP notamment.

    En ce qui concerne les briques communes qu’on peut réutiliser d’une page à l’autre, comme la partie invariante du <head>, j’ai effectivement opté pour un répertoire inclure/ (include/ pour garder une terminologie anglo-saxonne) unique, commun à tous les blocs.

    Pour le <head>, il y a en plus une partie variante qui concerne le <title>, qui doit arriver en debut de <head> pour des problèmes de référencement, et une partie qui peut varier aussi pour des scripts supplémentaires sur certaines pages.

    La meilleure synthèse que j’ai trouvée est donc d’avoir un bloc head/, suivi d’une inclusion commune include/head, suivi enfin d’un bloc head_js/. Dans la version SPIP du framework, que je suis en train remettre à niveau, cela donne ça : http://zone.spip.org/trac/spip-zone/browser/_plugins_/z-core/structure.html

    Si tu penses que ça a un intérêt pédagogique, on peut aussi modifier l’exemple de http://github.com/Cerdic/Z/tree/master/php/demo/ car il est vrai que cela touche aussi le fichier page.php

  • Le 23 octobre 2010 à 15:34, par Ben S. En réponse à : Un framework HTML est-il possible ?

    Je crois que je viens de comprendre : je n’avais pas encore regardé le code du framework, mais les commentaires du constructeur semblent répondre à ma question :
    Il faut, dans mon body, que je créé une instance de la classe Z avec pour paramètre block quelque chose comme array(’content’,’header’,’nav’,’style’,’js’,’footer’,’head’) ;

    je peux ensuite créer un répertoire style/ et js/ au même niveau que content/, head/... avec dans ces nouveaux répertoires un fichier dist.php qui sera utilisé par défaut.

    C’est bien cela ?

  • Le 23 octobre 2010 à 15:36, par Cedric En réponse à : Un framework HTML est-il possible ?

    Oui tout à fait, c’est aussi une possibilité qui fonctionne très bien !

  • Le 24 octobre 2010 à 00:08, par Ben S. En réponse à : Un framework HTML est-il possible ?

    Merci pour ton retour d’expérience, Cédric.
    Je pense effectivement que ce serait pertinent d’inclure dans l’exemple php cette notion de parties communes/spécifiques du head, car c’est une chose à laquelle on est très vite confronté quand on créé un projet.

    En y réfléchissant bien il me semble que le mieux serait de faire un mixte : utiliser un répertoire style/ et js/ pour conserver une organisation rigoureuse des fichiers, « dans l’esprit » du framework, tout en utilisant un « include » dans les fichiers du head/ permettant de ne pas avoir à dupliquer du code inutilement.

    Reste à savoir où placer le répertoire include/...
    Par instinct, je pense qu’il vaut mieux créer un répertoire include dans chaque répertoire de bloc (header/, content/, footer/...), ainsi, chaque répertoire include contiendra des fichiers de même « nature » (tous les js dans le dossier js/include/, tous les css communs dans style/include/...)

    En tout cas, je me répète, je trouve cette organisation d’une logique et d’une limpidité étonnante : j’espère pouvoir la mettre en pratique rapidement.

  • Le 25 octobre 2010 à 14:56, par Ben S. En réponse à : Un framework HTML est-il possible ?

    Maintenant qu’il est simple de créer des pages (pour un webmaster), avec ce framework, l’étape suivante concerne le backoffice.
    En effet, je compte réaliser un petit site vitrine très simple. Les pages n’ont pas vraiment besoin d’être toutes être administrables (ex. Présentation de la société, Nos Valeurs...), mais si elles peuvent l’être, tant mieux ;)

    Je me dis, qu’avec cette séparation du contenu, il devient très simple de réaliser un template d’admin (body-admin.php ?) qui prend en paramètre le nom de la page à éditer (comme le fait l’index.php). Ce template d’admin peut se contenter dans un premier temps de proposer 2 champs :
    - Titre de la page :
    Créera ou modifiera le fichier correspondant dans le dossier head/) afin d’adapter la balise <title> de la page.
    - Contenu :
    Propose un éditeur riche de type TinyMCE pour la saisie du contenu de la page.

    Avec ce squelette de page d’admin (et un menu présentant la liste des pages éditables), on pourrait proposer une plateforme d’édition de contenus Wysiwyg très simple et très rapide à mettre en place...

    Qu’en penses-tu, Cédric ?

  • Le 8 décembre 2010 à 06:47, par Eric En réponse à : Un framework HTML est-il possible ?

    Ca fait un moment que je zyeute zpip pour ces raisons. Mais à la longue,
    je pense à une approche différente : pourquoi pas du XML + XSLT

    On a un fichier
    - module.xml qui liste tout les modules disponibles
    - pages.xml qui déclare toutes les pages du site et les modules qui la composent
    - Une feuille de style XSLT qui génère le HTML correspondant

    Dès que j’ai un temps je me lance. Ca paraît usine à gaz mais sur des gros devs type portail/presse en ligne je pense que c’est rentable

  • Le 13 janvier 2011 à 01:11, par Kaelig En réponse à : Un framework HTML est-il possible ?

    Après avoir trouvé l’approche de Z très intéressantes, je suis tombé sur staticmatic qui permet une intégration très rapide (notamment grâce à haml et scss). Maintenant j’ai du mal à faire machine arrière car c’est vraiment très pratique (mais bien évidemment on s’éloigne du php).

  • Le 14 janvier 2011 à 10:06, par jpvincent En réponse à : Un framework HTML est-il possible ?

    j’avais implémenté la même idée à une époque où ce genre de framework n’existait pas, du coup j’ai fait des choix très différents, qui peuvent peut être t’inspirer ? :
    - chaque module est une classe héritant de la même classe, et généralement divisée en 2 méthodes, l’une qui calcule les données , l’autre qui prend les données et va générer du HTML (à partir de templates)
    - comme toi, chaque module est appellable dans un layout générique ou en standalone pour l’AJAX.
    - en plus, pour chaque module on peut appeller uniquement la partie data, formatable en JSON ou XML, ce qui crée une API à pas cher, utilisable en interne ou par des tiers
    - il y a des scripts PHP libres (non mis dans des classes) qui représentent les pages et qui exécute les modules pour les placer dans le layout
    - le routage vers les pages ou les modules n’est pas automatique, c’est un fichier d’expressions régulières qui correspond chacune à une page ou un module. Ca permet d’être libre dans le format de ses urls

    ce que je regrette de ne pas avoir fait : je n’ai pas formalisé les dépendances JS et CSS de chaque module, ce qui est dommage car lorsque le site grossit, ça permettrait aux pages de n’envoyer que les bonnes dépendances

    dernière chose : le titre de ta présentation laissait penser qu’on pouvait faire quelque chose pour éviter les gros copier/coller de HTML entre chaque projet, mais comme moi c’est une question d’organisation du code plutôt que de framework

  • Le 14 janvier 2011 à 11:11, par Kaelig En réponse à : Un framework HTML est-il possible ?

    Et hop un petit lien vers la vidéo de la conf : http://dai.ly/fEbA0E

  • Le 5 février 2011 à 00:55, par rivsc En réponse à : Un framework HTML est-il possible ?

    Je viens de regarder la conf, super intéressant et bien présenté ! Je partage un peu l’avis du développeur qui a parlé de rails.

    Effectivement on a cette notion de vues et de controlleurs mais chaque vue est une page (le content particulier qui fait qu’il y a lieu d’avoir une page) pour le reste (les portlets, les zones ou boites html que l’on retrouve sur plusieurs pages) il existe dans le framework les partials ce sont des morceaux de vues qui peuvent être inclue dans n’importe quelle page.

    La gestion des layouts existe aussi. La seul chose qui diffère vraiment c’est la structure des répertoires et des partials qui n’est pas normalisée par rails. Le fait aussi que ce soit le framework serveur qui gère tout ça va effectivement à l’encontre d’un framework html. Sinon petite suggestion pour être langage serveur agnostique : mettre une balise commentaire html normalisée qui fait l’inclusion :

    Il suffira alors de passer le répertoire parent pour « compiler » chaque page dans le cas de la soutraitance de l’intégration et d’adapter dans chaque langage serveur « l’inclusion html » en « inclusion serveur ».

  • Le 7 février 2011 à 09:31, par Kaelig En réponse à : Un framework HTML est-il possible ?

    Je viens de tomber là dessus :

    http://nanoc.stoneship.org/docs/3-getting-started/

    Ce n’est pas un « framework html », mais quelque chose qui facilite l’intégration de sites statiques.

    À tester, donc.

  • Le 11 octobre 2014 à 19:29, par jawi En réponse à : Un framework HTML est-il possible ?

    je trove que c’est compliqué de trouver une documentation assez complète pour zcore and spipr. J’essaye de comprendre comment ajouter des nouveaux blocs aux pages article, rubrique, etc....en principe j’ajoute un dossier avec le nouveau bloc dans la racine de spipr, avec un fichiers dist.html, j’ajoute aussi dans spipr_dist_options.php le nouveau bloc et j’ajoute un div avec l’insertion du nouveau bloc dans le body.html, article.html, etc... mais ça ne marche pas pour l’instant, j’aimerai trouver une doc detaillé....pour l’instant je bodouille tout ce que je peux mais je n’arrive pas. Néanmoins je vous felicite, parce que le système est phénomenal le seul petit blem, la doc compliqué à trouver. Sinon bon travail, vous êtes vraiment très fort en développement web.Merci pour votre travail

  • Le 19 juin 2015 à 11:13, par Peetdu En réponse à : Un framework HTML est-il possible ?

    En l’état zcore place la meta Charset APRÈS les méta Title et Description.

    D’après cette doc (https://code.google.com/p/doctype-mirror/wiki/MetaCharsetAttribute) il le faudrait avant.

    Il faut alors supprimer la déclaration dans le fichier /inclure/head.html et la replacer dans /header/dist.html.

    cheers

  • Le 19 août 2015 à 17:39, par Valéry En réponse à : Un framework HTML est-il possible ?

    Le lien de documentation du plugin renvoyant ici je signale un article pour se lancer avec SPIP et Z-Core sur SPIP-Contrib : http://contrib.spip.net/Creer-des-squelettes-avec-Zcore

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom