Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Développement

GLPI : Lieux et Prises réseaux

Remi Collet

Une refonte importante de la gestion des "intitulés" est en cours, un premier aperçu avec la gestion des Lieux et des Prises réseaux.

Version cible 0.80. Comme pour les autres objets de GLPI, on pourra désormais utiliser le moteur de recherche standard. La fiche d'un lieu s'enrichit : On notera, sur la fil d'Ariane l'apparition d'un 4ème niveau (très attendu). Les lieux peuvent désormais être partagés entre plusieurs entités. De nouveaux champs documentaires peuvent faire... Lire GLPI : Lieux et Prises réseaux

GLPI Tâches planifiées

Remi Collet

Une des sources récurrentes de demandes des utilisateurs et la possibilité de personnaliser les tâches réalisées de manières automatiques par GLPI. C'est maintenant posible.

Désormais une option du menu Configuration permet d'accéder à la personnalisation et à la supervision des tâches automatiques. Pour chaque tâche, il est possible de choisir : La fréquence d'exécution Le mode d'exécution : Interne (déclenché par la navigation des utilisateurs, par défaut lors de l'installation standard) ou Externe (plus robuste... Lire GLPI Tâches planifiées

GLPI Catégorie des tickets

Remi Collet

Alors que la version GLPI 0.72 est stabilisée et n'est plus modifiée en dehors de quelques corrections mineures, la version développement, qui devrait sortir sous le numéro 0.80, est en pleine activité.

Je vais donc essayer de poster régulièrement quelques copies d'écran pour vous permettre de découvrir les nouveautés et vous permettre d'y réagir.

Jusqu'à présent, les catégories de ticket étaient un simple "intitulé" comme plusieurs autres. Désormais, c'est un objet plus complexe, géré depuis le moteur de recherche habituel : Une catégorie peut être définie dans une entité, ce qui permettra à chaque administrateur "local" de personnaliser l'activité de son centre de support. Une... Lire GLPI Catégorie des tickets

Projets en cours

Fabien Nicoleau

Ces derniers temps mon blog est plutôt inactif ... Pourtant "l'effet été" n'y est pour rien, et ce n'est pas non plus la cause d'une quelconque démotivation. Après la dernière release de trustyRC, j'ai décidé de faire une pause car la prochaine version devrait être majeure et contenir de nombreux changements radicaux. J'ai profité de ce temps pour retoucher un peu à Java, et découvrir un tas de nouvelles choses pour moi (ant et gcj notamment). Deux intérêt : me replonger dans ce langage que j'apprécie, et pouvoir poser plein de questions à Pikachu_2014 pour profiter de son légendaire savoir ! Je n'ai rien fait d'original, j'ai tout simplement recommencé une version de trustyRC en java (non, je ne bloque pas sur les bots IRC, c'est juste que ça intègre différentes notions et que c'est donc assez formateur). Vu que la chose me plait bien, je continue pour le moment, je verrai bien où ca me mène. La version C++ n'est pas pour autant arrêtée. Selon l'état d'avancement de la version Java le jour ou je déciderai de reprendre activement le développement de trustyRC, je verrai quelle version je garde, ou si je garde les deux. En parallèle je pense me lancer dans un petit jeu de bataille navale en réseau, intégrant un chat, etc ... Pour cela encore l'éternelle question : java ou C++ (avec Qt) ? Je verrais bien, je pourrais bien me lancer dans le développement de bibliothèques dynamiques gérant le jeu, et ainsi les réutiliser pour développer des GUI dans les deux langages. Enfin, ces dernières semaines, j'ai réalisé deux articles pour le prochain numéro de Linux Identity, dédié à CentOS 5.3 (j'ai d'ailleurs vu qu'un dino y participe aussi). Voilà, non je ne glande pas, non je ne suis pas mort, je n'ai juste rien de concret à présenter pour le moment !

PS : oui je sais, l'art d'écrire un billet quand on à rien à dire ... :D


Fabien (eponyme)

Au nom du libre je te baptise : Photo Imp !

Aurélien Bompard

Mon afficheur web de photos, que j’avais présenté précédemment, a maintenant un nouveau nom : Photo Imp !

J’en ai profité pour ouvrir un espace sur Gitorious, pour que le développement soit plus accessible et plus visible.

En ce moment, je suis en train de porter la bibliothèque javascript type “Lightbox” qui permettait d’afficher les photos depuis ShadowBox vers PrettyPhoto, puisque ShadowBox n’est plus libre dans les versions récentes (utilisation commerciale interdite). C’est un peu plus long que prévu, mais je vois le bout.

Pour en revenir au nom, il a été trouvé par Peuf, et c’est une référence à une créature du monde de Terry Pratchett : le “photo imp” est un petit démon dans une boîte noire avec une petite fenêtre, appelée Iconographe. Quand on ouvre la fenêtre, le “photo imp” peint très rapidement ce qu’il voit sur une toile. L’appareil dispose aussi d’une salamandre pour éclairer rapidement l’objet à dessiner. C’est évidemment une transposition de l’appareil photo, très très bien vu de la part de Peuf, merci beaucoup. Pour les détails : voyez la page Wikipedia.

Je publierai une nouvelle version quand j’aurais porté le code sur PrettyPhoto. Si vous utilisez Photo Imp, dites-le moi, ça m’intéresse !

Export des billets Dotclear en ODT

Aurélien Bompard

Comme dirait la demoiselle : « Oops, I did it again » (oui, je sais, je ne suis pas fier). Il y a quelque temps (deux ans en fait) que je m’intéresse au format OpenDocument, utilisé principalement par OpenOffice. Je vous annonce donc solannellement en ce jour béni de votre divinité préférée le résultat de mon labeur acharné : un plugin d’export des billets de Dotclear en ODT. Oui, tout ça pour ça.

old book stara ksiazka
Creative Commonsold book stara ksiazka” par v.max1978

Le format ODT

Depuis les débuts de l’informatique grand public, le traitement de texte est omniprésent, et a rapidement remplacé la machine à écrire. Au début des années 90, plusieurs logiciels de bureautique se faisaient concurrence, Microsoft Word bien sûr, mais aussi Corel WordPerfect, AppleWorks, etc.

Les éditeurs de logiciel on vite compris que leur logiciel servait avant tout à traiter des données, et que pour battre la concurrence il fallait être capable de lire leur format tout en s’assurant qu’ils ne pourraient pas lire le sien. Il s’en est suivi une guerre des format, accentuée par l’explosion des communications et des transferts de fichiers, dont le vainqueur a été Microsoft et le grand perdant l’utilisateur final. Même si il est plus “simple” d’un premier abord pour l’utilisateur final de ne pas se demander si son correspondant utilise le même logiciel, en fait cette simplicité revient à donner les clés de ses données à la société éditrice. Si elle décide de changer son format, comme elle l’a déjà fait plusieurs fois, elle force les utilisateurs à une mise à jour coûteuse. C’est plus facile de vivre dans une dictature, on a pas à choisir pour qui voter.

Il a fallu attendre l’avènement de StarOffice, une suite bureautique réalisée par une société allemande du nom de StarDivision, puis rachetée par Sun, pour voir les prémisses d’un format de bureautique standardisé. StarOffice a ensuite évolué en OpenOffice, dont le format était ouvert (c’est à dire documenté), et qui a été soumis à normalisation. L’ISO a mis son tampon sur une version légèrement modifiée du format, appelé OpenDocument, qu’OpenOffice à utilisé à partir de sa version 2.0.

Enfin, enfin, nous avons un format de bureautique standard, sur lequel tout le monde s’est mis d’accord, et qui répond à nos besoins. Tous ? Non, pas Microsoft bien sûr, qui n’a aucun intérêt à mettre en péril son monopole et l’emprise qu’il a sur ses utilisateurs en adoptant un format de fichier ouvert…

Mais la révolution est en marche, et Microsoft va avoir beaucoup de mal à l’arrêter. Je pense même sincèrement qu’il ne pourra tout au plus que la retarder légèrement. L’OpenDocument voit son adoption progresser très régulièrement, c’est maintenant une question de quelques années.

Et moi dans tout ça

Pour des besoins professionnels, j’ai développé depuis mi-2007 un plugin pour Dokuwiki permettant d’exporter des pages au format ODT. Je me suis donc intéressé à la syntaxe de ce format, et j’ai découvert avec plaisir qu’il est très clair, assez proche de HTML/CSS (pas la peine de réinventer ce qui marche déjà et que tout le monde connaît), et très bien pensé.

Le plugin achevé (et, avouons-le, légèrement grisé par la réussite), je me suis dit que je devais absolument faire des exports ODT sur d’autres logiciels pour populariser le format. Finalement, l’eau à coulé sous les ponts, j’ai été pris par d’autres choses, j’ai vaguement commencé à participer à l’export ODT sous SPIP, mais je ne me suis jamais vraiment impliqué.

Depuis ma migration sous Dotclear, j’avais en tête de réaliser un export ODT. C’est maintenant chose faite.

A Rainbow Of Books
Creative CommonsA Rainbow Of Books” par Dawn Endico

Comment ça marche

Pour ne pas recoder ce qui existe déjà, je me suis appuyé sur odtPHP, un module d’accès aux fichiers ODT depuis PHP (développé par une boîte française au passage). Mon objectif était de permettre à l’utilisateur de Dotclear de faire un fichier ODT qui contiendrait potientiellement les mêmes tags que ceux qu’il a utilisé pour faire son thème. De cette façon, on reste au maximum dans l’esprit Dotclear, et pas la peine d’apprentre un nouveau langage de templates. L’infrastructure de Dotclear n’est pas aussi souple que celle de Dokuwiki sur cet aspect-là, ça a donc été un peu plus compliqué de brancher le générateur ODT sur le moteur de templates de Dotclear.

Une fois ce branchement réalisé, j’avais donc du HTML dans mon document ODT. Il me restait alors à le convertir en ODT XML. Il n’existe pas à ce jour de convertisseur complet de HTML vers ODT, la fondation OpenDocument Fellowship a même proposé un prix de 11 500 dollars à qui le réaliserait. Mais ça tombe bien, je n’avais pas besoin de quelquechose de compliqué qui irait re-créer les styles présents dans les feuilles de style CSS, j’avais juste besoin de convertir quelques tags.

Je me suis donc appuyé pour cela sur le moteur de conversion DocBook vers ODT de Consultia, en remplaçant les tags Docbook par le HTML auquel je m’attends. Ma conversion est donc entièrement basée sur des feuilles de traduction XSL ! Cool, non ?

Enfin, j’ai paufiné le plugin pour le faire respecter les conventions Dotclear sur les plugins, lui ajouter un tag pour les thèmes graphiques, et un widget pour proposer facilement un export sur toutes les pages.

Conclusion

Mon plugin peut donc convertir tout post en ODT, mais aussi les pages, ainsi que la page d’acceuil. Par défaut, les documents générés sont très simples, mais je propose aussi un modèle d’export pour la page d’accueil permettant d’exporter tous les articles du blog, avec tout leur contenu. Une conversion du blog entier en ODT, en somme.

Le code est sous licence AGPLv3, comme toujours, et je vous attache à ce billet un Zip tout prêt à être déployé dans votre blog Dotclear.

Si ça vous intéresse, essayez-le et remontez-moi les bugs (ou les idées d’amélioration). Je ferai de mon mieux pour le maintenir et le faire évoluer. Comme vous avez pu comprendre, c’est un sujet qui me tient à coeur…

AGPL

Fils de discussion dans Dotclear

Aurélien Bompard

Comme il ne faut pas s’arrêter en si bon chemin (et que ma boîte fait le pont de l’ascension…), je me suis attelé à un nouveau plugin Dotclear. Il s’agit d’une fonctionnalité que j’aimais bien dans SPIP : la possibilité de voir les commentaires par fils de discussion.

Bundles of cotton thread
Creative Commons Bundles of cotton thread par Unhindered by Talent

L’avantage des fils de discussion

En effet, quand un article commence à avoir beaucoup de commentaires (par exemple celui-là), il devient difficile de savoir qui répond à qui. Une convention est née : préfixer sa réponse par le signe “@” suivi du nom de la personne à qui on veut répondre. Il existe même un plugin Dotclear appelé @Reply pour pré-remplir la fenêtre d’ajout de commentaire avec ce préfixe, simplement en cliquant sur un bouton.

C’est très bien, mais ça n’aide pas beaucoup à la visualisation. Le mieux serait, selon moi bien sûr, de placer les réponses sous les commentaires auxquels elle répondent, en les indentant de quelques pixels.

La méthode

Malheureusement, comme la réponse à un commentaire n’est pas prévue par le moteur de Dotclear, on ne peut pas trouver dans la base de données la référence au commentaire auquel répond un autre commentaire. Pour recréer les fils de discussion, j’ai donc décidé de m’appuyer sur la convention “@”, et notamment sur le lien qui est généré par le plugin @Reply. Cette méthode est la meilleure que j’ai trouvée, mais elle a tout de même deux inconvénients :

  • le commentaire ne se retrouvera pas au bon endroit dans les fils de discussion si le visiteur n’utilise pas le bouton @Reply
  • on ne peut pas répondre à deux commentaires dans le même commentaire (mais ça je vois pas bien comment faire autrement…)

Donc ce n’est pas parfait, mais c’est déjà “suffisamment bien” pour moi.

La réalisation

Ce plugin fonctionne à 100% en javascript, à l’aide de jQuery. Le principe est simple : on ajoute un bouton pour activer la vue en fils de discussion, et en arrière-plan on prépare une liste des commentaires dans laquelle chaque élément a comme attribut supplémentaire le numéro du commentaire auquel il répond.

À l’activation de la vue par fils de discussion, on vide complètement la zone de commentaires, et on les réinsère les uns après les autres. Si un commentaire répond à un autre commentaire, il est inséré après celui-ci, et on lui ajoute une marge à gauche pour l’indenter.

Comme toujours, la complication est dans les détails :

  • quand on insère une réponse, il faut l’insérer après les autres réponses au commentaire.
  • il faut ajouter une marge de plus en plus grande au fur et à mesure des réponses, mais pas trop grande pour ne pas écraser le commentaire à droite

Enfin voilà, vu de chez moi, ça marche. J’avais peur que ce soit extrêmement lent, mais en testant sur un de mes articles qui a eu beaucoup de commentaires, je n’ai pas constaté de lenteur excessive.

Je n’ai qu’un bug à déplorer : l’indentation du commentaire fait perdre les deux angles arrondis de droite. C’est dû à l’image de fond utilisée pour simuler les bords arrondis, peut-être que si j’ai le courage je corrigerai ça.

Le code

Si vous voulez l’essayer chez vous, j’attache le code packagé à cet article. Le fichier Zip est prêt à installer, et contient toute la plomberie Dotclear qui va bien (interface d’administration, aide en ligne, traductions, etc). Le code est sous licence AGPL (qui est plus ou moins la GPL des applications web).

Je vais le laisser tourner ici quelques jours, voire semaines, avant de le proposer au “lab”. Comme toujours, si vous ou l’un de vos collaborateurs étaient pris ou tués, le Département d’État nierait avoir eu connaissance de vos agissements. Euh, non, remontez-moi les bugs, quoi. Bonne chance Jim.

AGPL

Commenter en anonyme sur Dotclear

Aurélien Bompard

Ceux qui utilisent Dotclear (comme moteur de blog, ou juste en tant que commentateur d’un billet) le savent déjà : pour pouvoir commenter, il faut fournir un nom et une adresse email. Le nom est affiché, l’adresse mail ne sert qu’à l’administrateur, et éventuellement pour vous envoyer un suivi par mail, mais même dans cette situation un visiteur peut avoir envie de commenter de manière anonyme.

Le principe

Avec les attaques récentes sur nos libertés informatiques, je pense qu’il est important de donner sa place à l’anonymisation. J’ai envie que chez moi, sur mon blog, on puisse commenter anonymement si on le veut. Et sans avoir à inventer un faux nom et une fausse adresse mail, mais tout simplement en cliquant une case “anonyme”.

J’ai donc réalisé un (deuxième[1]) plugin pour Dotclear qui ajoute une simple case à cocher dans la zone de commentaire, permettant de régler le nom et l’adresse à quelque chose de neutre, genre “Anonyme” (c’est configurable, mais c’est ça la valeur par défaut).

La technique

Techniquement, tout se fait à base de javascript, en utilisant jQuery. Le fonctionnement est relativement simple finalement, toute l’astuce est dans les détails. Donc à la base, on crée une boîte de dialogue dans la page (en utilisant les “behaviors” de Dotclear), et on ajoute dans l’en-tête de la page (par la même méthode) un appel à un fichier javascript, qui va associer une action au clic sur cette boîte.

Cette action commence par sauvegarder ce qui était inscrit avant dans les champs nom, email et site, puis ferme les champs du formulaire. Quand les champs se sont fermés, elle remplace les valeurs par celles que l’administrateur du blog aura choisies (par défaut: “Anonyme” et “anonymous@example.com”). Un nouveau clic sur la case “anonyme” restaure les valeurs.

Tout ça serait resté très simple sans le mode de prévisualisation. À cause de la prévisualisation, il faut détecter au chargement de la page si on ne serait pas dans ce mode et que l’utilisateur n’aurait pas déjà choisi d’être anonyme. Ça se fait assez bien en comparant les valeurs des champs aux valeurs décidées par l’administrateur. Si on est en mode prévisualisation et que les champs sont déjà ceux du commentaire anonyme, on re-coche la case et on referme les champs.

Voilà, le principe n’est pas très compliqué, il fallait juste le faire :)" class="smiley

Les sources

Ce plugin va être en test sur mon blog pendant quelques semaines avant que je l’ajoute au SVN du “lab” Dotclear, histoire d’être sûr que j’ai pas oublié des morceaux, donc n’hésitez surtout pas à me remonter les bugs, même anonymement ! ;-)" class="smiley

