je ne vois pas trop ce que tu reproches à du contenu généré dynamiquement. Tous les hébergeurs mutualisés proposent du php, et si tu as un dédié ou un auto-hébergement tu peux utiliser ce que tu veux (ror, php, python etc).
Le seul intérêt que je vois, c'est juste de s'amuser avec de nouvelles technologies que tu cites (haml, sass, ruby, rake, gem, git, bundler, guard, guard-rake, coffeescript, redcarpet, pygments etc…), par contre, quand tu critiques le fait que par exemple pmwiki nécessite de "gérer" la version de php, ça fait juste un paramètre à prendre en compte (pas de base de données relationnelle, le contenu est stocké en plein texte), en revanche dans la chaîne de production que tu utilises, il y en a plus de 10 !
Que se passe-t-il si un des chaînons casse ? S'il change de comportement, s'il y a un bogue lors d'une mise à jour ? Ça me semble autrement plus périlleux que de vérifier une unique version de PHP, d'autant plus que pmwiki est simple et compact, régulièrement mis à jour, et toutes des versions récentes de PHP fonctionnent sans problème avec.
et justement, tout ceci n'est pas un wiki (je n'aime pas du tout les wiki détournés pour faire autre chose
On pourrait d'ailleurs dire la même chose de Ruby : je n'aime pas les langages de programmation détournés pour faire autre chose, un langage de programmation ce n'est pas fait pour créer des pages html (ou faire office de serveur web, comme ROR)
hélas, le nom de pmwiki, choisi sans doute à l'époque florissante des débuts du concept de wiki, ne s'applique plus à ce que c'est devenu : un système de gestion de contenu comme un autre, qui utilise effectivement le principe de wiki pour éditer les pages, mais qui permet la plupart des choses que l'on trouve dans un CMS comme Drupal par exemple.
Enfin, l'avantage dans mon utilisation de pmwiki, c'est que j'utilise la même syntaxe en txt2tags qu'ailleurs, et il m'est possible à partir d'un site en pmwiki de l'exporter en LaTeX (pdf), ou en html statique, via un petit script qui récupère le contenu en mode texte de pmwiki. De plus, il est possible de recoller le contenu en txt2tags dans les autres CMS existants qui en supportent la syntaxe : entre autres dotclear, dokuwiki, plone, wordpress, drupal.
Et si on préfère le html static, il reste toujours l'export html de txt2tags : txt2tags -t html fichier.t2t
J'ai d'ailleurs créé la plupart de mes sites sur ce principe, mais maintenant je trouve fastidieux de devoir éditer les fichiers en local, les convertir, renvoyer les fichiers générés sur le serveur ftp, alors je migre progressivement tout dans par exemple pmwiki (ou encore il est possible de servir directement les fichiers originaux via le module php)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: webgen
Posté par fravashyo . En réponse au journal Écrire une page web de nos jours, troisième partie. Évalué à 1.
je ne vois pas trop ce que tu reproches à du contenu généré dynamiquement. Tous les hébergeurs mutualisés proposent du php, et si tu as un dédié ou un auto-hébergement tu peux utiliser ce que tu veux (ror, php, python etc).
Le seul intérêt que je vois, c'est juste de s'amuser avec de nouvelles technologies que tu cites (haml, sass, ruby, rake, gem, git, bundler, guard, guard-rake, coffeescript, redcarpet, pygments etc…), par contre, quand tu critiques le fait que par exemple pmwiki nécessite de "gérer" la version de php, ça fait juste un paramètre à prendre en compte (pas de base de données relationnelle, le contenu est stocké en plein texte), en revanche dans la chaîne de production que tu utilises, il y en a plus de 10 !
Que se passe-t-il si un des chaînons casse ? S'il change de comportement, s'il y a un bogue lors d'une mise à jour ? Ça me semble autrement plus périlleux que de vérifier une unique version de PHP, d'autant plus que pmwiki est simple et compact, régulièrement mis à jour, et toutes des versions récentes de PHP fonctionnent sans problème avec.
On pourrait d'ailleurs dire la même chose de Ruby : je n'aime pas les langages de programmation détournés pour faire autre chose, un langage de programmation ce n'est pas fait pour créer des pages html (ou faire office de serveur web, comme ROR)
hélas, le nom de pmwiki, choisi sans doute à l'époque florissante des débuts du concept de wiki, ne s'applique plus à ce que c'est devenu : un système de gestion de contenu comme un autre, qui utilise effectivement le principe de wiki pour éditer les pages, mais qui permet la plupart des choses que l'on trouve dans un CMS comme Drupal par exemple.
Enfin, l'avantage dans mon utilisation de pmwiki, c'est que j'utilise la même syntaxe en txt2tags qu'ailleurs, et il m'est possible à partir d'un site en pmwiki de l'exporter en LaTeX (pdf), ou en html statique, via un petit script qui récupère le contenu en mode texte de pmwiki. De plus, il est possible de recoller le contenu en txt2tags dans les autres CMS existants qui en supportent la syntaxe : entre autres dotclear, dokuwiki, plone, wordpress, drupal.
Et si on préfère le html static, il reste toujours l'export html de txt2tags : txt2tags -t html fichier.t2t
J'ai d'ailleurs créé la plupart de mes sites sur ce principe, mais maintenant je trouve fastidieux de devoir éditer les fichiers en local, les convertir, renvoyer les fichiers générés sur le serveur ftp, alors je migre progressivement tout dans par exemple pmwiki (ou encore il est possible de servir directement les fichiers originaux via le module php)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond