Un framework HTML est-il possible ? - commentaires

Un framework HTML est-il possible ?

Bonjour,
zcore/structure.html génère des contenus mixtes http / https
avec les URL :
http://www.w3.org/1999/xhtml

à remplacer par
https://www.w3.org/1999/xhtml

ou simplement par
//www.w3.org/1999/xhtml

Cordialement

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

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

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

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.

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 ».

Un framework HTML est-il possible ?

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

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

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).

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

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 </code> de la page. <br><span class="spip-puce ltr"><b>–</b></span> Contenu :<br class="autobr"> Propose un éditeur riche de type TinyMCE pour la saisie du contenu de la page.</p> <p>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...</p> <p>Qu'en penses-tu, Cédric<small class="fine d-inline"> </small>?</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>Merci pour ton retour d'expérience, Cédric.<br class="autobr"> 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.</p> <p>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, «<small class="fine d-inline"> </small>dans l'esprit<small class="fine d-inline"> </small>» du framework, tout en utilisant un «<small class="fine d-inline"> </small>include<small class="fine d-inline"> </small>» dans les fichiers du head/ permettant de ne pas avoir à dupliquer du code inutilement.</p> <p>Reste à savoir où placer le répertoire include/... <br class="autobr"> 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 «<small class="fine d-inline"> </small>nature<small class="fine d-inline"> </small>» (tous les js dans le dossier js/include/, tous les css communs dans style/include/...)</p> <p>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.</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>Oui tout à fait, c'est aussi une possibilité qui fonctionne très bien<small class="fine d-inline"> </small>!</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>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 :<br class="autobr"> 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')<small class="fine d-inline"> </small>;</p> <p>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.</p> <p>C'est bien cela<small class="fine d-inline"> </small>?</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>@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 :)</p> <p>Ta question est très bonne, car le <code class="spip_code spip_code_inline" dir="ltr"><head></code> 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.</p> <p>Néanmoins, je peux te faire un retour d'expérience de ce que je pratique avec, en production, autour de <span class="caps">SPIP</span> notamment.</p> <p>En ce qui concerne les briques communes qu'on peut réutiliser d'une page à l'autre, comme la partie invariante du <code class="spip_code spip_code_inline" dir="ltr"><head></code>, j'ai effectivement opté pour un répertoire <code class="spip_code spip_code_inline" dir="ltr">inclure/</code> (<code class="spip_code spip_code_inline" dir="ltr">include/</code> pour garder une terminologie anglo-saxonne) unique, commun à tous les blocs.</p> <p>Pour le <code class="spip_code spip_code_inline" dir="ltr"><head></code>, il y a en plus une partie variante qui concerne le <code class="spip_code spip_code_inline" dir="ltr"><title></code>, qui doit arriver en debut de <code class="spip_code spip_code_inline" dir="ltr"><head></code> pour des problèmes de référencement, et une partie qui peut varier aussi pour des scripts supplémentaires sur certaines pages.</p> <p>La meilleure synthèse que j'ai trouvée est donc d'avoir un bloc <code class="spip_code spip_code_inline" dir="ltr">head/</code>, suivi d'une inclusion commune <code class="spip_code spip_code_inline" dir="ltr">include/head</code>, suivi enfin d'un bloc <code class="spip_code spip_code_inline" dir="ltr">head_js/</code>. Dans la version <span class="caps">SPIP</span> du framework, que je suis en train remettre à niveau, cela donne ça : <a href="http://zone.spip.org/trac/spip-zone/browser/_plugins_/z-core/structure.html" class="spip_url spip_out auto" rel="nofollow external">http://zone.spip.org/trac/spip-zone/browser/_plugins_/z-core/structure.html</a></p> <p>Si tu penses que ça a un intérêt pédagogique, on peut aussi modifier l'exemple de <a href="http://github.com/Cerdic/Z/tree/master/php/demo/" class="spip_url spip_out auto" rel="nofollow external">http://github.com/Cerdic/Z/tree/master/php/demo/</a> car il est vrai que cela touche aussi le fichier <code class="spip_code spip_code_inline" dir="ltr">page.php</code></p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>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.</p> <p>Cela dit je suis un peu dans la même situation que Jacques.<br class="autobr"> 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/. <br class="autobr"> 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.</p> <p>Comment t'y prends-tu dans ce cas<small class="fine d-inline"> </small>? 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<small class="fine d-inline"> </small>?<br class="autobr"> 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 <span class="caps">CSS</span>...)<small class="fine d-inline"> </small>?</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>Je viens de regarder un peu <a href="http://jquerymobile.com/" class="spip_url spip_out auto" rel="nofollow external">http://jquerymobile.com/</a> 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.</p> <p>Il suffit de faire des pages en 3 blocs <code class="spip_code spip_code_inline" dir="ltr">header, content, footer</code>, d'écrire une fois pour toute la structure de la page, le <code class="spip_code spip_code_inline" dir="ltr">header/dist</code>, le <code class="spip_code spip_code_inline" dir="ltr">footer/dist</code>, et il n'y a plus ensuite qu'à enchainer les gabarits de <code class="spip_code spip_code_inline" dir="ltr">content/</code>.</p> <p>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.</p> <p>Je crois que je vais très vite refaire la version mobile de <a href="http://www.cuisine-libre.fr/" class="spip_url spip_out auto" rel="nofollow external">http://www.cuisine-libre.fr/</a> sur cette base<small class="fine d-inline"> </small>!</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>Excellent résumé et <span class="caps">PDF</span> très concis, bravo<small class="fine d-inline"> </small>!</p> <p>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 :-)</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>Vouloir passer une variable directement d'un bloc à un autre est non pertinent d'un point de vue architectural.</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Un framework <span class="caps">HTML</span> est-il possible<small class="fine d-inline"> </small>?</h1> <p>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 «<small class="fine d-inline"> </small>communiquer<small class="fine d-inline"> </small>» entre eux de manière à en modifier le comportement. Autrement dit : se passer des variables.</p> <p>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 <code class="spip_code spip_code_inline" dir="ltr"><title>Titre de page 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.