En attendant, pour ceux qui voudraient voir les sources et/ou le tester, j’attache à cet article un fichier zip tout prêt à déployer.

Notes

[1] Voir le premier.

Utiliser son blog Dotclear comme identifiant OpenID

Aurélien Bompard

OpenID est un standard ouvert qui permet de s’authentifier sur des sites web sans avoir à créer un nouveau mot de passe. C’est un système bien pratique que j’utilise depuis un certain temps, et de plus en plus de sites web l’acceptent comme méthode d’authentification.

Un identifiant OpenID ressemble à une URL, donc par exemple http://user.provider.com, ou plus simplement user.provider.com.

OpenID a une fonctionnalité très intéressante : la délégation. Cette fonctionnalité permet d’utiliser n’importe quelle adresse dont vous contrôllez le contenu, par exemple l’adresse de votre blog, comme identifiant OpenID. Le vrai travail d’authentification est alors “délégué” à un fournisseur réel.

Finalement, la délégation OpenID ressemble énormément aux “alias” mail : c’est une adresse de redirection qui n’est pas une vraie boîte aux lettres, mais à qui vous pouvez envoyer des mails qui seront transférés à votre vraie boîte aux lettres.

L’avantage est donc évident : vous pouvez vous créer un compte sur un fournisseur OpenID gratuit, par exemple myOpenID ou OpenID France, et lui déléguer l’authentification. Ainsi, si vous désirez changer de fournisseur, votre identifiant OpenID restera l’adresse de votre blog, donc il n’y aura rien à changer sur les sites que vous visitez. De la même façon que grâce à un “alias” mail, pas besoin de prévenir tout votre carnet d’adresses quand vous changez d’adresse mail.

