Présentation suivante ce mercredi matin :
Next generation Wikis : Mixing Content-Oriented Applications with Wikis
by Vincent Massol
Vincent Massol, de XWiki SAS, mais aussi l’un des CastCodeurs, nous propose ce matin une présentation des nouvelles fonctionnalités de l’application XWiki 2.0. Sa présentation commence par un rappel du concept de Wiki, qu’il appelle Wiki 1.0. Ensuite, l’approche qu’il va développer concernant XWiki 2.0, sera de nous montrer qu’il devient facile de créer des mini-applications hébergées dans un wiki. Il cite quelques exemples d’applications qui seraient faciles à développer avec la future version de XWiki :
– Gestion de projet
– Système de demande de congés
– Notes de réunion
– Factures ou notes de frais
– Annuaire de contacts
– Notes de frais
Bref l’idée est de prendre en compte un fait : le Wiki est maintenant bien implanté dans l’entreprise, l’étape suivante est d’ouvrir le moteur afin d’offrir aux utilisateurs des applications, des formulaires, en conservant la philosophie du Wiki. En effet, tout ce qui va suivre sera codé directement dans l’interface de XWiki.
Vincent Massol montre quelques exemples de sites comme « France 2025 » construit autour de XWiki. La frontière entre un portail et un wiki est très fine. Comme il l’explique, les Wikis 1.0 présentent des données peu structurées. Les blogs ajoutent une journalisation, ce qui structure les données. Les portails d’entreprises ensuite ont structuré l’information par domaine. Ce qu’il va présenter est donc la dernière étape, la structuration des données personnalisés, la possibilité de développer son application. Un outil de développement léger en quelques sortes.
L’idée des Wikis 2.0 est donc d’être l’Excel du Web. Un besoin simple ? Plutôt que de développer un gros projet, il explique que le moteur de Wiki doit fournir quelques services simples pour créer ses formulaires, et donc ajouter aux pages une application avec un coût de développement réduit.
Il débute la démonstration. L’objet de la démo sera de créer une petite application de demande de congés. Pour comprendre la suite, il présente 2 concepts de XWiki. Une classe est une page, un template. Un Object est une instance de cette classe. Tout d’abord il commence par créer les méta-données associées à la page. Pour cela, un script dans une textarea permet de déclarer les attributs. La syntaxe utilisée est Velocity. Le support de Groovy est aussi prévu déjà présent, le support de Jython et de JRub est en cours (cf commentaire ci-dessous).
Cette étape fait un petit peu peur au premier coup d’oeil, on pense à Microsoft Sharepoint qui permet de créer des applications. Si j’avais un bémol je dirai que j’ai eu un peu peur en regardant le code. Mais cependant la syntaxe est simple, et je pense qu’une fois l’outil maitrisé, cela ne pose pas de soucis. De toutes les façons, ce qui suit est plutôt destiné à des administrateurs de portails, mais je n’ai pas assez de connaissances sur ce sujet.
L’intérêt évident d’éditer en direct, c’est que le résultat est tout de suite disponible. Et en effet, je trouve le concept vraiment intéressant. Donc un template Velocity permet de décrire sa demande de congés, ce template est attaché à une page, il est temps ensuite de créer l’interface de saisie.
Dans un deuxième temps, Vincent crée une ClassSheet, une feuille de style pour habiller la class qu’il a créé. La demande de congés est constitué de champs simples, de champs de type Date, et d’une liste déroulante d’utilisateurs, automatiquement peuplées par XWiki.
Une fois la feuille de style prête, nous voyons alors la page de saisie s’afficher. Le tout en 10 minutes à peine. Le reste est bien de la syntaxe Wiki, vous pouvez alors intégrer des images, des feuilles de style, les méta-données sont stockées dans la version de la page (??).
Un langage de requêtage, le xwql, permet de créer des éléments dynamiques, une liste des personnes ayant effectué une demande de congés.
Vincent Massol explique ensuite que la version 2.0 de XWiki est polyglotte, elle supporte un nombre assez important de syntaxe Wiki. D’ailleurs comme il le fait remarquer, il est intéressant de remarquer que certains Wikis proposent par défaut un éditeur type Word, là où au départ le wiki a été créé pour qu’un langage simple de balisage soit utilisé !
La version 2.0 supportte aussi le « Roundtrip between XHTML and Wiki Syntax » et ce moteur est disponible comme librairie à part.
Parmi les questions posées en fin de présentation, quelqu’un demande si un moteur de Workflow (pour valider la demande de vacances) serait prévu ? Au delà de la question, on comprend que les Wikis 2.0 se rapprochent de la frontière des applications d’entreprise. Est-ce que les utilisateurs accepteront quelques limitations ? Est-il envisageable de développer plus de fonctionnalités tout en gardant la simplicité et la puissance d’un Wiki ?
Peut-être qu’un slide pour présenter les fonctionnalités des autres acteurs nous aurait aidé pour comprendre l’avantage d’utiliser XWiki. Bonne présentation qui montre en tous les cas que les Wikis sont devenus des outils incontournables dans les entreprises.
0 no like
Merci pour le post! 🙂
Le support de Groovy existe bel et bien depuis plusieurs années deja. Tu vas te faire massacrer par Guillaume si tu corriges pas vite 🙂
Ceux qui sont en cours d’ajout sont les supports Jython et JRuby… mais chut…. faut pas le dire a Guillaume, il aime pas 😉
-Vincent
« Peut-être qu’un slide pour présenter les fonctionnalités des autres acteurs nous aurait aidé pour comprendre l’avantage d’utiliser XWiki. »
Bonne idee, moins facile a realiser sans se faire agresser, mais que je garde en tete pour une prochaine presentation 🙂
Article corrigé.
Pour le deuxième point, j’imagine un slide « Main Actors/Competitors » afin de donner une idée du marché. J’ai vu cela à la présentation Portlet 2.0 de Thomas Heute.
Oui, dommage qu’il n’y ait pas un ou des transparents pour avoir un panorama des compétiteurs et comment un wiki, et particulièrement xwiki, se positionne.
Mais c’est vrai qu’écrire ces transparents est délicat car le positionnement des uns des autres dépend de pas mal de paramètres et est mouvant :
– cible visé : développeur confirmé ? occasionnel ? utilisateur confirme ? occasionnel ?
– type d’appli visé
– contexte d’utilisation des applis développées
– capacité d’intégration avec d’autres applis
– évolution
– etc.
Mais c’est vrai que c’est dommage que de tels transparents ne soient pas dispos 😉