Sommaire
- Présentation
- Installation
- Mise à jour
- Usage
- Objets ruby
- Et donc, comment que ça marche en pratique ?
- Getting started
- Mot de la fin
- Il ne manquerait pas un truc ?
Après la superbe trilogie « écrire une page web de nos jours », voici enfin la suite tant attendue.
Pour rappel :
- Ecrire une page web de nos jours et la suite des aventures
- Ecrire une page web de nos jours, troisième partie
Mais quelle suite pouvait-on donner alors ? Avec ces trois épisodes nous avons touché du bout des doigts la création d'une page web aujourd'hui. Bon, on en est resté au strict minimum avec haml, git, markdown, ruby, gem, guard, rake, sass, coffeescript, bundler, redcarpet, gollum, etc. Evidement pas question d'en rester là !
Voici un petit résumé tout de même :
- le html c'est surfait
- le css c'est tellement 2012
- ruby c'est indispensable
- gem say bien
- markdown ça enlarge ta capacité à écrire
- javascript c'est pour les boutonneux, coffeescript c'est pour les vrais
Pfiou, on en avait vu des choses tout de même !
L'ensemble était orienté "simple page web". Mais les simples pages, say trop nul, il en faut deux ! (ou plus…) Et c'est ainsi qu'est né Web Log Today ! Voyons donc désormais comment écrire un blog de nos jours !
Présentation
Web Log Today (wlt
) est né d'un besoin très simple : remplacer mon vieux blog dotclear par un ensemble beaucoup plus sympa :
- site / blog statique (pas besoin d'un langage côté serveur)
- markdown comme langage principal de contenu
- génération simple de flux atom, sitemap, etc
- gestion (bien qu'un peu sommaire pour le moment) de tags
- gestion de billets mais aussi de pages statiques
- utilisation de templates pour ne pas se répéter tout le temps
- que des technos cool (mais pour le coup elles sont presque toutes dans la version "écrire une page web de nos jours")
Au final, ça donne quelque chose dans le même genre que jekyll avec quelques différences :
- haml est utilisé aussi bien comme langage de template que comme générateur de html
- sass est utilisé par défaut pour les css
- coffeescript est utilisé par défaut pour le javascript
- uniquement markdown est supporté côté contenu, et on ne peux pas utiliser de template dans les contenus
Sinon c'est un peu le même principe, il y a pas mal de ressemblances entre autre sur les headers des fichiers (pour indiquer le layout à utiliser, le titre, les tags, etc).
Installation
La majeur partie de Web Log Today est la commande wlt
. Cette commande est basée sur sub et ça c'est juste très pratiques. Pour la suite, je pars du principe que vous allez l'installer dans ~/.wlt
.
Dépendances
Récupération des sources
git clone https://github.com/CrEv/wlt.git ~/.wlt cd ~/.wlt
Récupération des dépendances
bundle
Mise à disposition
Pour bash :
echo 'eval "$(<wltpath>/bin/wlt init -)"' >> ~/.bash_profile exec bash
Pour zsh :
echo 'eval "$(<wltpath>/bin/wlt init -)"' >> ~/.zshenv source ~/.zshenv
Et voilà, wlt
est dispo !
Mise à jour
Evidemment, c'est juste trop facile !
cd ~/.wlt && git pull && bundle
Un petit apparté sur le côté git : le but est de garder la branche master
toujours installable. Il devrait donc être possible en permanence de faire un pull
depuis le master sans craindre le moindre problème. Les développements futurs seront +
Usage
Le principe global est plutôt simple. wlt
va lire des informations dans des dossiers spécifiques, va les compiler en css, js et html afin d'en générer un site statique. De manière globale le principe est :
convention over configuration
La majorité des choses repose donc sur certaines conventions, en premier lieu les fichiers et répertoires.
_site
Ce répertoire contient l'ensemble des fichiers générés. Il s'agit réellement de votre site web, il suffit de le copier sur votre serveur pour le rendre disponible.
_posts
Le répertoire _posts
contient logiquement les billets de votre blog. Il s'agit de fichiers markdown dont le titre a la structure suivante :
yyy-mm-dd-title-of-the-blog-post.md
yyyy
: année de publicationmm
: mois de publicationdd
: jour de publicationtitle-of-the-blog-post
: nom du fichier, en général le titre du billet sans accent ni espace ni caractère spéciaux
Le fichier html généré sera :
yyyy/mm/dd/title-of-the-blog-post.html
_pages
Vous pouvez définir des fichiers statiques qui ne sont pas des billets de blog. Ces fichiers se trouvent dans le répertoire _pages
et sont des fichiers markdown. Le nom du fichier markdown sera le nom du fichier html généré. Par exemple index.md
deviendra index.html
.
Certaines fichiers un peu plus spéciaux peuvent être présents, voir la partie spécifique.
_css
Contient l'ensemble des fichiers sass destinés à être compilés en css. Les fichiers "racines" sont spécifiés dans la configuration (voir plus loin). Le fichier généré est le nom du fichier sass avec l'extension css. Par exemple application.sass
donnera application.css
Vous pouvez utiliser toutes les fonctionnalités de sass, entre autre les @import
vous permettant de factoriser vos css.
Si vous avez des fichiers css
à inclure, et donc ne nécessitant pas une compilation, se référer à la partie publique.
Note : il est bien sur possible d'avoir plusieurs fichiers css de sortie.
_js
Contient l'ensemble des fichiers coffeescript destinés à être compilés en javascript. Les fichiers à compilés sont à spécifier dans la configuration.
Le fichier généré est le nom du fichier coffeescript avec l'extension js. Par exemple application.coffee
donnera application.js
.
Pour le moment il n'y a pas de mécanismes permettant de concaténer plusieurs fichiers coffeescript en un. Dans un premier temps ce n'est pas réellement nécessaire car le but était de faire un site/blog simple et non une application web. Néanmoins un système type sprockets pourra être envisagé par la suite.
Si vous avez des fichiers js
à inclure, et donc ne nécessitant pas une compilation, se référer à la partie publique.
Note : il est bien sur possible d'avoir plusieurs fichiers javascript de sortie.
_layouts
Contient l'ensemble des fichiers haml de templates. Il peut s'agir aussi bien de fichiers "racines" fournissant l'html de base que de fichiers partiels (à charger avec render :partial => "..."
) ou des fichiers "intermédiaires".
Les contenus (pages, posts) déclarent dans leur entête le template à utiliser. Un template peut également faire appel à un template parent. Ceci permet par exemple d'avoir un premier template correspondant à tout ce qui tourne autour du contenu généré par le markdown, et un autre dédié à la page en elle-même. Pour plus d'explications, je vous suggère juste d'aller voir les exemples.
_pub
Ce répertoire est probablement le plus simple. Tout ce qui est contenu dedans sera copié à la racine du site. Il permet donc d'inclure des fichiers css, des javascript, des images, des ressources diverses, des fichiers html générés par d'autres moyens, etc.
config.yaml
Le fichier config.yaml
contient les paramètres nécessaire à la génération du site. Il s'agit de paramètres "systèmes" (par exemple l'url, le chemin de déploiement) ou simplement des paramètres destinés à être factorisés (comptes, infos twitter, etc).
Voici un exemple de fichier, commenté :
# URL du site généré (les liens sont tous absolus)
site_url: http://log.winsos.net
# URL de déploiement, via rsync
deploy_to: ...@www.....lan:/var/www/log/
# Titre des pages
title: CrEv's log
# Informations twitter cards, opengraph, etc
# Nom de l'auteur
name: Plop Plop
# Twitter site / creator -> twitter cards
twitter_site: _crev_
twitter_creator: _crev_
# Description par défaut si non fournie
default_description: My personal weblog
# Divers comptes, permettant d'être affichés dans une page about dans les templates par défaut
accounts:
twitter: https://twitter.com/_crev_
gplus: https://plus.google.com/112813954986166280487
github: http://github.com/CrEv
coderwall: https://coderwall.com/crev
linkedin: http://fr.linkedin.com/in/yvesbrissaud
# Assets, description des css/js à générer (nom des fichiers sans extension)
assets:
css: [application, cv]
js: [application]
A part le premier (site_url
) qui est réellement conseillé, le reste est toujours optionnel et dépend de vos templates. Ceci n'est donc qu'un exemple et vous pouvez en rajouter autant que vous voulez. Ils seront donc accessible de partout via les objets ruby.
Headers
Chaque fichier markdown et haml peut débuter par un entête ajouter quelques méta données. Selon les cas (pages, billet, template) les paramètres ne sont pas forcément tous obligatoire. Voici les paramètres dans le cas d'un billet de blog.
Tout d'abord l'entête doit toujours débuter à la première ligne du fichier, par ---
et termine par une ligne contenant uniquement ---
.
Ce qui est entre ces lignes est du yaml.
Voici donc les données les plus courantes :
layout
: nom du fichier haml qui va recueillir la sortie de markdowntags
: tableau contenant les tags relatif au billettitle
: Titre clair, avec accents et autresauthor
: Nom de l'auteuremail
: email de l'auteur. L'email n'est pas affiché, il est utilisé pour afficher le gravatar correspondanttwitter
: compte twitter de l'auteur. Optionnel, il peut être défini dans la configurationpublished
: sifalse
permet de ne pas généré la sortie. Cela permet de versionner certains contenus avant qu'ils soit publiés
Par exemple :
---
layout: post
tags: [web_log_today]
title: Web Log Today est juillet
author: Yves
email: plopplop@....com
twitter: _crev_
published: false
---
Note : vous pouvez rajouter sans aucun problème des métadonnées propres. Elles seront accessibles via les objets ruby comme détaillé plus bas. Cela peut vous permettre d'améliorer vos templates, votre site, en posant le maximum de données dans les fichiers markdown ce qui permet de rendre la saisie plus agréable.
Fichiers spéciaux
Deux fichiers un peu plus spéciaux peuvent être présent dans le répertoire _pages
et un dans le répertoire _layouts
.
Le premier est simplement le fichier atom.xml.haml
. Comme son nom l'indique il permet de générer un fichier atom.xml
et donc permet d'offrir à vos lecteurs un flux à placer dans un quelconque lecteur. Par défaut il permet de générer un flux basé sur les articles de blogs uniquement.
Le deuxième, un peu dans le même veine, est le fichier sitemap.xml.haml
. Il permet de générer un fichier sitemap.xml
listant l'ensemble des ressources html de votre site.
Enfin le fichier tags.haml
peut être présent dans le répertoire _layouts
afin d'afficher tous les billets d'un tag commun. Contrairement à tous les autres cas, ce fichier aura de multiples sorties, un fichier par tag, présent dans le répertoire tags
.
Objets ruby
Les fichiers haml peuvent accéder à un certain nombre de propriétés et méthodes. L'ensemble n'est pas parfaitement unifié mais cela fonctionne plutôt bien. C'est un point qui sera amélioré par la suite.
Voici les propriétés les plus importantes accessibles dans les fichiers haml :
name
: nom du fichier@contents
: propriétés globales du contenuconfig
: yaml du fichier du configurationlist
: ensemble des postslist_lasts(number)
: ensemble des posts, au plusnumber
list_by_date
: ensemble des posts organisés par année, mois, jouraccount?(name)
: vérifie la présence d'un comptename
dans la configurationaccount(name)
: valeur du comptename
dans la configurationtag
: tag courant, dans le cadre detags.haml
urls
: l'ensemble des urls des billets et pages
link_to(url)
: transforme une url relative en url absolue en utilisant la configurationgravatar?
: teste la présence d'un email pour afficher un gravatargravatar
: url de l'image gravatarpublished?
: présence du paramètrepublished
dans l'entêtepublished
: valeur du paramètrepublished
de l'entête outrue
date
: date, dans le cas d'un billet<...>?
: teste la présence de<...>
dans l'entête<...>
: valeur de<...>
dans l'entête@scope
: En gros idem que tout cela, mais spécifiquement au contenu markdown. Cela permet d'avoir accès aux valeurs de l'entête du contenu ainsi que celles de l'entête du hamlcontent
: contenu html à insérer (généré à partir du markdown ou à partir du haml)
D'autres propriétés existent, mais entre ça et les exemples ça devrait permettre de commencer ;-)
Et donc, comment que ça marche en pratique ?
Quelques petites commandes au niveau de wlt
:
wlt assets
Compilation des css et javascript.
wlt build
Vide le répertoire de sortie et génère l'intégralité des données.
wlt clean
Vide le répertoire de sortie
wlt gollum
Lance gollum afin de visualiser et éditer les fichiers markdown du projet. Attention, seuls les fichiers ajoutés à git sont gérés.
wlt serve
Compile l'ensemble des données en changeant l'url de destination et le rend disponible sur http://localhost:4000
wlt scaffold
Permet de générer une version de base, simple ou déjà relativement complexe, facilitant le démarrage avec wlt
.
Les deux commandes sont wlt scaffold basic
et wlt scaffold full
.
La version basique contient le strict minimum pour bien commencer :
- fichier css de base
- fichier js de base
- une page d'index listant tous les billets
- un template pour les billets
- un header contenant les infos twitter, opengraph, etc
- un atom, un sitemap
- un fichier rake et un fichier guard
La version complète rajoute :
- un css déjà correct (couleurs, mise en page, etc)
- tags, pages
- quelques partiels
Getting started
Pour finir, voici un mini tuto pour prendre en main wlt
.
Créer un répertoire destiné à recevoir vos sources, dans notre cas
mon_supair_blog
mkdir mon_supair_blog cd mon_supair_blog
On échafaude en version basique (pour la version full je vous laisse regarder)
Attention,
wlt scaffold
nécessite un répertoire vide.wlt scaffold basic
Vous vous retrouvez donc avec tout ce qu'il faut pour commencer.
Vous pouvez déjà voir le rendu tout de suite :
wlt serve
Puis rendez-vous sur http://localhost:4000
Et voilà, votre blog est en route !
Créer un dépôt git (utile pour plein de raisons, entre autre pour l'édition)
git init git add . git ci -m "Initial scaffold"
Un peu de configuration
Editez le fichier
config.yaml
. La configuration est plutôt simple et claire.Editez le fichier
_pub/robots.txt
pour changer l'adresse du fichier sitemap.Si vous voulez utiliser le déploiement via rake ajoutez une clé
deploy_to
. Vous pouvez voir l'usage dans le fichierRakefile
.Editez le contenu, ajoutez un post, etc.
Si vous voulez éditer un contenu existant (et versionné dans git) le plus simple est d'utiliser gollum :
wlt gollum
Puis rendez-vous sur http://localhost:4567/pages
Vous pouvez aussi éditer le fichier markdown à la main.
Si vous voulez créer un nouveau post, facile :
touch _posts/2013-01-29-web-log-today-say-cool.md git add _posts/2013-01-29-web-log-today-say-cool.md git ci -m "Add new post" wlt gollum
Ha oui, faites attention à un point : gollum commit dans git lorsque vous enregistrez.
Un peu plus loin ?
wlt serve & guard
Comme ça, vous pouvez éditez vos fichiers, et voir le rendu en même temps sans relancer les commandes à la main.
Publication
Si votre serveur permet de faire du rsync, facile :
rake deploy
Et voilà, c'est dispo !
Alors, trop facile, non ?
Mot de la fin
Et voilà, c'est la fin de la prez. Alors, vous voyez bien que le html c'est surfait !
Comme quoi, on part d'un besoin tout bête, faire une page web tout simple, et on arrive à un générateur de site et blog statique top moumoute à base de ruby, markdown et plein de trucs trop cool.
Ha oui, le tout est sous licence BSD, donc faites vous plaisir.
Il reste pas mal de taff, par exemple améliorer vraiment la partie ruby, enfin les objets utilisés côté haml surtout. Et rajouter des tests aussi, j'aimerais bien le blinder de rspec.
Donc voilà, je ne sais pas comment ce petit soft évoluera, la principal étant qu'il répond à mon propre besoin.
Il ne manquerait pas un truc ?
Ha oui, l'url à laquelle trouver tout cela : https://github.com/CrEv/wlt
# Pour être cool
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Moi j'ai remplacé mon blog dotclear, par Drupal. Ca c'est moderne!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour être cool
Posté par Thom (site web personnel) . Évalué à 1.
C'est pratique mais quand même un poil lourd par moment.
Je connais aussi, je fréquente depuis un certain temps.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# les gens, j'aime les gems
Posté par Dreammm . Évalué à 4.
Mais pourquoi donc ne pas distribuer la chose sous la forme d'une gem ?
Cela permettrait une plus grande facilité d'installation (juste
gem install wlt
) et d'installer la chose dans un endroit standard.Sinon c'est de la belle ouvrage.
[^] # Re: les gens, j'aime les gems
Posté par zebra3 . Évalué à 10.
Où y'a de la gem, y'a pas de plaisir.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: les gens, j'aime les gems
Posté par CrEv (site web personnel) . Évalué à 2.
Hum, je sais plus trop pourquoi mais j'ai préféré ne pas faire une gem. Pour la facilité, je pense que je vais simplement faire un "oneliner".
Et aussi j'avais envie d'utiliser sub (oui je sais c'est pas forcément une superbe raison, mais elle me plait quand même)
Bon après, pourquoi pas une gem un jour…
# usine à gaz
Posté par fravashyo . Évalué à 7.
C'est un peu compliqué je trouve…
Pour moi, 2 fichiers php qui servent de moteur, des fichiers textes en txt2tags qu'on envoit sur le serveur, et ça suffit pour monter un blog :
http://cyoa.hostzi.com/blog/index.php?article=2012-12-07-NewBlog
la source : http://cyoa.hostzi.com/blog/2012-12-07-NewBlog.blog.t2t
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: usineàgaz
Posté par Juke (site web personnel) . Évalué à 2.
On Wed, Jan 30, 2013 at 06:03:17PM +0100, fravashyo wrote:
je suis curieux de voire comment tu genere le rss et le lien vers le zip est mort, peux tu publier ton projet quelque part ?
[^] # Re: usineàgaz
Posté par fravashyo . Évalué à 3.
si j'étais de mauvaise foi je dirais que c'était l'effet
slashdotlinuxfr mais en fait j'avais simplement oublié de publier le zip on dirait (ou je l'ai effacé par erreur, ou un vilain pirate a exploité une faille php parce que j'ai eu la mauvaise idée de ne pas avoir un site statique)« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: usine à gaz
Posté par ckyl . Évalué à 5.
Générer des fichier statiques compliqué ?
Ca n'a rien de statique ton truc .
Tu paies l'overhead du PHP pour servir des choses qui n'en ont pas besoin.
Tu paies le cout de maintenance (c'est dégueulasse les variables dans les .php)
Tu paies la sécurité d'un truc dynamique. Oh un joli XSS sur ton blog statique…
Et on peut continuer.
Non la solution de crEv est très élégante. D'ailleurs je recommande le même genre d'approche pour écrire la documentation dans vos équipe de dev. Dégagez les wiki dont l'UX est assez moisie et remplacez les par ce genre de système. On peut facilement réutiliser tout les outils de dev, de l'éditeur au VCS en passant par l'intégration continue ou grep pour trouver les infos. C'est du coup vachement plus productif. Pour ceux qui aiment pas le Ruby y'a Markdoc en Python qui fait le job.
[^] # Re: usine à gaz
Posté par fravashyo . Évalué à 3.
je n'ai jamais dit que je recherchais à faire un site statique.
D'ailleurs si ce n'est que ça, txt2tags est prévu à la base justement pour générer du contenu statique, avec la même source et la commande
txt2tags -t html --style style.css 2012-1204-NewBlog.blog.t2t
ça me génère le fichier 2012-1204-NewBlog.blog.html que je peux poser chez n'importe quel hébergeur.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: usine à gaz
Posté par CrEv (site web personnel) . Évalué à 2.
En quoi est-ce compliqué ?
La version courte de l'usage c'est :
Pas très compliqué quand même.
Et surtout c'est en rien comparable car je parle d'un blog statique ne dépendant que d'un serveur web et non d'un langage côté serveur.
[^] # Re: usine à gaz
Posté par Krunch (site web personnel) . Évalué à 3.
Markdown (préférablement le vrai, pas la réimplémentation bancale utilisée par DLFP) et mod_autoindex. Tout le reste c'est de la branlette.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: usine à gaz
Posté par CrEv (site web personnel) . Évalué à 2.
c'est à dire ?
Hum, tu génère ton html depuis le markdown, ok. Par contre, il faut bien créer une page html de base, un css, non ?
[^] # Re: usine à gaz
Posté par Krunch (site web personnel) . Évalué à 4.
https://linuxfr.org/suivi/impossible-de-mettre-des-backspaces-dans-les-commentaire-sans-user-de-subterfuges-abscons
https://linuxfr.org/suivi/la-page-de-nouveau-commentaire-redirige-vers-le-contenu-sans-permettre-de-commenter#comment-1304883
Entre autres.
Effectivement. Ça mérite pas un journal de 2600 mots par contre.
http://bl0rg.krunch.be/txt2html.sh
http://bl0rg.krunch.be/stylez.css
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: usine à gaz
Posté par CrEv (site web personnel) . Évalué à 3.
Oué enfin, ta solution et ce que je propose ne sont juste absolument pas comparable, désolé.
Si je ne voulais faire que du markdown et un template basique en html, pourquoi pas. Alors c'est sur, je comprend que si on veut une css qui fait 3 lignes et un template qui en fait 10 il n'y a pas besoin de cela. Parfais. Maintenant désolé d'avoir besoin d'un poil plus.
Et sinon, j'ai pas bien compris les "bugs". Sur le premier, c'est bien markdown qui gère les backslash de la sorte, non ?
Et le deuxième, il est où le rapport avec markdown ?
# Et en Python...
Posté par TNorth . Évalué à 3.
…pour ceux qui l’affectionnent particulièrement, il y a Poole qui est du même genre, avec probablement moins de fonctionnalités, mais qui fait l'essentiel et a un système de macros qui rend aisé l'ajout de petits hacks sympathiques.
[^] # Re: Et en Python...
Posté par laurentm . Évalué à 3.
Il existe énormément de générateurs de site web static, que ce soit en Python, ruby ou [votre langage préféré]. Ils font tous plus ou moins la même chose, certains sont orientés blog, d'autres sont fait pour la doc, mais au final aucun ne convient à 100% (en tout cas pour moi). J'en avais essayé une bonne dizaine avant de me rendre compte que trouver LA solution qui me convienne c'était mission impossible…
Perso, j'utilise Flask avec deux extensions (Frozen-Flask et Flask-FlatPages), c'est très très fortement inspiré d'un article de Nicolas Perriault. Du coup, aucune contrainte, je choisis mon langage de markup, la structure du site, et tout et tout. C'est-y pas merveilleux :)
[^] # Re: Et en Python...
Posté par CrEv (site web personnel) . Évalué à 3.
Oui, c'est un peu ça. Il y a plein de générateurs existant. Le truc c'est que c'est qu'ils ne font jamais tout, c'est toujours assez limité pour répondre aux besoins de l'auteur essentiellement et pas pour tous les cas.
C'est d'ailleurs une raison pour laquelle j'ai développé le mien, ce que j'ai essayé ne faisait pas ce que je voulais (en fait sass et coffee) donc j'ai tout recommencé ;) Faut dire que faire un générateur du genre c'est pas un trop gros boulot.
Et au final, c'est plutôt cool :)
[^] # Ikiwiki
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 3.
Ikiwiki
Sur FusionInventory, on a migré sur Ikiwiki. En gros, on a un dépôt git avec des fichiers Markdown qu'on pousse sur le serveur. Le serveur se charge de générer les pages.
Ikiwiki a trois gros intéret à mes yeux :
- Il est toujours possible d'éditer les pages et poster des commentaires avec un navigateur Internet
- branchable.com permet d'être hébergé sans s'embêter
- et surtout, on peut activer un mode “traduction”, dans ce cas, des fichiers de langue sont générés et ici aussi on peut soit les traduits avec l'interface web, soit avec un client git.
Au final, on a enfin un site facile a maintenir et surtout simple a traduire !
[^] # Re: Et en Python...
Posté par steph1978 . Évalué à 2.
Je suis d'accord.
L'idée est donc d'en trouver un qui soit le plus proche de ce que tu veux faire et dans les technos que tu maîtrises ou qui t'intéressent.
Perso j'aime bien l'approche de qui consiste à utiliser la génération de site statique. Quand l'usage principale est la lecture, c'est très efficace. Cela permet (implique) de dissocier le frontend (lecture) du backend (post, commentaires, etc.). Donc d'avoir une architecture mieux adaptée à l'usage. Par exemple frontend synchrone chez un hébergeur avec une bonne bande passante et une bonne disponibilité et backend asynchrone en auto-hébergement, plus souple.
Pour ma part, j'ai joué avec jinja2, un peu de sqlite, le tout enrobé de python et j'en ai été très content :)
# Commentaires
Posté par Thom (site web personnel) . Évalué à 6.
Super article. Merci.
J'avoue que les générateurs statiques m'intéresse et m'attire particulièrement. Mais une seule chose freine encore mon envie de sauter le pas : les commentaires…
Je n'ai pas envie de me priver de commentaires et les sites statiques en sont clairement dépourvus.
Je comprends bien la problématique de ne pouvoir avoir de commentaire dynamique sur un site statique. Mais les solutions actuelles comme disqus (la plus connu) sont loin d'être digne de confiance…
J'ai entendu parler de Juvia, mais je n'ai pas encore réussi à tester ça. En plus, ça ne fait pas les commentaires en thread…
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Commentaires
Posté par laurentm . Évalué à 2.
Pour les commentaires, David Larlet utilise une solution à base de mailing list. C'est expérimental et je ne sais pas trop si ça fonctionne bien (comprendre : est-ce qu'il y aurait plus de commentaires avec un système classique ?). En tout cas, ça sort de l'ordinaire et c'est une idée originale.
[^] # Re: Commentaires
Posté par CrEv (site web personnel) . Évalué à 2.
J'avais vu ça, mais je trouve ça plutôt étrange. Entre autre le fait que les commentaires sont externalisés même pour leur consultation. C'est plutôt étrange, déroutant, et j'en vois pas bien l'intérêt.
Mais c'est vrai que ça a le mérite d'être original.
[^] # Re: Commentaires
Posté par CrEv (site web personnel) . Évalué à 5.
Ha, les commentaires…
Pour ma part je ne veux pas de disqus (pour tout un tas de raisons, en premier lieu la possibilité de recoupement et les infos que disqus peut avoir)
Ensuite, je ne veux pas non plus de solution équivalente pour d'autres raisons, par exemple le fait que les commentaires ne font pas partie de la page mais sont en général chargés par iframe. Résultat, pas d'indexation par exemple.
Je suis en train de chercher quelques solutions, l'objectif étant que les commentaires soient aussi générés par wlt, donc dans l'html généré. Evidemment cela demande des opérations manuelles (la génération est commandée manuellement pour moi) et donc une modération des commentaires. Mais en général, c'est préférable (pas de spam, pas tant de commentaire que ça donc pas trop de taff).
Le problème est que tout cela nécessite une composante serveur. Par contre, le but est de l'externaliser, que ce soit un composant indépendant du site et de l'affichage, que ce soit mutualisable.
Donc au final, l'idée (non implémentée pour le moment, j'ai pas eu le temps) est de jouer beaucoup avec git : un formulaire qui pointe sur une partie serveur externe. Le commentaire écrit est transformé… en commit dans une branche dédiée à la page (le commentaire devient une portion de markdown dans un fichier lié à la page, tous les commentaires d'une même page dans une même branche)
Il faut juste rajouter un petit outil dans wlt pour pouvoir choisir les commentaires (commits) à publier. Les infos genre adresse mail est dans le message de commit.
Il ne reste donc qu'à merger les contenus (les commentaires) et deployer la version générée.
En gros, le principe est un peu le même qu'une pull request, le commentaire étant vu comme un ajout au post.
Bon, je sais pas si c'est clair, ni si ça peut vraiment fonctionner, mais ce sera à tester lorsque j'aurai le temps…
[^] # Re: Commentaires
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Bien sûr! Il y a même des tordus qui, de la même façon, détournent un gestionnaire de version pour en faire une messagerie distribuée: http://devnewton.bci.im/home/?q=node/25
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Commentaires
Posté par CrEv (site web personnel) . Évalué à 3.
Ha oui, c'est vrai que ce qui est bien dans l'informatique c'est que quand tu penses avoir une idée un peu tordue, tu peux être certain que quelqu'un a déjà eu une idée… beaucoup plus tordue ! ;-)
[^] # Re: Commentaires
Posté par benoar . Évalué à 3.
Je sais pas si ça peut t'intéresser, mais le coup du site statique avec des pages « dérivées » (y compris pour commentaires, si on veut) qui seraient enregistrées dans des branches à part en git, et donc sur une autre partie « dynamiques », je l'expérimente dans un projet à moi qui est un peu inactif en ce moment : http://dolka.fr/code/gitollion.git
C'est aussi basé sur des technos « modernes » mais je voulais faire beaucoup plus simple : utiliser Sphinx pour ne pas avoir à réinventer un système de publication (même s'il est un peu trop orienté documentation parfois), git pour le versionning, et Pyramid pour la partie dynamique. Bon en fait, je triche, je ne sers pas vraiment de fichiers « statiques » directement, mais des blob git qui peuvent leur correspondre, mais ça revient quasiment au même. Ah, et c'est plutôt orienté wiki, moins blog.
Et pour l'instant, c'est pas documenté ni décrit nulle part, donc bon courage ;-)
[^] # Re: Commentaires
Posté par Juke (site web personnel) . Évalué à 2.
L'utilises tu publiquement quelque part ?
[^] # Re: Commentaires
Posté par benoar . Évalué à 2.
C'est en « prod » sur http://grifon.fr/ mais ça n'est pas encore du tout adapté à la contribution dynamique, car beaucoup trop buggé (c'est surtout un premier jet). On l'utilise là-bas surtout comme dépôt git multi-version avec génération automatique du HTML.
J'ai fait assez attention à séparer les différentes parties du projet : il y a le script qui sert à garder un dépôt git « parallèle » à un autre pour du contenu généré (le HTML sorti par Sphinx), et le « reste » qui peut être divisé entre la partie (très simple, en gros un git cat-file amélioré) qui sort les blobs en fonction des requêtes HTTP, et la partie « dynamique » qui stocke les modifications du wiki par commit en git.
[^] # Re: Commentaires
Posté par maboiteaspam . Évalué à 0. Dernière modification le 02 février 2013 à 01:21.
Il me semble que ce sont deux choses tout à faits distinct.
L'un c'est du contenu statique, que tu peux te permettre si ça te plait, de compiler.
L'autre, les commentaires, sont tout à fait dynamique, et ce serait assez ouf de re compiler le site, re déployer, a chaque nouveau commentaire.
Ou alors, il faut partir sur des système à wake up régulier, mais cela implique pour l'utilisateur que son post n'est pas instantané.
Sachant qu'en plus tout l’intérêt de la compilation et de balancer le site on the CDN, cela commence à faire beaucoup de latence pour des fonctions que l'on sait très bien faire aujourd'hui avec des langages cote serveur.
Bref, j'ai pris partit de ne pas mélanger ces deux choses. Elles ne sont liés que par l'ui, et l'ui m'offre pléthore de solution pour mixer le compiler et le JIT selon les besoins de la fonctionnalité.
désolé pour les fautes toousa.
[^] # Re: Commentaires
Posté par CrEv (site web personnel) . Évalué à 3.
ce qui est de toute façon le cas avec des commentaires modérés…
auquel il faut rajouter un moyen de persistance qui serait en doublon avec mon git
hum, non. en tout cas pas directement
L'intérêt premier est que c'est plus cool à gérer qu'un logiciel côté serveur. Ensuite c'est beaucoup plus sympa en terme de gestion serveur car pas de langage. Je peux donc déplacer mon domaine et son contenu très facilement.
Mais le but est au contraire de traiter les commentaires comme du contenu venant enrichir le contenu initial.
[^] # Re: Commentaires
Posté par maboiteaspam . Évalué à -1.
Oui effectivement cet exemple de commentaire est un peu tendancieux en ta faveur.
Si je prenais plutôt un exemple sur une fonction qui utilise le temps, ou le statut de l'utilisateur pour modifier le contenu.
Cela impliquerait que tout une logique soit déplacé,
- ou dans la vue, cf ta problématique
- ou côté serveur, ma position
At least une bonne raison de le placer côté serveur est de contrôler les accès.
Car placé dans la vue c'est permettre à tout a chacun d'accéder ce contenu.
Hors il est des cas où ce comportement n'est pas désiré.
Effectivement une base de donnée, serait un doublon.
Mais si tu voulais garder uniquement une base de fichier, ta base de données pour les commentaires, serait donc un fichier compilable.
Genre une liste ul > li, je sais pas.
Dans ce cas là, la compilation générerait plusieurs versions des commentaires
- une version public avec tous les commentaires modérés
- une version privée, avec modération des commentaires
Après avec e-tag facile à générer pour le coup, c'est très agréable à hoster.
En tout cas, cette idée de prendre le fichier comme base de stockage, et de développement me semble forte intéressante à moi aussi.
[^] # Re: Commentaires
Posté par CrEv (site web personnel) . Évalué à 2.
Ha oui, mais là on est vraiment dans quelque chose de totalement différent. D'ailleurs de mon point de vue je fais de la publication simple, il n'existe même pas d'utilisateur…
Heu, justement, je ne contrôle pas les accès, c'est ouvert (les sources sont même publiques)
Oui, les commentaires seraient un fichier qui est inclus dans la génération, aucune vrai différence avec un billet.
Oula non. Mon idée (pas encore implémentée faute de temps) est juste d'utiliser git comme base de données. Les informations du commentateur (email par exemple) seraient dans les données du commit. Le commentaire serait le contenu du commit. la modération se fait alors en cherry-pickant / fusionnant les commits ou non.
Git est donc l'outil de modération et de "base de donnée".
Par contre, je ferai tout ça dans un autre dépôt, pas question d'avoir cela en publique.
# Recherche
Posté par redgriff . Évalué à 2.
Je n'ai pas vu de fonction recherche.
C'est assez simple à rajouter même pour un site statique tant qu'il n'y a pas trop de contenu.
Par exemple, Sphinx construit un index de recherche lors de la compilation. Pour effectuer une recherche, il y a un script qui charge l'index, construit la requête et charge les résultats. J'ignore s'il y a des équivalents écrits en ruby (pour l'indexation) mais l'approche et le code javascript doit être réutilisable.
[^] # Re: Recherche
Posté par CrEv (site web personnel) . Évalué à 3.
En effet, il n'y a pas de fonctionnalité de recherche. Franchement j'en ai pas du tout vu l'intérêt. Il m'arrive assez peu d'utiliser les recherches sur les blogs (et google est plutôt bon en général…)
Mais ça reste une piste d'amélioration, faudrait que je regarde plus en détail ce que fait sphinx.
# Merci
Posté par Ago . Évalué à 2.
Encore une fois un journal de qualité.
Merci à toi pour le partage, c'est un plaisir de te lire et de découvrir tout ce petit monde.
# Migration contenu dotclear wiki2xhtml vers markdown
Posté par franek . Évalué à 0.
Petite question : Si tu es parti d'un blog dotclear vers un contenu au format Markdown, tu as sûrement dû être confronté à un problème de migration du contenu dotclear (au format wiki2xhtml) vers Markdown. Si oui, comment l'as-tu résolu ? Je suis à la recherche d'un script de migration. Je n'ai encore rien trouvé de pertinent et n'ai pas encore pris le temps de le faire. J'ai testé rapidement le script présent dans Pelican mais il n'est pas parfait (chez moi, il n'arrive pas à migrer les liens, ne récupère pas les tags, …).
Merci,
[^] # Re: Migration contenu dotclear wiki2xhtml vers markdown
Posté par CrEv (site web personnel) . Évalué à 2.
Nope. Mon dotclear existe toujours, j'ai choisi de ne rien migrer. De toute façon je n'aurais pas pu garder les mêmes urls par exemple. Et je n'en ai pas vu vraiment l'intérêt.
Mais si je devais le faire, je pense que je m'arrangerais simplement pour récupérer les contenus des articles en html (ça doit être faisable sans trop de problème) et je les transformeraient en pages html statiques à placer dans _pub. En gros. Mais bon, je pense que je ne le ferai jamais.
[^] # Re: Migration contenu dotclear wiki2xhtml vers markdown
Posté par saimn . Évalué à 1.
Pour Pelican (et pour avoir écris une partie du script en question pour le support de dotclear ;-)):
# une question comme ca
Posté par maboiteaspam . Évalué à 1.
Tu ne trouves pas que c'est un peu dommage de rajouter cette étape de compilation autour de ces langages de bases qui depuis toujours ont fais la part belle à l’exécution JIT ?
Les outils choisit sont probablement très bien, mais je ne peux m’empêcher de penser qu'il y à perte d'un acquis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.