Techniquement, pour mettre en place cette redirection, il faut ajouter des balises spécifiques dans la page d’accueil de votre blog. On peut obtenir ces balises auprès de son fournisseur OpenID final, et faire les changements dans le thème à la main, mais pour simplifier tout ça j’ai créé un plugin Dotclear qui ajoute ces balises tout seul. Il est disponible à l’adresse suivante :

C’est mon tout premier plugin Dotclear, donc même si j’ai suivi de près la documentation, il se peut que j’ai oublié des choses. En tout cas, comme on dit chez-moi-ça-marche.

Le plugin contient une liste de fournisseurs connus, en plus d’un champ libre. Si le votre n’est pas dans la liste, contactez-moi et je l’y ajouterai.

Et voilà, grâce à la délégation OpenID, vous ne serez jamais lié à votre fournisseur. Plus de raisons de s’en priver !

Après le blog, le Trac et après le Trac, le Twitter...

Guillaume Kulakowski

Après avoir changé le thème du blog, je me suis attaqué à celui du Trac que j'ai renommé en "Plateforme de développement" et passé sous le sous-domaine dev.llaumgui.com. En effet, je voulais une certaine cohérence entre le design du blog et celui de la plateforme de développement. J'ai donc entrepris de porter Emplode sous Trac, et là, force est d'avouer que le truc est assez déconcertant.

