Envole » Envole-Archive » posh » eole-posh

h1. Mettre un badge sur xDesktop (2.3)

h2. 1° Définition du type de badge 

La définition du type de badge se passe dans la gestion des profil (/posh-profil)

Lors de cette définition, vous avez la possibilité de définir

* *Le type de badge*: Informations, Attention et erreurs, le type de badge déterminera le type d'icone qui sera affiché

* *Le message* qui sera affiché à droite, juste au dessus du post-it

* *Une url distante* qui permettra de charger des badges dynamiques

+Exemple+

Voici la définition d'un badge sur piwigo

!badge-definition-photo.png!

Voici le résultat

!badge-infos-photo.png!

Vous noterez le *formatage HTML* et le lien *cliquable*

h2. 2° URL distante

Il est possible de définir une url distante qui permettra de récupérer une information qui peut donc être dynamique. comme par exemple le nombre de mail non lu.

Le chargement de l'url peux se faire de deux manières

h3. L'URL retourne un objet json directement

Dans ce cas il est *INDISPENSABLE* que cette url retourne directement un objet json, sans passer par des redirections HTML

pour cela la définition de l'url devra être préfixée par :

    @:http://URL_DU_BADGE/chemin/?parametres@

Cette url devra donc retourner

    @{count:<count>,message:<message>,type:<type>}@

Voici la signification des champs

* *type*: type de message (infos, warning, errors, count)

* *message* : votre message a afficher, laisser a vide si pas de message

* *count*: si c'est de type count, ce paramètre affichera le nombre dans l'info bulle

h3. L'URL doit passer par des redirections pour notamment permettre une authentification.

Dans la méthode précédente, l'appel utilisé est une fonction AJAX qui permet de charger une URL.

Sauf que l'appel d'une fonction AJAX, ne permet pas de suivre les liens de redirection

C'est ce qui se produit notamment lors d'une authentification CAS.

J'ai donc mis en place un mécanisme permettant d'utiliser une iframe avec l'appel d'un callback.

Ce mécanisme permet donc 

* De gérer les redirections http, lors des phases d'authentifications

* D'éviter les Xframe cross scripting inter-domaine, vous noterez donc qu'il est possible d'utiliser un badge sur un domaine différent.

La définition de l'url se fait de manière classique de manière absolue ou relative

    @https://URL_DU_BADGE/chemin/mapage?parametres

ou /chemin/mapage?parametres@

+*NOTE:*+  A cause des problème de mixed-content je vous conseille d'utiliser les liens en https

xDesktop appel cette URL en précisant une url de callback et un id. Avec l'exemple ci-dessus cela nous donne une requête (de xdesktop) vers l'url suivante

    @http://URL_DU_BADGE/chemin/mapage?parametres&callback=<domaine envole>/includes/plugins/plugin_xdesktop/infosplus.php&id=<id interne xdesktop>@

Votre page doit alors rediriger vers l'url de callback en précisant les informations suivantes

* id: id interne xdesktop, que vous avez reçu

* type: type de message (infos, warning, errors, count)

* message : votre message a afficher, laisser a vide si pas de message

* count: si c'est de type count, ce paramètre affichera le nombre dans l'info bulle

* link: pour le moment self permet de rendre le message cliquable

Ces informations peuvent être transmises en POST ou en GET, ainsi dans note exemple ci dessus votre page devra rediriger vers l'url suivante

    @<domaine envole>/includes/plugins/plugin_xdesktop/infosplus.php?id=123456&type=count&count=3&message=3%20messages@