Petit retour sur Elgg. A l’occasion d’une petite (mini) mission je me suis penché sur l’API REST. L’objectif étant de brancher Elgg et son moteur (engine/lib) en utilisant son API REST à un service WS Soap tiers pour l’alimenter. En quelques mots : brouillon mais prometteur.

Pour rentrer plus précisément sur le sujet je devais générer des groupes dynamiquement en puisant les infos dans un WebService SOAP externe. Ce que mon proto met en avant : il est tout à fait possible d’”exposer” (selon la terminologie elgg) toutes les fonctions liées aux entités de Elgg. C’est à dire que l’on rend accessible via une API REST les fonctionnalités des briques de Elgg. Pour cela il faut créer un plugin (du moins je m’y suis pris ainsi). Créer un plugin c’est deux coups de cuillère à pot :  un fichier manifest.xml qui dit qui/licence/version, un fichier start.php qui permet de générer ses fonctions et surtout de les enregister au sein du fonctionnement de Elgg. Je n’ai pas creusé l’aspect MVC du produit mais après si je regarde les autres plugins tout semble couler assez de source : dossier view, dossier action, etc. Le fait de manipuler les librairies Elgg depuis son infrastructure rend tout plus simple : on accède à toutes les librairies tous les objets/entités, toutes les fonctions. Y’a plus qu’à.

Il ressort cependant que l’API n’est pas très propre au niveau du codage et que pas mal de petits bugs sont présents.J’adore à ce sujet le passage du wiki :

Note: Elgg’s REST API has many bugs so developers need to beware that development with it will take longer than expected as you run up against these bugs

Par exemple dans mon code, j’ai eu besoin de faire un accès direct  à la base de données (ce qui n’est pas vraiment conseillé…) l’API de l’entité “group” ne fonctionnant pas pour l’attribut owner_guid. Enfin j’ai aussi par exemple supprimé des validations de paramètres dans l’API REST qui fonctionnaient de manières incohérentes. Enfin si il semble dans la documentation que les questions de sécurité soient bien prises en charge, j’ai eu la surprise de noter que suite à mon installation on pouvait déclencher la fonctionnalité sans aucune restriction via un url / méthode GET (alors que j’avais préparé un script mettant en place des headers/entêtes http spécifiques pour palier à cette question d’authentification). Alors soit c’est un leurre (la sécurité de l’API). Soit j’ai raté un épisode et j’ai pas compris ou activé la sécurisation de l’API (la bonne hypothèse probablement). A fouiller donc.

Ces divers désagréments ne sont cependant pas bloquants. Elgg et son “engine” et API REST sont très prometteurs. Le code va aller en s’améliorant, il est déjà correct. Les questions de sécurité peuvent être traitées à un autre niveau : sécurisation des urls REST via Apache par exemple.

Pour tout cela il s’agit de développement php/mysql relativement classique, donc efficace et productif. Il faut cependant mettre un bémol sur cette productivité en raison de la jeunesse de la plate-forme Elgg et des anomalies qu’on y trouve toujours encore régulièrement.

quelques urls intéressants :
des exemples de codes et infos concernant l’API :
http://trac.elgg.org/elgg/browser/trunk/mod/apitest/start.php?rev=430
http://www.danielansari.com/wordpress/2008/12/how-to-use-the-rest-api-in-elgg-11/

Quelques bouts de code :

le plugin :fichier start.php

<?php

function haras_init()
 {
 /** j'expose ma fonction  au travers de l'api REST */
 expose_function(
 'group.create', //method
 'createGroup', //function
 array (
  "user_guid" => array('type'=>'string'),
 "montrucnumber" => array('type'=>'string')
   ), // parameters
 elgg_echo('group.create'),  // description
 "GET", // call_method
 false, // auth token
 true // anonymous   <-- sûrement cette ligne mes questions sur l'authentification   
  );
  }

function getMontruc($montruc)
 {

  /** je récupère l'objet vers le service SOAP tiers */

}