Le moteur de template de Trac est basé sur un système d'XSLT qui me fait comprendre la charge serveur d'un Trac ;-). En plus pour appliquer le nouveau thème, bien sûr, il faut redémarrer le serveur apache, normal quoi...

Bon, au final, ça surprend mais ça ne casse pas 3 pattes à un canard. Histoire d'aider ceux qui voudraient appréhender la customisation de Trac, je vous donne mon site.html commenté :

<html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:py="http://genshi.edgewall.org/"
     py:strip="">

  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*|comment()|text()')}
    <!-- Là, je rajoute ma CSS perso (dans htdocs) en plus des autres champs de head -->
    <link rel="stylesheet" type="text/css" href="${href.chrome('site/style.css')}" />
  </head>
<body py:match="body">
  <div id="page">
    <div id="top">
      <div class="wrapped">

        <!-- Login et préférences... -->
        ${navigation('metanav')}

        <!-- Formulaire de recherche... -->
        <form id="search" action="${href.search}" method="get">
          <div py:if="'SEARCH_VIEW' in perm">
            <label for="q">Search:</label>
            <input type="text" id="q" name="q" size="10" accesskey="f" value="Rechercher" />
          </div>
        </form>

        <!-- Là on va se servire dans trac.ini -->
        <h1><span><a href="${chrome.logo.link}">${project.name}</a></span></h1>
        <p id="blogdesc">${project.descr}</p>
      </div>
    </div>
    <div id="navigation">

      <!-- Le menu principale -->
      <div class="wrapped">
        <ul>
          <li py:for="idx, item in enumerate(chrome.nav['mainnav'])" class="${classes(first_last(idx, chrome.nav['mainnav']), active=item.active)}">
            ${item.label}
          </li>
        </ul>
        <br class="clear"/>
      </div>
    </div>

    <!-- Contenu -->
    <div id="inner">
      <div id="wrapper">
        ${select('*[@id="main"]|text()')}
      </div>
    </div>

    <!-- Pied de page -->
    <div id="footer" xml:lang="en">
      <div class="wrapped">
        <p class="left">
          Powered by <a href="${href.about()}"><strong>Trac ${trac.version}</strong></a> by <a href="http://www.edgewall.org/">Edgewall Software</a><br />
          Basé sur le thème Emplode par <a href="http://arcsin.se/">Arcsin</a>
        </p>
        <p class="right">${chrome.footer}</p>
      </div>
    </div>

  </div>
</body>
</html>

Maintenant il y a plus qu'à faire pareil sur le Trac de Fedora-Fr...

Comme j'étais parti sur ma lancée, j'ai aussi refait le design de mon profils Twitter.

Utilisation des pthreads dans un object C++

Fabien Nicoleau

Les pthreads sont fréquemment utilisés pour la programmation des threads, pour lesquels ils fournissent le nécessaire, mais aussi la protection des données. Cependant, si la bibliothèque pthread s'utilise facilement en C, il est parfois un peu difficile de faire des choses propres avec en C++. Je propose ici une solution : un objet PThread s'appuyant sur la lib pthread et fournissant les méthodes nécessaires pour l'utiliser. Cet objet nécessite qu'on lui passe, au moment où l'on souhaite threader une fonction, un pointeur sur celle-ci. Il est plus courant de créer un objet dérivant de la classe gérant le thread, et d'implémenter une méthode run(), mais j'ai préféré ce système car j'utilise cette classe dans un projet où il était plus agréable d'avoir un objet PThread, et de pouvoir lancer un thread facilement, en passant une fontion en paramètre, plutôt que de créer une nouvelle classe à chaque fois. Il est aussi possible de passer une méthode d'une autre classe en paramètre, mais il faut que celle-ci soit décalrée en static. La classe permet en plus connaitre le status du thread, de l'arreter, ou de l'attendre.

Vous trouverez un exemple dans les fichiers joints au billet. pthread.cpp et pthread.h décrivent l'objet PThread, et le main.cpp un exemple d'utilisation. N'hésitez pas à poser des questions dans les commentaires si besoins. Je sais bien que la classe est loin d'être complète, mais elle propose un bon exemple pour aborder les pthread en C++.

Pour compiler l'exécutable, dans le dossier contenant les trois fichiers sources, tapez

$ g++ -o thread main.cpp pthread.cpp -lpthread

Enfin pour l'exécuter, tapez

./thread

Vous verez cinq compteurs s'exécuter en parrallèle.


Fabien (eponyme)

Utilisation des pthreads dans un object C++

Fabien Nicoleau

