Journal Un wiki pas cher

Posté par  .
Étiquettes : aucune
0
1
sept.
2005
Voulant mettre en place un wiki pour un petite équipe de 5 personnes, je me suis plonger dans le monde sans pitié des wikis où la concurrence fait rage, et j'ai trouvé un wikounet tout petit, tout mignon, c'est dokuwiki.
Ce wiki n'a même pas besoin de base mysql, les articlers étant de "vulgaires" fichiers textes dans ./data/ . Bien sûr, un .htaccess vient protéger le contenu. Du coup, pas la peine de faire un mysql ou sqlplus pour supprimer un article, unrlm suffit.

Je remercie donc les developpeurs de dokuwiki de leurs investissement pour créer ce bijou.

Et mince, j'allais oublier de mettre le lien qu'il faut:
http://wiki.splitbrain.org/(...)
  • # Liens

    Posté par  . Évalué à 4.

  • # Résultats ?

    Posté par  . Évalué à 5.

    Puis-ce que tu as comparé des wikis, pourrais-tu en dire plus sur tes recherches pour ceux qui feraient le même type de recherches que toi ?

    Par exemple, quels-sont ceux pour lesquels tu t'es dit "ah non pas celui-là", et sur quels critères ?

    Envisages-tu de publier un comparatif ?

    Voilà, désolé si je pose trop de questions, mais puisque des dizaines de personne font le même type de recherche que toi chaque jour, il serait bien que tu leur fasses profiter de ta science [insérer ici votre blabla préféré du type "c'est bien de bénéficier du libre et il ne faut pas hésiter à donner aussi"]
    • [^] # Re: Résultats ?

      Posté par  . Évalué à 5.

      J'ai eu aussi à faire cela. Et je me suis également arrêté sur dokuwiki, principalement pour sa non-utilisation de base de données, un gage de pérennité maximum des données.

      Mais si dokuwiki m'a séduit c'est aussi pour ce tableau comparatif qu'on peut trouver sur le wiki de l'auteur :

      http://wiki.splitbrain.org/wiki%3Acompare(...)

      ... qui répond à beaucoup de questions sur les uns et les autres et te fait gagner du temps :-) Bonne lecture...
      • [^] # Re: Résultats ?

        Posté par  . Évalué à 1.

        Ah, merci bien, même si je me méfie toujours des comparatifs fait par des personnes promouvant un des éléments comparés. En tout cas c'est une bonne base de réflexion, ça reste bon à prendre, merci.
        • [^] # Re: Résultats ?

          Posté par  . Évalué à 1.

          En general, j'en ai trouvé moche d'aspect, d'autre peu instinctif, certains trop "machine à gaz"....
          Mais je ne citerais pas de nom (car je n'ai préféré ne pas me souvenir de leurs noms, sf wikini, et le wiki de wikipedia)
          Bref, dokuwiki m'a plus et le conf du style est ultra simple
      • [^] # Re: Résultats ?

        Posté par  (site web personnel) . Évalué à 2.

        En quoi est-ce un gage de pérénité des données ?
        Si les fichiers textes sont codés avec un format à la con tu va en chier pour l'importer dans un autre système que tu aurais choisi.

        Dans une base de données, tu auras bien sûr le même genre de problèmes d'import/export.

        Moi je vois plutôt ça comme un atoût par rapport à l'installation car ton hébgergeur ne te fournit pas toujours d'accès à une base de données.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Résultats ?

          Posté par  (site web personnel) . Évalué à 1.

          dans certaint cas une base peut etre interessante, dans d'autre cas, les fichiers peuvent etre bien pratique

          A premiere vue :
          Base de donnée
          + calculée pour etre rapide meme avec un grand nombre de donné (cache de requetes)
          + tris efficace
          + Possibilité de sortir des données dans n'importe quel ordre ? (si je veut toute les dates ou une page a été modifié, je suis obligé de tenir un fichiers de date)
          + Possibilité de faire des actions et des scripts en dehors de celle prevu par l'applis (SQL)
          + Libere (un peu) les disques

          - Oblige un serveur ( temps CPU, Memoire) ..

          Fichiers
          + Structure paraissant adapté a un wiki (page bien distincte)
          + Sans serveur (hebergement facile & temps CPU & memoire vive)
          + Sauvegarde & deplacement facile


          - Difficulté de gerer des informations complementaire au contenue des pages .. de les triés et de cherché dans un ordre non prevu par l'applis
          - Tout les hebergeur accepte la creation de fichiers "a la volé" ?
          - ca fait pas mal au disque quand meme ? (contrairement a une monté d'information en memoire vive)

          Quand a sa simplicité de codage, entre gerer plusieurs fichiers (a chaque page) et gerer une requete mysql, moi je dit, pareil...

          En aucun cas je dit que tu as fait le mauvais choix, juste ..ca me parais moin simple que ca ...(moi j'ai pris base, mais je connais pas mal le SQL et le codage mysql/php, ca aide)

          Baptiste
          • [^] # Re: Résultats ?

            Posté par  . Évalué à 2.

            En même temps, c'est ça le libre: y'en a pour tout le monde
        • [^] # Re: Résultats ?

          Posté par  . Évalué à 2.

          L'idée d'exploiter le système de fichiers pour le stockage des données a plusieurs avantages, en particulier toutes les manipulations classiques sur les fichiers/dossiers (déplacement, suppression, liens symboliques, etc...) de manière standard et transparente, mais aussi pour mettre en place une solution de backup ou de synchronisation en quelques simples lignes de script...

          Quand tu stockes les données en base, tu est contraint à l'utilisation du langage SQL pour toute manipulation de tes données. Il n'est pas possible d'y accéder directement et simplement, le tout étant stocké au final dans un format binaire complètement opaque et non utilisable en tant que tel (pire encore que le format à la con que tu imaginais).

          En l'occurence, les fichiers générés sont très clairs et lisibles même pour celui qui découvre les syntaxes wiki. Aucun problème donc pour les convertir en texte brut ou en HTML s'il le fallait, sans aucune dépendance logicielle pour ce faire.

          Certes, un stockage en base de données aurait aussi ses avantages (recherches, traitements etc...), mais c'est toujours intéressant d'avoir le choix !
          • [^] # Re: Résultats ?

            Posté par  . Évalué à 2.

            C'est surtout une question de préférence.

            Personnellement, je préfère enregistrer mes données dans une base de donnée. Le SGBD tourne déjà et est déjà sauvegardé; et les manipulations sont, je trouve, bien plus pratique en SQL; on peut modifier un grand nombre de page avec une seule requête; si jamais on fait une fausse manip on peut faire un rollback; on s'interface facilement avec n'importe quel autre outil sans avoir à implémenter une gestion de fichiers; on n'a pas besoin de gérer 36 fonctions et autant de cas d'erreur (erreur sur la recherche de fichier, erreur sur l'ouverture du fichier, erreur sur la lecture du fichier, erreur à la fermeture du fichier...).

            Je comprends que l'on puisse avoir des contraintes matérielle qui interdise l'usage d'une base, ou un manque de maitrise; mais il me semble que les bases de données ont été conçues justement pour manipuler les données, et qu'elles le font très bien.
        • [^] # Re: Résultats ?

          Posté par  (site web personnel) . Évalué à 1.

          Wiki utilisant MySQL ou des fichiers textes, ça change rien à la pérénité. L'essentiel du wiki étant le contenu des pages ! Dans MediaWiki par exemple, c'est un champ d'une table (en l'occurance, wiki_cur.cur_text de type « mediumtext », texte codé en UTF-8). L'intérêt de MySQL (ou autre SGBD) est que c'est plus optimisé que des accès à des fichiers textes standards (exemple : recherche plein texte, tri selon différents critères, etc.). Le désavantage est qu'il faut un serveur.

          Pour rappel, les bases de donnée ont été inventées pour palier aux défauts des systèmes basés uniquement sur des fichiers ...

          Pour moi, un wiki c'est plus que des documents : y'a la gestion des utilisateur, gestion de l'historique, recherche, ...

          Faire des sauvegardes : pas de pb. MySQL permet de faire un dump, et d'ailleurs avec les tables au format InnoDB on peut avoir un dump alors qu'on est en train de modifier la base parallèlement. Un p'tit script bash avec sauvegarde de la base + sauvegarde des fichiers (images) et puis c'est tout.

          Haypo
      • [^] # Re: Résultats ?

        Posté par  (site web personnel) . Évalué à 1.

        Pour du texte en fichier, je préfère MoinMoin et d'après ton tableau, niveau fonctionnalité, il est en avance.
    • [^] # Re: Résultats ?

      Posté par  . Évalué à 3.

      J'ai égallement fait le tour des wikis. J'ai retenu Mediawiki pour sa communauté. Un tour sur le IRC de Wikipedia France et une personne réponds.
      Il est vrai que mediawiki est immodifiable pour un non programmeur php, ce qui est mon cas, d'ailleur je m'en mort les doigts. C'est aussi une usine à gaz au niveau ressource mais il est bien. Il faut précisé que j'ai un hébergeur sympa (php5+3 mysql+stat+3 adresses+etc...).
    • [^] # Re: Résultats ?

      Posté par  (site web personnel) . Évalué à 3.

      tiens sur wikini j'avais ajouté diverses url de comparatifs que j'avais trouvés :
      http://www.wikini.net/wakka.php?wiki=WakkaForks(...)

      à l'époque je m'étais fait celui-ci : http://www.wikini.net/wakka.php?wiki=WackoWikiNiComparison(...)

      sinon tikiwiki est celui qui me convient pour utf-8 et internationalisation, mais c'est un peu trop lourd
    • [^] # Re: Résultats ?

      Posté par  . Évalué à 1.

      A défaut d'un comparatif stricto sensu, tu peux jeter un oeil à la rubrique wiki de Framasoft. http://www.framasoft.net/rubrique335.html(...)

      Moi, j'ai un petit faible pour Chuwiki. http://chuwiki.berlios.de/(...)
  • # PmWiki

    Posté par  . Évalué à 3.

    Dans le même genre PmWiki n'est pas mal non plus : http://pmwiki.org/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.