mais tu n'as pas besoin de tout régénérer à chaque fois que tu postes un article, si ?
Si. Et j’ai fait exprès, en plus !
Il y a deux bonnes raisons raisons à vouloir réécrire 100% des fichiers lorsque l’on poste un article. La première est technique (la facilité de maintenance du logiciel), la seconde est d’ordre humain (un logiciel ne doit pas nuire).
Fblog est issu de ma seule expérience d’avec NanoBlogger (je n’avais jamais blogué auparavant). NanoBlogger a l’option de rafraîchissement qui permet une mise à jour partielle du blog en cas d’ajout d’un billet (ou de sa modification) et une autre de reconstruction totale. Je pense que d’autres moteurs de blog statique ont eux aussi ces deux options (mais en fait, je n’en sais rien...). Les utilisateurs de NanoBlogger ont rapportés de nombreux bogues car ils se contentaient de faire une mise à jour partielle plutôt qu’une mise à jour intégrale lors de certaines circonstances. Le vrai problème pour le programmeur est de décider où doit se situer le curseur entre le partiel et l’intégral. Et le problème pour l’utilisateur est de savoir ce qu’en pense le programmeur. En plus, du point de vue du code, c’est une sacré complication que d’implémenter et faire coexister les routines des mises à jour partielles et intégrales.
J’ai longtemps hésité sur l’utilité d’une mise à jour partielle. Mais quand j’ai vu que la technologie des machines d’aujourd’hui permettait de générer des milliers de fichiers en quelques secondes, d’un point de vue pragmatique, j’ai décidé que c’était un tracas inutile que d’implémenter l’option de rafraîchissement. L’autre raison est bien plus cruciale : un logiciel ne doit pas nuire à son utilisateur.
Un blog est une chose amusante à tenir, sinon en en tiendrait pas, hein ? Sauf que sur Internet, comme dans la vraie vie, « si les paroles s’envolent, les écrits restent ». Il peut arriver que l’on ait à supprimer un ancien billet devenu compromettant. Dans ce cas, l’option de rafraîchissement du blog devra-t-il en tenir compte ou pas ? C’est le choix du programmeur et uniquement lui. Et encore heureux s’il ne change pas d’avis entre deux versions ! Il y a aussi, dans le cas d’une option de rafraîchissement, la possibilité de dé-indexer le billet mais sans le supprimer du système de fichier. Tout est possible, c’est le programmeur qui décide ! Reste qu’à ce moment là, si le billet compromettant a été mis en marque-page quelque part, il sera toujours lisible sur Internet même si son lien au sein du blog a été supprimé.
Il y a aussi une chose encore plus pernicieuse concernant la suppression d’un billet de blog : celle que cette action entraîne un aveu de culpabilité. En effet, si quelqu’un demande et obtient la suppression d’un billet offensant, il jubile. Encore faut-il qu’il puisse apporter la preuve que sa réclamation ait été couronnée de succès ! En effet, pour des facilités de modification / suppression d’un billet de blog statique, il semble évident d’attribuer un identifiant à chaque billet. Ce pourrait être la date et l’heure mais c’est pas pratique à saisir. Donc, j’ai choisi un identifiant numérique. Mais si j’attribue un identifiant numérique fixe qui s’incrémente au fur et à mesure que le blog grossi , la suppression d’un billet sera visible car il y aura un trou dans l’ordre des identifiants. C’est pourquoi fBlog renumérote absolument tous les billets que l’on en ajoute ou que l’on en supprime. Et pour couronner le tout, j’ai choisi de mettre le numéro le plus faible pour le plus récent des billets (numéro 1) et le numéro le plus fort pour le billet le plus ancien (numéro égal au total des billets du blog). Ainsi, en ouvrant la page d’accueil du blog, on ne peut pas deviner si un billet a été supprimé suite à un contentieux.
Le seul fait de renuméroter tous les billets du blog entraîne une mise à jour intégrale. Fblog, pour ces raisons de sûreté de la vie privée, détruit l’intégralité des données résidant dans le sous-répertoire « fBlog/export_html » avant de procéder à la mise à jour. Ceci évite donc d’y voir résider un billet que l’on pensait avoir supprimer de bonne fois. Cependant, si l’utilisateur se contente d’uploader les fichiers de ce sous-répertoire vers son serveur Web (au lieu de faire une vraie synchronisation !), le billet qu’il croyait avoir supprimé sera toujours visible sur Internet. Mais ça, ce n’est plus de ma responsabilité d’auteur !
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard . En réponse à la dépêche Moteur de blog fBlog. Évalué à 6.
Si. Et j’ai fait exprès, en plus !
Il y a deux bonnes raisons raisons à vouloir réécrire 100% des fichiers lorsque l’on poste un article. La première est technique (la facilité de maintenance du logiciel), la seconde est d’ordre humain (un logiciel ne doit pas nuire).
Fblog est issu de ma seule expérience d’avec NanoBlogger (je n’avais jamais blogué auparavant). NanoBlogger a l’option de rafraîchissement qui permet une mise à jour partielle du blog en cas d’ajout d’un billet (ou de sa modification) et une autre de reconstruction totale. Je pense que d’autres moteurs de blog statique ont eux aussi ces deux options (mais en fait, je n’en sais rien...). Les utilisateurs de NanoBlogger ont rapportés de nombreux bogues car ils se contentaient de faire une mise à jour partielle plutôt qu’une mise à jour intégrale lors de certaines circonstances. Le vrai problème pour le programmeur est de décider où doit se situer le curseur entre le partiel et l’intégral. Et le problème pour l’utilisateur est de savoir ce qu’en pense le programmeur. En plus, du point de vue du code, c’est une sacré complication que d’implémenter et faire coexister les routines des mises à jour partielles et intégrales.
J’ai longtemps hésité sur l’utilité d’une mise à jour partielle. Mais quand j’ai vu que la technologie des machines d’aujourd’hui permettait de générer des milliers de fichiers en quelques secondes, d’un point de vue pragmatique, j’ai décidé que c’était un tracas inutile que d’implémenter l’option de rafraîchissement. L’autre raison est bien plus cruciale : un logiciel ne doit pas nuire à son utilisateur.
Un blog est une chose amusante à tenir, sinon en en tiendrait pas, hein ? Sauf que sur Internet, comme dans la vraie vie, « si les paroles s’envolent, les écrits restent ». Il peut arriver que l’on ait à supprimer un ancien billet devenu compromettant. Dans ce cas, l’option de rafraîchissement du blog devra-t-il en tenir compte ou pas ? C’est le choix du programmeur et uniquement lui. Et encore heureux s’il ne change pas d’avis entre deux versions ! Il y a aussi, dans le cas d’une option de rafraîchissement, la possibilité de dé-indexer le billet mais sans le supprimer du système de fichier. Tout est possible, c’est le programmeur qui décide ! Reste qu’à ce moment là, si le billet compromettant a été mis en marque-page quelque part, il sera toujours lisible sur Internet même si son lien au sein du blog a été supprimé.
Il y a aussi une chose encore plus pernicieuse concernant la suppression d’un billet de blog : celle que cette action entraîne un aveu de culpabilité. En effet, si quelqu’un demande et obtient la suppression d’un billet offensant, il jubile. Encore faut-il qu’il puisse apporter la preuve que sa réclamation ait été couronnée de succès ! En effet, pour des facilités de modification / suppression d’un billet de blog statique, il semble évident d’attribuer un identifiant à chaque billet. Ce pourrait être la date et l’heure mais c’est pas pratique à saisir. Donc, j’ai choisi un identifiant numérique. Mais si j’attribue un identifiant numérique fixe qui s’incrémente au fur et à mesure que le blog grossi , la suppression d’un billet sera visible car il y aura un trou dans l’ordre des identifiants. C’est pourquoi fBlog renumérote absolument tous les billets que l’on en ajoute ou que l’on en supprime. Et pour couronner le tout, j’ai choisi de mettre le numéro le plus faible pour le plus récent des billets (numéro 1) et le numéro le plus fort pour le billet le plus ancien (numéro égal au total des billets du blog). Ainsi, en ouvrant la page d’accueil du blog, on ne peut pas deviner si un billet a été supprimé suite à un contentieux.
Le seul fait de renuméroter tous les billets du blog entraîne une mise à jour intégrale. Fblog, pour ces raisons de sûreté de la vie privée, détruit l’intégralité des données résidant dans le sous-répertoire « fBlog/export_html » avant de procéder à la mise à jour. Ceci évite donc d’y voir résider un billet que l’on pensait avoir supprimer de bonne fois. Cependant, si l’utilisateur se contente d’uploader les fichiers de ce sous-répertoire vers son serveur Web (au lieu de faire une vraie synchronisation !), le billet qu’il croyait avoir supprimé sera toujours visible sur Internet. Mais ça, ce n’est plus de ma responsabilité d’auteur !