Les pthreads sont fréquemment utilisés pour la programmation des threads, pour lesquels ils fournissent le nécessaire, mais aussi la protection des données. Cependant, si la bibliothèque pthread s'utilise facilement en C, il est parfois un peu difficile de faire des choses propres avec en C++. Je propose ici une solution : un objet PThread s'appuyant sur la lib pthread et fournissant les méthodes nécessaires pour l'utiliser. Cet objet nécessite qu'on lui passe, au moment où l'on souhaite threader une fonction, un pointeur sur celle-ci. Il est plus courant de créer un objet dérivant de la classe gérant le thread, et d'implémenter une méthode run(), mais j'ai préféré ce système car j'utilise cette classe dans un projet où il était plus agréable d'avoir un objet PThread, et de pouvoir lancer un thread facilement, en passant une fontion en paramètre, plutôt que de créer une nouvelle classe à chaque fois. Il est aussi possible de passer une méthode d'une autre classe en paramètre, mais il faut que celle-ci soit décalrée en static. La classe permet en plus connaitre le status du thread, de l'arreter, ou de l'attendre.

Vous trouverez un exemple dans les fichiers joints au billet. pthread.cpp et pthread.h décrivent l'objet PThread, et le main.cpp un exemple d'utilisation. N'hésitez pas à poser des questions dans les commentaires si besoins. Je sais bien que la classe est loin d'être complète, mais elle propose un bon exemple pour aborder les pthread en C++.

Pour compiler l'exécutable, dans le dossier contenant les trois fichiers sources, tapez

$ g++ -o thread main.cpp pthread.cpp -lpthread

Enfin pour l'exécuter, tapez

./thread

Vous verez cinq compteurs s'exécuter en parrallèle.


Fabien (eponyme)

Qt creator, une IDE pour Qt, par Qt

Fabien Nicoleau

Il y avait l'Assistant, le Designer et Linguist. J'ai découvert aujourd'hui Qt Creator, un outil qui pourrait bien les rejoindre bientôt dans la suite d'outils fournis officiellement pour le développement Qt4 par trolltech. Ce dernier est une IDE, actuellement en version beta, plutôt complète, et vraiment légère. Comme d'habitude, c'est joli, ca marche bien, bref, c'est réussi.

Les outils habituels sont intégrés, on peut donc avoir accès à la doc directement, mais aussi au designer (qui est donc lui aussi intégré à l'IDE). Le "code completion" est aussi réussi, rapide et complet (ce qui manque parfois ...). A y réfléchir, on pouvait penser que ne pas fournir d'IDE était un manque, et qu'il est franchement bien comblé. En revanche, cela m'inquiète un peu pour les IDE actuelles, populaires, mais toujours en développement (QDevelop (que je package pour Fedora), MonkeyStudio (dont je comptais soumettre le package pour Fedora) ou encore Edyuk (dont je travaille actuellement le packaging pour Fedora ...)). Chacune ont leurs spécificités, mais Qt Creator les reprends quasiment toutes. Seul le lien GUI <-> Code fourni par QDevelop manque (c'est d'ailleurs ce qui m'a fait choisir cette IDE). Je me demande si ces projets pourrons avoir un nombre d'utilisateurs croissant car Qt Creator devrait attirer beaucoup de monde ....

L'installation sous Fedora est des plus faciles, il suffit de lancer le script disponible sur la page de téléchargement. Il faudra évidemment avant avoir installé le package qt-devel :

# yum install qt-devel

Attention, sous Fedora 8, c'est

# yum install qt4-devel

Qt Creator est dosponnible sous linux, Mac OSX et évidemment Windows (super le package de 200 Mo quand on a déja Qt d'installé, et qu'on a donc seulement besoin de l'IDE pesant seulement 20Mo ...).

A essayer, et surtout à suivre.

Ceux souhaitant avoir un aperçu sans pour autant l'installer, peuvent regarder ces trois petites vidéos :

Les utilisateurs d'Eclipse peuvent eux aussi bénéficier des outils Qt grâce aux outils d'intégration.


Fabien (eponyme)

Un serveur TCP en C, sans fork, ni threads

Fabien Nicoleau

Il est très courant, voir systématique, dans les tutos décrivant le fonctionnement d'un serveur TCP écrit en C, de voir l'utilisation de la fonction fork() pour gérer le dialogue avec un client connecté. Des raisons bien connues font que fork() est souvent délaissé au profit d'un thread dédié à cette tâche. Sauf que la encore, ca n'est pas forcément la solution idéale. Tout d'avord, l'éternel souci du partage des ressources, mais aussi les attentions particulières qu'ils faut avoir si on arrête le serveur (et donc les processus fils), pour le relancer ensuite (dans le programme lui même, et non pas en stoppant/relançant le programme). Je propose ici une méthode différente.

La méthode en question, est tout simplement d'utiliser la (magnifique) fonction select(), permettant de savoir si des données sont en attente de lecture dans un flux. Ainsi, dans la boucle principale, nul besoin d'utiliser une fonction bloquante si il n'y  a rien en attente. Celle-ci ne sera appelée que si l'on est sûr qu'on à quelque chose à lire. On peut donc, dans un seul processus, gérer la fonction accept(), qui ne sera appellée que si un client est en attente, puis ensuite stocker les sockets client dans un tableau, et parcourir ce dernier afin de savoir si on doit prendre le temps de s'arrêter faire une lecture (autrement dit, s'il y à quelque chose envoyé par un client à lire).  Il suffit de répeter ce processus dans une boucle, et le tour est joué. Pas de blocage, pas de problème de partage de données, pas de problème de fils fantômes ou autre joyeusetées offertes par les threads ou fork.

Pour cet exemple, je donne directement le code. Il faut donc évidemment savoir comment fonctionne un dialogue avec les socket, et avoir des notions sur select(). Le net est rempli d'explications la dessus, nul besoin de répeter.

Ce code gère 5 clients, et affiche les données envoyées par ceux-ci sur la console du serveur. C'est basique, mais ça permet de voir le principe, et d'améliorer ensuite pour produire quelque chose de plus utile. N'hésitez pas à poser des questions dans les commentaires si quelque chose vous échappe.

Le fichier server.c fournit en pièce jointe vous évitera un copié/collé, et sachez aussi que ce code a été validé par le magnifique Thaeron !

Le code :

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/un.h>

#define MYPORT 9999 
#define BACKLOG 5  
#define MAXCLIENTS 5
#define MAXDATASIZE 100

int main(void)
{
   int sockfd,new_fd,numbytes,highest = 0,i;
   int clients[MAXCLIENTS];
   char buffer[MAXDATASIZE] ;

   struct sockaddr_in my_addr,their_addr;
   socklen_t sin_size;
   struct timeval tv;
   fd_set readfds;

   if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
     perror("socket");
     exit(-1);
   }
   my_addr.sin_family = AF_INET;       
   my_addr.sin_port = htons(MYPORT);  
   my_addr.sin_addr.s_addr = INADDR_ANY;
   bzero(&(my_addr.sin_zero), 8);

   if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)) == -1) {
      perror("bind");
      exit(-1);
   }
   if (listen(sockfd, BACKLOG) == -1) {
      perror("listen");
      exit(-1);
   }
   bzero(clients,sizeof(clients));
   if ( sockfd > highest ) {
      highest = sockfd ;
   }
   while(1) {
      sin_size = sizeof(struct sockaddr_in);     
      tv.tv_sec = 0;
      tv.tv_usec = 250000;
      FD_ZERO(&readfds);
      for ( i = 0 ; i < MAXCLIENTS ; i ++ ) {
         if ( clients[i] != 0 ) {
            FD_SET(clients[i],&readfds);
         }
      }
      FD_SET(sockfd,&readfds);  
      if (select(highest+1, &readfds, NULL, NULL, &tv) >=0 ) {
         if (FD_ISSET(sockfd, &readfds)) {
            if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr, &sin_size)) == -1) {
               perror("accept");
               continue;
            }
            for( i = 0 ; i < MAXCLIENTS ; i ++ ) {
               if ( clients[i] == 0 ) {
                  clients[i] = new_fd ;
                  break;
               }
            }
            if ( i != MAXCLIENTS ) {
               if ( new_fd > highest ) {
                  highest = clients[i] ;
               }
               printf("Connexion received from %s (slot %i)\n",inet_ntoa(their_addr.sin_addr),i);
               send(new_fd,"Welcome !\n",10,MSG_NOSIGNAL);
            }    
            else {
               send(new_fd, "No room for you !\n",18,MSG_NOSIGNAL);
               close(new_fd);  
            }
         }
         for ( i = 0 ; i < MAXCLIENTS ; i ++ ) {
            if ( FD_ISSET(clients[i],&readfds) ) {
               if ( (numbytes=recv(clients[i],buffer,MAXDATASIZE,0)) <= 0 ) {
                  printf("Connexion lost from slot %i\n",i); 
                  close(clients[i]);
                  clients[i] = 0 ;
               }
               else {
                  buffer[numbytes] = '\0';
                  printf("Received from slot %i : %s",i,buffer);
               }
            }
         }
      }
      else {
         perror("select");
         continue;
      }
   }
   return 0;
}

