Articles précédents : Logiciel
- [43] Dictionnaire orthographique français inclus par défaut dans Firefox, Thunderbird et Seamonkey
- [66] Sortie de PostgreSQL 8.3
- [6] Jukebox Power Pack : collaboration de trois projets de lecteurs audio
- [18] Sortie de zsh 4.3.5 et 4.2.7
- [29] Barracuda défend l'anti-virus ClamAV contre les brevets logiciels
- [11] Sortie de Tellico 1.3
- [16] Simpleweb, un CMS ultra-simple sans base de données
- [14] Elisa Media Center 0.3.3 "Mayfly" est sortie
- [65] Sortie du noyau Linux 2.6.24
- [93] KDE devient multiplateforme
Liens connexes
- twiki.org (1897 hits)
- Greffons et autres extensions (462 hits)
- Mode d'emploi d'un site utilisant Twiki (1597 hits)
Dépêche modérée par
Dépêche éditée par
Créé il y a près de dix ans par Peter Thoeny, TWiki est distribué sous licence GPL. Techniquement, il est écrit en Perl et ne requière pas de base de données, les pages et les documents attachés étant versionnés à l'aide de RCS ; certains sites l'utilisant comptent plusieurs dizaines de milliers de pages.
![[en]](../../../images/en.png)
twiki.org (1897 hits)-
Greffons et autres extensions (462 hits)
![[fr]](../../../images/fr.png)
Mode d'emploi d'un site utilisant Twiki (1597 hits)
> Lire la dépêche (23 commentaires, moyenne: 2,2).
Twiki apporte aussi des moyens originaux de structurer l'information en permettant, par exemple, la création d'espaces de travail distincts ou l'association de formulaires aux pages. À l'image d'un tableur, la gamme des usagers débute au simple lecteur pour arriver au développeur d'applications métier. Au moyen des nombreuses directives et variables internes disponibles, les usagers avertis peuvent construire de véritables applications incorporées aux pages.
Près de 200 greffons ont été développés afin de satisfaire aux besoins les plus divers, de l'indispensable à l'exotique. Un certain nombre sont pré-installés comme les modules « commentaires », « feuille de calcul », « éditeur de table », « notification par courrier électronique », « diaporama », etc.
Bien que les développeurs considèrent comme mineure la présente version, celle-ci comporte bien sûr son lot de corrections de bugs et de nombreuses améliorations, dont le nouvel éditeur WYSIWYG, des requêtes de type SQL pour la directive de recherche, de nouvelles traductions et un nettoyage de l'interface, une procédure d'installation simplifiée et une meilleure gestion des greffons.
TWiki est utilisé dans un cadre professionnel par des structures importantes comme British Telecom, le CERN, Google, Michelin, Motorola, Nokia, SAP, Sun, Yahoo, etc. et beaucoup d'autres plus modestes, souvent pour des usages internes.
[+] Nouvelles technologies
Perl et RCS ? Ca donne envie..
Bon et loyaux services
Je suis Directeur Technique, cela fait 4 ans que j'ai mis en place Twiki dans mon entreprise.
J'en avais testé des dizaines auparavant mais, bien qu'imparfait, lui seul me satisfaisant en terme de fonctionnalités. Le système de "Formulaire", de versionning, de pièce jointes, de notification sont épatantes de simplicité et de souplesse.
Dans mon entreprise il est devenu un des logiciels les plus utilisés. On peut même dire qu'il est critique pour l'entreprise.
Pour son implémentation, j'avais bien préparé mon coup ; je l'ai "alimenté" tout seul pendant un an avant de l'ouvrir officiellement à mes collègues. Succès immédiat : le contenu est toujours plus fort que le contenant.
Le système de markup n'est pas évident pour les non-informaticiens. C'est ma seule critique mais elle est de taille. Je participe à de nombreux projets avec des "cols-blancs" et je n'ai jamais songer à présenter twiki comme outil de travail collaboratif entre nous. Et c'est bien dommage quand on sait ce que cela peut apporter. La seule alternative ce sont des Ged et c'est tellement lourd!
J'ai bien testé et je continue à tester d'autres wiki, mais rien ne vaut twiki...
Le problème principal pour la généralisation de son utilisation était l'absence de Wysiwyg. Je dis bien "était" car dans la nouvelle version on y est presque. Je l'utilise depuis quelques mois, il reste quelques petits bugs qui m'oblige parfois encore à passer par le mode "markup". Ce n'est donc encore assez abouti pour mes "cols-blancs" habitué à travailler avec Word et Excell.
Le deuxième problème est le système de création de page. Il est suffisant pour moi mais déroutant pour un non-informaticien car trop éloigné du système d'arborescence de fichiers qu'il utilise habituellement pour ranger ses documents.
Le système de nommage des topics de twikiest aussi un frein.
Les macros de recherche ont bien évoluée dans la dernière version et se rapproche de SQL, cela va faire gagner du temps. L'ancien système n'était pas toujours évident.
En résumé, pour mes propres besoins et ceux de mes collègues informations je suis très satisfait ; pour le reste, je suis optimiste car le projet avance à bonne cadence. Encore un petit effort Twiki deviendra un outils parfait. Je remercie en tout cas les développeurs de ce logiciel si malléable, qui facilite tant le travail quotidien et qui correspond presque à mon schéma de pensée. Un grand outil de productivité! Je me devais de le le dire.
-
[^]Re: Bon et loyaux services
Posté par Nicolas (page perso, ) le 10/02/2008 à 11:39. (lien). Évalué à 2.Et est-ce vraiment gênant que TWiki n'utilise pas de base de données ? J'avoue que ce point me dérange un peu, mais j'ai vraiment envie de tester cet outil...
-
[^]Re: Bon et loyaux services
Posté par Thierry Pasquier (page perso, ) le 10/02/2008 à 12:31. (lien). Évalué à 3.Pour moi ce n'est pas un inconvénient du tout. Les pages sont stockées dans des fichiers texte auxquels sont intégrés les balises TML (TWiki Markup Language), variables et directives propres à TWiki ou aux greffons. Pour la visualisation ou l'édition WYSIWYG elles sont générées à la volée en HTML. Les documents attachés aux pages sont évidemment eux aussi stockés comme fichiers dans une arborescence parallèle à celle des espaces de travail et des pages. Le tout est versionné - comme du code source - par RCS. Je pense que la force de TWiki réside dans la robustesse de son architecture.
L'objectif de cet outil n'est pas la publication web comme médiawiki où les lecteurs sont bien plus nombreux que les rédacteurs. Son orientation est le travail collaboratif :
une communauté d'usagers lecteurs & rédacteurs
de nombreux espaces de travail,
des pages dont les contenus peuvent êtres purement textuels ou comporter des formulaires ou des traitement de données assez simple à mettre en oeuvre
la possibilité de gérer l'information sur l'information (des métadonnées à la carte)
des compétences évolutives dans l'utilisation des fonctionnalités avancées par les usagers eux-mêmes
une gestion partagée des droits
etc.
L'utilisation d'un wiki en lieu place d'un groupware ou en remplacement des interminables échanges de mails et des pièce jointes est assez déroutante, et demande à remettre à plat les façons de travailler. C'est la cas, quel que soit le moteur de wiki utilisé.
-
[^]Re: Bon et loyaux services
Posté par Alain () le 10/02/2008 à 13:06. (lien). Évalué à 1.Pas du tout gênant. La dernière version de Twiki offre un outil de requête proche de SQL. Je pense par ailleurs qu'une bonne partie de la puissance TWiki, de cette malléabilité, est dû au fait que TWiki bénéficie de toute la puissance du Perl dans le traitement de fichiers ; c'eût-été bien difficile à obtenir avec une base de données.
-
[^]Re: Bon et loyaux services
Posté par Jean-Baptiste Mayer () le 10/02/2008 à 15:24. (lien). Évalué à 1.Je dirais, au contraire!
Tu as juste besoin d'un serveur qui peut faire tourner des CGI perl. Pas de base de données, même pas besoin de RCS car une implémentation en perl est fournie avec (même si le binaire est un poil plus rapide).
Pour ce qui est recherche en texte c'est juste une affaire de grep - ce à quoi perl est assez efficace :)
Dans la série 'témoignage d'utilisateurs' j'ai mis en place un TWiki pour mon équipe au boulot.
Parmi les gros avantages, on y a vu:
-> Moteur en perl, donc intégrable avec tous nos applicatifs métier (qu'on a aussi écrit en perl)
-> Une API très propre, qui facilite d'autant l'intégration (certains batches vont chercher leurs paramètres dans le wiki, comme les mailing lists)
-> Les flux RSS et les mails de notification
-> Les espaces séparés pour chaque groupe, avec ses admins, sa propre identité visuelle
-> Les fichiers attachés
-> Et les plugins de gestion de projet.-
[^]Re: Bon et loyaux services
Posté par Thierry Pasquier (page perso, ) le 10/02/2008 à 17:19. (lien). Évalué à 1.En fait, il me semble que la difficulté principale pour celui ou celle qui installe un TWiki pour le travail collaboratif est de conserver la simplicité des principes du wiki malgré ou avec la puissance des fonctions qui sont disponibles.
Quels plugins de gestion de projet utilisez vous ?
Nous (pour un centre de culture scientifique et technique) utilisons TWiki comme moyens de faire coopérer les professionnels, les bénévoles et les partenaires des différents projets que nous menons ou auxquels nous participons. Au départ (2005), nous avons eu tendance à construire une espèce d'usine à gaz avec de nombreux formulaires, plugins, skins, etc.. Très rapidement, nous sommes revenus a l'essentiel : TWiki de base avec quelques plugins et un formulaire simplifié à l'extrême.
-
[^]"Juste besoin"
Posté par M Nicolas (page perso, ) le 10/02/2008 à 18:15. (lien). Évalué à 1.De nos jours, il est plus facile de trouver un hébergement avec BDD (mysql ou postresql) que de trouver un hébergement Perl. Je doute qu'on puisse trouver ce dernier sans l'autre.
Tout ça pour dire que ça n'est vraiment pas un point positif, même si ça n'est pas non plus nécessairement un inconvénient. Avec des outils comme php(pg|my)admin, une BDD est même plus facile à gérer pour un admin débutant qu'un tas de fichiers (permission, propriété, groupes ...)-
[^]Re: "Juste besoin"
Posté par fridim () le 10/02/2008 à 19:14. (lien). Évalué à 3.Lorsqu'on a une application telle mediawiki ou autre, cette dernière fait une grosse partie du travail pour nous, donc pas besoin (en dehors des backups ou des cas rares de corruptions) de mettre le nez dans la base de données. A partir de là, une base de données ou des fichiers avec système de révisions, ça change pas grand chose.
Je pense même que l'installation est plus simple sans base de données. D'ailleurs Twiki n'est pas le seul à penser ça : moinmoin, oddmuse, usemod, etc, utilisent aussi une arborescence de fichiers.
-
[^]Re: "Juste besoin"
-
-
-
Ca a l'air bien TWiki ... sauf que ça ne supporte pas (bien) UTF-8
En 2008, ça la fout un peu mal. Surtout que Perl supporte UTF-8 parfaitement, depuis des années, à la différence de Python.
-
[^]Re: Ca a l'air bien TWiki ... sauf que ça ne supporte pas (bien) UTF-8
Posté par Jean-Yves LENHOF (page perso, ) le 10/02/2008 à 20:29. (lien). Évalué à 4.Tu peux argumenter ?
Parce que suite à la lecture de cette news, j'ai jeté un oeil sur le site wikimatrix.org et il dise que TWiKi supporte Unicode...
Pour info, jusqu'à aujourd'hui j'installe du moinmoin lorsque je veux un WiKi, mais j'ai quelques bugs avec l'éditeur graphique (pas bien méchant)-
[^]Re: Ca a l'air bien TWiki ... sauf que ça ne supporte pas (bien) UTF-8
Posté par M Nicolas (page perso, ) le 11/02/2008 à 19:15. (lien). Évalué à 3.« Unicode and UTF-8 support were out of scope for the initial work in late 2002, because the whole area of Unicode is much more complex. UTF-8 support has been investigated, and implemented for URLs in EncodeURLsWithUTF8, but full UTF-8 support is currently on hold because of lack of time, some technical difficulties (see ProposedUTF8SupportForI18N), and the greater importance of UserInterfaceInternationalisation. However, East Asian sites successfully run TWiki with UTF-8 for Japanese, Chinese, Korean, etc. »
http://twiki.org/cgi-bin/view/Codev.InternationalisationEnhancements
-
-
[^]Re: Ca a l'air bien TWiki ... sauf que ça ne supporte pas (bien) UTF-8
Posté par Laurent Pointal (page perso, ) le 11/02/2008 à 12:49. (lien). Évalué à 4.à la différence de Python.
Tu peux préciser ?-
[^]python et utf-8
Posté par M Nicolas (page perso, ) le 11/02/2008 à 19:13. (lien). Évalué à 1.Ca a peut-être changé très récemment (je crois que c'est prévu pour Python 3), mais la dernière fois que j'avais regardé, il y avait une syntaxe particulière pour initialiser une chaine utf-8.
-
[^]Re: python et utf-8
Posté par Laurent Pointal (page perso, ) le 11/02/2008 à 22:48. (lien). Évalué à 4.En Python, tu as les chaines "raw", et les chaîne "unicode".
Pour les chaînes unicode, elles sont stockées directement en représentation 2 ou 4 octets par caractère (ie. pas en utf8 ou autre).
Par contre, pour les exprimer dans le source, comme ceux-ci peuvent avoir différents encodages, tu indiques l'encodage au début du source, par exemple:
# -*- encoding: utf-8 -*-
Puis tu déclares les chaînes unicode avec unu"Ma chaîne"(noter le 'u' avant le premier quote). A la compilation en byte-code, Python sait ainsi comment interpréter la chaîne source et la stocker dans le bon format en unicode.
Ensuite, tu manipules naturellement les chaînes unicodes. Par contre, lorsque tu fais des entrées/sorties avec, il faut utiliser les méthodes encode/decode en indiquant l'encodage destination/source (il y a des wrappers, par exemple en utilisant codecs.open(), pour que les transformations soient faites de façon transparentes pour le programmeur).
Le préfixe "u" n'est quand même pas un trop grosse contrainte et a permis de garder la compatibilité avec les codes existants... mais en effet, si tu veux que toutes les chaînes soient Unicode par défaut, il faudra attendre Python 3 (si j'ai bien suivi, les données raw ne seront alors que des buffers d'octets, sans les méthodes de manipulation des chaînes).
Après, le support d'Unicode dans telle ou telle librairie, c'est autre chose. Dans certains cas ça peut demander du boulot ou devenir un casse tête (du genre perte de l'encodage à un moment donné du processus).
-
-
mieux que dokuwiki ?
Je ne connais pas du tout TWiki, est-ce que quelqu'un qui connait également dokuwiki pourrait me dire si TWiki est mieux et si oui pourquoi ?
J'ai adopté dokuwiki pour son stockage sur fichier et sa facilité d'habillage, et parceque ça marche. Mais après, si on me donne encore mieux …
-
[^]Re: mieux que dokuwiki ?
Posté par Thierry Pasquier (page perso, ) le 11/02/2008 à 13:18. (lien). Évalué à 2.Pour ce que j'en sais, Dokuwiki est extrêmement simple à mettre en place sans doute beaucoup plus que TWiki. Si c'est pour faire du texte simplement les deux se valent sans problème.
Comme il a été indiqué plus haut, ce qui fait la spécificité de TWiki ce sont les divers moyens de structuration de l'information (recherche, formulaire, versionning des contenus et des documents attachés, etc.) qu'il propose grâce à la richesse et à la puissance de son API au sens large (fonctions perl, directives, variables, etc.) ainsi qu'à ses plugins (environ 200)
-
[^]Re: mieux que dokuwiki ?
Posté par Yann Cochard (page perso, ) le 11/02/2008 à 13:32. (lien). Évalué à 3.Salut,
J'utilise aussi Dokuwiki, que je trouve très bien fait.
Il vient avec plus de 300 plugins, dont les backend d'authentification à d'autres produits (par exemple utiliser les utilisateurs et groupes d'un forum comme Phorum ou PunBB).
J'ai rédigé plusieurs plugins, c'est très simple et facilite grandement les mises à jour de Dokuwiki.
Je ne connais pas Twiki, mais en complément de l'autre réponse à ta question, il faut aussi noter :
Dokuwiki = PHP
Twiki = Perl
A choisir aussi en fonction de ce qui est disponible sur le serveur, et de sa préférence personnelle pour l'un ou l'autre langage.
-
[^]Re: mieux que dokuwiki ?
Posté par Eric Guirbal (Jabber id, ) le 11/02/2008 à 14:48. (lien). Évalué à 3.Mieux ? Une Ferrari est préférable à une Smart pour frimer, par contre, pour aller faire du shopping en ville, c'est moins sûr. Il ne fait aucun doute que Twiki est fonctionnellement bien plus riche que Dokuwiki, cependant le choix se fera en fonction de l'usage que vous désirez en faire, du profil de ses futurs utilisateurs et dans une moindre mesure des compétences de l'administrateur.
Twiki est plus difficile à installer, configurer et administrer que Dokuwiki, cependant pour un administrateur ou un «wiki champion» motivé cela ne devrait pas constituer un véritable obstacle. Par contre, il faut bien prendre en compte le profil des utilisateurs. Pour citer mon cas personnel, je travaille pour un client dont les salariées n'ont jamais reçues de formation sur l'usage de l'outil informatique et sont pour la plupart peu à l'aise. Au passage, une petite anecdote: il y a quelque jours j'ai surpris une secrétaire additionnant laborieusement à l'aide de sa calculatrice tous les nombres d'une colonne d'une feuille de calcul Excel :-). Cela fait plus d'un an que j'utilise Dokuwiki pour documenter mon travail. Depuis 9 mois, dans le plus grand secret ou presque, j'y ajoute du contenu suceptible d'intéresser mes utilisatrices. Je pense le présenter dans quelques semaines. J'ai choisi Dokuwiki. Sa simplicité m'a immédiatement séduit. Il est remarquable sur ce point. Pourtant j'aurais aimé pouvoir installer Twiki. La richesse et la qualité de ses extensions, et la possibilité d'y mettre du contenu structuré aurait été bien utile. Mais sa plus grande compléxité serait certainement un frein à son adoption, alors qu'avec Dokuwiki mes chances sont bien plus grandes. Souvent «The less is more», n'est-ce pas ?
-
[^]Re: mieux que dokuwiki ?
Posté par Alain () le 11/02/2008 à 16:00. (lien). Évalué à 1.Il manque à Docuwiki un éditeur graphique en ligne (TWikiDraw). Ce plugin à lui tout seul peut faire tourner la balance en faveur de TWiki.
La fonction Wysiwyg de la dernière version de TWiki surpasse ce que l'on peut trouver sur docuwiki ou mediawiki. C'est un point essentiel pour l'adaption d'un wiki par une communauté non informaticienne.-
[^]Re: mieux que dokuwiki ?
Posté par Maillequeule () le 11/02/2008 à 17:55. (lien). Évalué à 2.Tu veux dire http://wiki.splitbrain.org/plugin:draw ?
(Je l'utilise depuis 2 ans, et ça fonctionne très bien)
Coté édition, l'intégration de FCKeditor dans dokuwiki est efficace même si c'est différent du mode WYSIWYG de TWiki : http://wiki.splitbrain.org/plugin:fckw
Mais à nouveau, à chacun de se faire son avis en fonction de ses besoins.
-
-
-
[^]Re: mieux que dokuwiki ?
Posté par Alain () le 11/02/2008 à 16:11. (lien). Évalué à 1.je rajoute que docuwiki est parfait pour mettre une documentation en ligne. TWiki est un outil de travail pour tous les jours. Il est parfait pour gèrér des bases de connaissance et les réactualiser à plusieurs au fil de l'eau, il est aussi un des seuls wiki à gérer le versionning des pièces jointes.
Alors que je vous écris j'ai à côté de moi affiché sur mon écran de gauche un schéma de réseau fait avec le pluginTWikiDraw et je me dis en le voyant : qu'est-ce que c'est bien de ne pas devoir passer par un programme externe comme Visio ou Dia! Avec ce plugin java, un navigateur suffit pour tracer un schéma
Cette page a été générée par Templeet en 0.0986s (dont 0.012 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.