function createGroup($user_guid, $numtruc)
 {

[...]

 $montruc = getMontruc($numtruc)

/** je crée dynamiquement un groupe */

 $group = new ElggGroup();

 $user = get_entity((int)$user_guid);

 $group->name = $montruc->name;
 $group->description = $description;
 $group->access_id = 2;
 $group->membership = ACCESS_PUBLIC;
 $group->files_enable = get_input('files_enable', 'yes');
 $group->pages_enable = get_input('pages_enable', 'yes');
 $group->forum_enable = get_input('forum_enable', 'yes');

 $group->save();

 $group->join($user); // toujours créer un utilisateur après la création du groupe

 /** l'API ne fonctionne pas je dois manipuler
 // sale mais nécessaire, api bugguée
 $dblink = get_db_link('write');
 $query = "update elggentities set owner_guid =" . $user_guid . " where guid=" . $group->guid;
 $result = execute_query("$query", $dblink); 

 return 'group ' . $group->name . ' ' . $group->owner_guid . ' created';  // ouh là là le proto
 }

/** très important, on enregistre le service/handler auprès de Elgg */
 register_elgg_event_handler('init','system','haras_init');

?>

Ps : ci-joint un arbre des solutions PHP que je viens de réaliser, un dessin valant mieux qu’un long discours.

Si vous souhaitez m’éclairer sur une solution opensource, fiable, php, qui complète ce diagramme je suis preneur !

Basé sur PHP, a première vue le code parait surprenant, on ne voit pas immédiatement dans l’arborescence projet où se trouve quoi, et à quoi sert tel ou tel dossier. Tout ce qui se conçoit clairement se déploie clairement, et cette première impression reste mitigée. Je vous en dirais plus lorsque j’aurai vraiment essayé de toucher au code. Je suppose que cela est du au modèle de données : apparemment il a été prévu un modèle très malléable : j’introduis un nouveau type d’élément (une entité), je lui donne telle ou telle propriété avec telle ou telle valeur. Du coup demain si j’ai un élément de type nouveau, pas de problème, pas de modification de la structure des tables, ça roule. Bon, pour l’instant mon analyse est très superficielle donc sujette à caution. Je compte creuser et vous informer. Je ne sais pas si ce modèle n’a pas un impact sur les performances aussi, que je trouve un chouïa poussives (ils ont cependant prévu l’utilisation de memcached ou autre pour optimiser celles-ci). Idem pour le design, et le système de templates, je n’ai rien vu de concret jusqu’à présent. Enfin, un dernier petit point : l’installation se fait cahin-caha : il faut nécessairement activer le mod_rewrite de Apache. J’aurais préféré avoir le choix d’utiliser le rewrite ou non, cela pourrait faciliter le debug.

Bref il me faut creuser, car c’est malgré tout très prometteur (ah j’oubliais aussi de signaler  une API REST qui permet à l’accès à toutes les fonctions de l’outil, même si un warning indique qu’elle peut encore secouer un peu).

J’ai pu assez (très) rapidement monter une plate-forme, activer tout un tas de plugins à la facebook, twitter, pages, blog, albums photos, fichiers, etc. C’est du PHP/MySQL/Apache, donc cela reste simple (dans le bon sens du terme), efficace et productif. Aujourd’hui avec l’évolution des pratiques des internautes, et plus globalement des gens (voir des mobilonautes ou des iphonautes)  il parait évident que c’est le genre d’outil à déployer : communauté d’utilisateurs d’un logiciel, d’un produit, événementiel : par exemple un festival de musique, ou la convention des maraichers, ou l’université d’été du xxx (mettez le parti qui vous embauche)  : 3 mois avant la plate-forme est disponible, on chat, on blog avec les intervenants, avec les organisateurs, etc. durant l’événement c’est un vecteur en temps réel de l’actualité, a posteriori, c’est un outil de rétrospective (fichiers liés, blogs,images, etc.).

Bref, pas mal de projets assez excitants autour en perspective, j’espère du moins. Si vous souhaitez tester un peu la plate-forme vous pouvez aller chez Elgg.org ou me demander de vous créer un compte pour elgg.areyouagile.com (en me contactant pablo point pernot arboase gmail point com). C’est la plate-forme de test dont je vous parlais. Attention actuellement vu de l’extérieur elle paraît très creuse car nous avons ajouté un pluggin (walledgarden) qui interdit l’accès du public aux infos.

Typo3 possède un langage de script propriétaire (le typoscript), qu’il soit bon ou mauvais peu importe, mais il est très long à prendre en main. Si donc une nouvelle équipe est amenée à intervenir sur un projet Typo3, la charge liée à sa montée en compétence est plus lourde que celle du PHP standard de eZPublish. Trouver un développeur est aussi moins simple que de trouver un développeur PHP. Problème de productivité donc. Le deuxième point est aussi lié à typoscript, on doit le modifier dans l’interface web du backoffice. Ceci interdit l’utilisation d’un gestionnaire de source classique type Git ou Subversion. C’est donc très dommageable, le script ne peut être modifié que par une seule personne à la fois. Problème de productivité encore.

Ces deux défauts ne sont pas anodins. Ils handicapent fortement le TCO (le fameux coût de revient global) d’une solution comme Typo3. eZPublish quand à lui n’utilise que des standards : PHP. De fait il est bien plus ouvert même si Typo3 est la solution 100% communautaire.