Pour compiler ce code, en console, dans le dossier contenant le fichier server.c :

$ gcc -o server server.c

Ensuite pour lancer le serveur :

$ ./server

Enfin pour s'y connecter :

$ telnet 127.0.0.1 9999

(Si vous vous connectez sur le serveur local évidemment). Le port peut être modifié dans le code.

Voilà une solution peu souvent présentée, qui apporte pourtant certains avantages. Lisez cette page pour une utilisation plus poussée.

C'est cette technique qui sera utilisée dans le module de prise de main à distance pour mon bot IRC trustyRC.


Fabien (eponyme)

dotclearRemember 2.0

Guillaume Kulakowski

C'est un peu plus de 3 mois après la sortie de la version 1.2 du framework javascript MooTools; que j'ai enfin pris le temps de migrer le thème de mon blog sous cette version.

J'en ai donc profité pour mettre à jour dotclearRemember. Pour ceux qui avaient loupé la version 1.0 de dotclearRemember, rappelons juste qu'Olivier Meunier, lead developper du projet Dotclear, a fait le choix de confier quelques actions du thème de base de Dotclear à la librairie jQuery. Affictionnados de MooTools, j'ai donc entrepris le portage de ces fonctionnalités vers cet outil et c'est ainsi que la fonctionnalité "Se souvenir de moi" (post.js) de Dotclear est devenu dotcleaRemember sous MooTools.

Au programme des réjouissances de cette version 2.0 :

  • Passage de MooTools 1.1.x vers MooTools 1.2
  • Utilisation de la class Class et nouvelle façon de passer les paramètres ainsi que d'initialiser le script
  • Fonction de débug

dotclearRemember 2.0 pour MooTools 1.2.
dotclearRemember 1.0 pour MooTools 1.1.x.

A propos du thème de ce blog, Nodoka, on remarquera que j'en ai profité pour laisser tomber mon script verif_form (qui ne sera pas porté vers la 1.2) pour passer sous Form.Check qui est tout bonnement génial. J'ai également profité de l'occasion pour céder à la mode des lightbox et pour installer Milkbox...

eZFluxBB 1.0 final

Guillaume Kulakowski

C'est avec beaucoup de plaisir que je viens de libérer le code d'eZFluxBB. Pour ceux qui auraient loupé les épisodes précédents, eZFluxBB est l'extension qui permet à Fedora-Fr d'utiliser conjointement le CMS eZ Publish avec le forum FluxBB.

Dès le début du projet, le code source était disponible sur mon trac et téléchargeable via SVN mais je n'avais pas encore pris le temps de faire un beau petit package avec documentation et tout le toutim.

Fedora-Fr utilise que du libre pour sa plateforme web et c'est avec satisfaction que nous libérons les développements internes. Je tiens aussi à remercier Emma, ma copine, qui ma bien aidé pour la documentation anglaise.

xchat 2.8.6 et les balloons, fin de l'histoire

Fabien Nicoleau

J'avais dans un ancien billet parlé du problème du temps d'apparition des balloons qui était toujours présent dans xchat 2.8.6 et proposé un patch permettant de rendre ce temps paramètrable. Ce patch a été accepté et intégré au code d'xchat dans la version CVS (voir cfgfiles.c, xchat.h et plugin-tray.c) par le développeur principal. Même si ce n'est pas grand chose, ca fait toujours plaisir de voir un petit bout de code à soi dans un logiciel qu'on utilise tous les jours. Malheureusement il faudra attendre une nouvelle release d'xchat pour avoir cette fonctionnalité utilisable sur Fedora car ce patch n'a pas été accepté pour le RPM.

C'est donc la fin de mon combat (gagné!) contre le temps fixé d'apparition des balloons !

Fabien (eponyme)

eZ Publish : activation vs forgotpassword

Guillaume Kulakowski

Il y a quelque chose d'étrange dans la façon dont eZ Publish gère l'activation de compte. En effet, si je crée un compte mais ne le valide pas, je ne peux pas faire une demande de renvoi du mail d'activation. Je peux cependant demander une re-génération de mon mot de passe via la fonction forgotpassword. Cette procédure demande, au préalable, une validation par mail, ce qui permet alors de vérifier le mail de l'utilisateur.
Me voila donc l'heureux propriétaire d'un compte dont l'email est validé, le mot de passe re-généré, mais qui est toujours inactif…

En annexe, je joins un petit patch pour remédier à cela. Je l'ai proposé sur les forums d'eZ publish, mais il ne semble pas déchaîner les foules…

Bien sur, le fait que l'utilisateur puisse réactiver son compte après une désactivation de ce dernier par l'administrateur, implique que la désactivation de compte ne soit pas une mesure de modération mais bien de (re)validation d'email. Pour modérer un bouletutilisateur, on créera alors un groupe à part avec des droits adéquats.

Fedora-Fr v4.1, étude de cas d'un site sous eZ Publish

Guillaume Kulakowski

Cela fera bientôt 3 ans que je travaille avec le CMS open-source eZ Publish édité par la société eZ Systems. J'ai débuté cette expérience dans la société Kaliop, et je la poursuis aujourd'hui, chez Logica.

Que ce soit en temps qu'expert, consultant ou développeur (« simple » ou référent), j'ai eu la chance de collaborer sur un grand nombre de projets différents utilisant cet outil. Des projets tels que des sites institutionnels (WWF, UM1), des (extra|intra)nets, des usines à sites, ou encore, dernièrement, un portail immobilier avec plus de 150.000 objets eZ (prévoyez 2 jours pour l'import sur un octo proc' ;-)).

Cependant, jusqu'à présent, mon utilisation d'eZ Publish s'était cantonnée au monde professionnel et je n'avais pas de site « personnel » (je mets entre guillemets car Fedora-Fr n'est pas un site perso, mais un site que je gère personnellement...) utilisant cette technologie. J'avais bien commencé le portage de Scénario-Paintball sous eZ, mais je suis toujours en attente d'une charte graphique (Rad' si tu me lis...).
Bref, la refonte de Fedora-Fr sous eZ arrivait à point nommé pour m'offrir un petit bac à sable pour toucher d'encore plus près l'outil, développer autour et reverser du code à la communauté.

Cette migration s'est faite en 2 temps; le premier, la bascule du Planet de Dotclear (+plugin planet) vers eZ; suivie dans un deuxième temps par le passage du site www.fedora-fr.org (le portail) sous eZ.

Le choix d'eZ

Comment s'est fait le choix d'eZ Publish ? Le premier choix qui a été fait à été celui de changer la structure d'avant qui souffrait de 2 problèmes majeurs :

  • Le premier venait du planet qui avait tendance à sauter des blogs voir même à arrêter l'indexation de ces derniers... Dotclear montrant ses limites, il fallait le changer.
  • Le deuxième problème venait de la structure même du portail de Fedora-Fr. C'était un portail 100% maison développé par mes soins, mais utilisant un grand nombre de fonctions PunBB. Je craignais que le passage à la 1.3 de PunBB (qui sera en fait la 1.3 de FluxBB) ne cause pas mal de problèmes et demande beaucoup de réécriture de code.

J'ai donc fait le choix de revoir ma copie et de ne plus faire un portail autour de PunBB mais de prendre un CMS déjà existant et de lui permettre de communiquer avec PunBB/FluxBB.

Mon bagage en eZ, ainsi que le fait qu'il correspondait parfaitement à nos besoins (notamment la fonction d'import/export de contenu via RSS), ont fait que c'est naturellement que je me suis tourné vers cette solution et que j'ai commencé le développement d'eZFluxBB.

eZFluxBB

A l'heure où j'écris ces quelques lignes (dans un Starbucks Parisien, la classe ;-)), eZFluxBB est disponible en version 1.O RC1 sur mon Trac. Il est parfaitement fonctionnel et il ne me reste qu'à faire la documentation : exportation de la doc francophone en PDF via Trac et traduction de cette dernière en anglais. Une fois que cela sera fait, eZFluxBB sera packagé et reversé à la communauté.

Bien définir le rôle de chaque outil

Lorsque j'ai commencé le développement de la nouvelle version de Fedora-Fr (v4.1) sous eZ Publish, j'ai délimité le rôle de chaque outil : FluxBB pour les forums et la gestion des membres; eZ Publish pour la partie publication.

Il n'est aucunement prévu de faire une synchronisation des membres eZ/FluxBB ni même de permettre au visiteur de Fedora-Fr de se connecter sur le CMS. Cependant, comme eZFluxBB est sous GPL, si la demande est là et si des volontaires sont motivés, pourquoi ne pas ajouter cette fonctionnalité à eZFluxBB : login handler / loginhandler ] + cronjobs côté eZ, hook côté FluxBB. Cependant, je ne pense pas l'activer sur Fedora-Fr.

Structure eZ mise en place sur Fedora-Fr

Les extensions

On est dans une architecture classique en eZ, à savoir : 1 site = 1 extension.
A cela, j'ai ajouté une extension dite socle permettant de regrouper certains design, les traductions et certains paramètres propres à tous les sites de Fedora-Fr en eZ.

Au extension typées sites, s'ajoute:

  • eZFluxBB : Communication FluxBB / eZ
  • MyUtils : Contient des fonctionnalités que je peux récupérer sur d'autres projets
  • ezrssfeed : Pratique pour afficher du contenu extrait de fils RSS sans avoir à le mettre en base
  • eZOE 5 : Pour finir, notons que j'ai fait le choix de partir sur la version 5.0 beta d'eZ Online Editor, l'éditeur de contenu d'eZ à la place du traditionnel ezdhtml (v4)

Les classes

Je ne vais pas décrire toutes les classes utilisées sur les différents sites. Je vais simplement dire que plutôt que de créer des classes spécifiques par typologie de contenu, j'ai fait le choix que toutes les pages soient de la classe page (ou website pour les pages d'accueil). Ensuite, j'inclus les différents blocs (qui eux sont des contenus spécifiques) via l'éditeur eZOE.

Edition de la page d'accueil du site

Je me suis même amusé à personnaliser le contentstructuremenu.ini.

Utilisation d'eZFlux dans l'administration d'eZ Publish

Les différents sites de l'instance eZ Publish

L'une des forces d'eZ est de pouvoir créer plusieurs sites à partir d'une seule instance de l'outil. Voila ce que ça donne sur Fedora-Fr (je fais un peu de teasing sur les prochains projets....).

Les différents site eZ Publish de Fedora-Fr

Concrètement, pour un professionnel, avec une bonne configuration des vhost apache, cela permet de confier tout son système d'information à eZ : site institutionnel, extranet et intranet , etc...

Planet

Comme écrit plus haut, le planet a été le premier sous-domaine à migrer sous eZ. Bien que la fonction d'importation des flux RSS d'eZ a l'air taillé sur mesure pour un planet, il souffre d'un manque de souplesse et elle m'aurait obligé à renseigner les flux RSS de chaque blog moi-même...

Comme je suis fainéant (c'est un avantage en informatique il parait), j'ai fait le choix d'étendre la classe utilisateur et de modifier le cronjobs rssimport.php en planet.php pour que ce dernier aille chercher les informations directement dans le profil des utilisateurs du groupe blogeur.

Edition de son profil Fedora-Fr

Le contenu de chaque billet est stocké dans un datatype Bloc-text, directement en HTML. Comme certaines versions de Dotclear utilisent des liens relatifs pour leurs smileys (ce qui invalide un flux, soit dit au passage) et que tous les blogs ne respectent pas les normes du W3C (je ne citerai pas de nom), cela m'a contraint à nettoyer les contenus avec quelques expressions régulières et à utiliser php-Tidy (yum install php-tidy, merci Remi).

Pour ceux qui seraient intéressés par mon, cronjob planet, il est disponible dans mon extension MyUtils téléchargeable sur mon Trac ou par svn.

WWW

Le portail est plus classique dans son développement, il s'agit en effet d'un site de présentation. Sa seule particularité est l'utilisation d'eZFluxBB pour récupérer les informations à partir de PunBB.

Démo d'eZFluxBB 1.0 RC1

Choix technologiques

Cache statique

Passer un site de la recette à la production est toujours cause de stress. En effet, il est toujours difficile d'apprécier la charge que va provoquer une nouvelle application avec 3.000 à 4.000 utilisateurs quotidiens (quoi qu'il existe des logiciels pour ça). Les développeurs d'UbuntuUser.de en ont récemment fait les frais.

En terme de performance, la référence était pour moi le site précédent. Basé sur PunBB, pas complètement POO ce qu'il faut le dire lui confère des pages servies en moins de 0,05s. Malheureusement, malgré tous les caches possibles et toutes les optimisations de développement envisageables, eZ, de par sa richesse fonctionnelle, n'arrivait pas à de tels scores. J'ai donc entrepris des tests de cache statique sur le planet. Les tests m'ont convaincu et j'ai mis en œuvre cette technique également sur le portail.

Concrètement qu'est-ce que le cache statique ?

Avant de servir la page, Apache va aller vérifier si elle existe dans un répertoire de cache. Si c'est le cas, il servira une simple page HTM, sinon, il servira une page issues d'eZ Publish. Le gain de performance est conséquent puisqu'on ne sert plus des pages php mais de simples pages HTML sans aucun calcul.

## Cache static
RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$
RewriteCond /path/to/ez/static/fedora_portail/index.html -f
RewriteRule ^/$ /static/fedora_portail/index.html [L]

RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$
RewriteCond /path/to/ez/static/fedora_portail/index.html -f
RewriteRule ^$ /static/fedora_portail/index.html [L]

RewriteCond %{REQUEST_METHOD}      !^POST$
RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$
RewriteCond /path/to/ez/static/fedora_portail$1/index.html -f
RewriteRule ^(.*)$ /static/fedora_portail$1/index.html [L]
RewriteRule !\.(gif|css|jpg|png|jar|ico|js)$ /index.php

Limitation

Comme il n'y a plus d'opérations php, la page est la même pour tous. Ça ne dérange pas sur le planet, mais sur le portail, la barre d'utilisateur de PunBB est confiée à une requête AJAX (voir plus bas).

Le bug #9126 faisant que le cache d'eZ se regénérait à partir de la version déjà en cache, cela m'a contraint à mettre quelques fichiers d'eZ 4.0 à jour par rapport à la version 4.0.1.

L'utilisation du cache statique sur Fedora-Fr

Fedora-Fr ne confie pas la régénération du cache statique à eZ Publish. En effet, la page d'accueil possède des contenu indépendants d'eZ et le planet également. J'ai donc fait le choix via cronjobs de mettre à jour le planet toutes les heures et la page d'accueil toutes les 5 minutes.

# Planet
0 * * * * cd $EZPUBLISHROOT && $PHP runcronjobs.php planet -q 2>&1 /dev/null; $PHP bin/php/makestaticcache.php -s $PLANET -f 2>&1 /dev/null

# Portail
*/5 * * * * cd $EZPUBLISHROOT && $PHP bin/php/makestaticcache.php -s $WWW -f 2>&1 /dev/null

MooTools

Fedora-Fr embarque la librairie MooTools dans ça version 1.2. Son utilisation est essentiellement due à 2 points :

  • L'événement domready qui comme le montre la démo, est bien plus rapide que le classique onload. Cet événement permet notamment de gérer les requêtes AJAX avant le chargement total de la page ce qui fait que vous ne voyez presque pas que la page se charge en 2 temps.
  • L'autre raison est une volonté d'aller plus vers le web 2.0 (même si je n'aime pas ce terme) avec l'utilisation d'info-bulles plus riches en informations et bien d'autres évolutions qui seront visibles avec l'arrivée de FluxBB 1.3.
window.addEvent('domready', function(){
       
        /* Récupération du brdwelcome en AJAX */
        if ( $('brdwelcome') && $('brdwelcome').hasClass('ajax')) {
                // Requète AJAX en 1 ligne...
                $('brdwelcome').load( ezroot + 'ajax/brdwelcome.php');
        }
});

Design

La façon dont les designs sont gérés sur Fedora-Fr diffère quelque peu des sites eZ classiques. En effet, après avoir hésité avec une utilisation classique conjointe à l'emploi d'ezoescript et ezoecss, j'ai fait le choix de conserver la structure de Fedora-Fr actuelle. A savoir, utiliser un sous domaine (common) pour les javascripts, les images et les feuilles de styles.

Fedora-Fr sous Firebug

Cela permet, par exemple, de ne télécharger qu'une fois la librairie MooTools (60Ko normalement mais 19Ko une fois compressée) pour le portail et le planet. Ça me permet aussi d'avoir toutes mes feuilles de styles et mes javascript à un seul endroit et de les compresser facilement avec YUICompressor.

Et demain

Les projets futurs en eZ ?

  • Passer la Faq non-officielle sous eZ.
  • eZFluxBB 1.1 compatible FluxBB 1.3. D'ailleurs, je travail actuellement sur la nouvelle version du forum utilisant FluxBB 1.3.

eZFluxBB 1.0 RC1

Guillaume Kulakowski

Je viens à l'instant de compléter la version 1.0 RC1 de eZFluxBB : le connecteur PunBB / FluxBB et eZ Publish. Pour plus d'information sur eZFluxBB vous pouvez vous reporter à mon précédent billet.