 Après la lumière au bout suivi de la feuille de route Xoops 2.3/2.4 voici un point intermédiaire sur les fonctionnalités de ces futures versions de Xoops.
Comme vous pouvez le lire dans l’article rédigé par Solo, l’Afux a réuni le week-end des 4 et 5 mars les membres de l’équipe Xoops francophone afin de faire le point sur ce que comportera la future version de Xoops et lui assurer le support qu'il convient auprès de la communauté. Skalpa, responsable du développement du noyau xoops, est l’initiateur de cette version. Nous allons tenter de vous faire partager les nouveautés et quelques principes de fonctionnement de cette version à partir des notes (prises essentiellement par Hervé).
1. Pré-requisCette nouvelle version de Xoops nécessitera au minimum une version 4.3 de PHP, sachant que des nouveautés ont été implémentées pour profiter des avantages de PHP5 (voir plus loin au chapitre 4 connexion avec d’autres bases de données)
2. InstallationIl sera toujours possible d’installer Xoops comme aujourd'hui mais une nouvelle fonction permettra de lancer le noyau en "ligne de commande" afin de l'utiliser pour des tâches périodiques (cron) ou pour pouvoir configurer des fonctions avancées qui ne seront pas modifiables en passant par l'interface graphique.
3. Démarrage de XoopsXoops disposera de deux modes de fonctionnement : un mode développement utilisé pour la construction, le paramétrage et la mise au point de son site et un mode production lorsque celui-ci sera opérationnel. Un site paramétré en mode production devrait tourner plus rapidement qu'un site paramétré en mode développement car il ne recevra pas tous les messages de debug, de log et les templates seront déjà compilés. Les messages de debug ont changés, les trois modes de mise au point sont remplacés par un seul mode debug qui résume tout : les erreurs/warning Php et Mysql.
Grossièrement en mode développement (où le debug est activé automatiquement) le site utilise le paramétrage contenu dans la base de données, les templates sont recompilés à chaque utilisation alors qu'en mode production, il génère du code Php (des classes) afin de gagner en vitesse en sollicitant moins la base de données. Par exemple lorsque les préférences du site sont modifiées puis appliquées (dans la base de données), du code Php est généré directement afin d'éviter de relire les tables plus tard. Il sera possible de "démarrer" Xoops en ligne de commande (via le shell du système d’exploitation). Une fois le site xoops "démarré" par ligne de commande, c'est tout l'environnement Xoops qui sera disponible.
4. Quelques grands principes
Pyro est la librairie (objet) permettant de gérer l'interface (par exemple les breadcrumbs). Cette librairie met à disposition des widgets (objets graphiques) un peu comme la librairie graphique QT sous Linux et Windows. Le système de cache est revu. Le cache côté client (mis en place par les navigateurs depuis des années) va être mieux utilisé et plus intensivement afin d'obtenir des sites plus rapides en affichage. Le cache côté serveur a aussi été amélioré. Les écrans de redirection ne sont plus les mêmes, ils sont remplacés. Le système des traductions va être totalement revu afin d'utiliser les fichiers .po bien connus dans le monde Linux. Cela posera moins de problèmes mais il va falloir revoir toutes les traductions. Les fichiers .po seront traités et traduits en un format interne. Le support multilangue est prévu. D'un point de vue du noyau cela se traduira par l'integration des fonctions du module xlanguage (réalisé par phppp qui doit travailler sur le sujet). Par contre cela ne sera pas suffisant et nécessitera une adaptation des modules par leurs auteurs, afin que ceux-ci exploitent les nouvelles possibilités mises à leur disposition. Une nouvelle interface de gestion des bases de données calquée sur PDO, nouveauté de PHP5, a également été ajoutée. Même si son ajout ne permettra pas à XOOPS de tourner tout de suite sur d'autres bases de données que MySQL, ce choix est un pas dans cette direction. En attendant, cela permettra déjà une adaptation rapide des applications utilisant cette interface, donnera aux développeurs de nouvelles possibilités, tout en permettant aux nouveaux venus de se trouver face à une couche d'accès aux bases de données standard et parfaitement documentée. L'administration de Xoops ne devrait plus contenir QUE ce qui permet de configurer le site et elle va être réorganisée afin que ce soit moins le "bazard". Le nouveau système d'authentification sera organisé sur le principe de services. Il sera alors possible d'ajouter n'importe quel système d'authentification : LDAP (bien sur !) mais aussi SGBD, NIS, .... Dans la 2.4 la gestion des blocs sera déportée dans un module.
4.1 Surcharge
Xoops va utiliser un système de surcharge (surcharge basée sur le concept utilisé en programmation orientée objet).
4.1.1 Surcharge des thèmes
Il est possible de créer un thème qui hérite d'un autre thème. Il suffit alors de ne décrire que les changements !
4.1.2 Surcharge des templates de modules
Dans le thème d'un site (dans son répertoire), il sera possible, en recréant l'arborescence d'un (ou de plusieurs modules), de remplacer les templates par défaut d'un module par des templates personnalisés ! Exemples pratiques
Si tous les sites supports de Xoops (et xoops.org) étaient sur le même hébergement, on pourrait imaginer d'avoir le thème de xoops.org. Ensuite chaque site de support aurait son propre thème qui "surchargerait" le thème par défaut afin de le personnaliser selon sa culture et son goût, en mettant par exemple son drapeau ou la photo d'un monument qui représente son pays. Il n'aurait donc pas besoin de refaire tout le thème. Ensuite chaque site de support personnaliserait les templates des modules (toujours en les surchargeant) afin de pousser la personnalisation jusqu'au bout. Comme autre exemple, on peut penser à une chaîne de restauration qui propose un site "global" qui parle de la chaîne mais qui héberge aussi les sites de chaque restaurant. Le siège propose un thème et des templates "généraux" qui définissent l'identité visuelle et générale du groupe et chaque restaurant à la possibilité de "personnaliser" son site en surchargeant le thème par défaut qui a été crée par la maison mère afin d'y apporter une touche locale. Notes : on a quasiment la possibilité de tout surcharger, thèmes, templates, CSS et images.
4.2 Réécriture des URL
Tout d'abord, ll ne faut pas prendre cela uniquement comme une classique réécriture d'url telle que celle que l'on peut mettre en place dans les fichiers .htaccess d'Apache pour faire de l'url-rewriting. Il va être mis en place une gestion globale et totale des URI (attention, pas URL mais URI). L'un des objectifs poursuivis est de permettre de faire de la réécriture d'URL (qui au passage devrait aussi fonctionner sous IIS).
Les modules et le noyau ne traiteront plus des url physiques.
Un exemple de la mise en oeuvre pratique de ce système c'est de pouvoir remplacer un module par un autre (ou de le renommer) sans que cela ne pose de problèmes au niveau des URL.
5. Les thèmes
Un thème va se décomposer en 3 parties : - Le canevas
- La page
- Le contenu
Le canevas contient les éléments communs au site, par exemple une bannière de pub en haut ou un menu de navigation.
La page est utilisée par et pour le module (on va par exemple y trouver le nom du module ou le nom de la catégorie en cours ou le "chemin" d'un article)
Le contenu va quant à lui contenir le contenu propre à la page, par exemple un article.Le fichier qui contiendra le thème ne devra pas obligatoirement s'appeler theme.html (pratique lorsque l'on récupère par exemple un kit graphique qui n'a pas été réalisé à la base pour Xoops). Chaque thème va contenir un fichier xo-info.php. Ce fichier va donner des informations sur le thème (un peu comme les fichiers xoops_version.php utilisés actuellement pour les modules).
<?php
return array(
'xoBundleIdentifier' => 'theme_default',
'xoBundleDisplayName' => 'XOOPS default theme (standards compliant)',
// This theme default templates
// templates paths must start with a "." to be considered relative to the theme folder
'canvasTemplate' => './theme-canvas-default.xotpl',
'pageTemplate' => './theme-page-default.xotpl',
// Properties that indicate the type of content this theme generates
'supportedMimeTypes' => "application/xhtml+xml,text/html,application/pdf",
'namespaces' => 'http://www.w3.org/1999/xhtml',
'doctype' => 'html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"',
);
?>
Un thème peut hériter d'un autre thème qui lui même hérite d'un autre thème. Une compatibilité avec les thèmes existants est néanmoins assurée mais ils ne pourront pas bénéficier des nouveautés de cette version.
6. Les templates
Le délimiteur Smarty utilisé dans les templates a été modifié afin de permettre aux graphistes de travailler les templates dans des logiciels comme dreamweaver sans que cela ne pose de problèmes. Les templates ont été totalement revus, on a maintenant la possibilité de générer du Pdf ou tout autre format de document basé sur un vocabulaire xml (comme par exemple des flux RSS ou pourquoi pas des documents OpenOffice). En fait un template peut contenir les différentes versions de sortie d'un même document. Dans le même fichier "physique" du template on peut avoir : - la version écran d'une news
- la version RSS
- la version PDF
- la version RSS
- etc..
Cela ne pose pas de problème vis à vis d'une éventuelle lourdeur d'interprétation par Smarty car les différentes versions de la page sont "compilées" et éclatées en fichiers par le système.Le code renvoyé aux navigateurs sera du vrai xhtml. Possibilité d'avoir du contenu adapté aux navigateurs (par exemple pour une même page, d'avoir une version en tableau pour Internet Explorer et une version full CSS pour les autres. Il est possible d'intervenir sur le contenu transmis aux templates via un système de plugins (un peu comme Smarty et comme dans Mambo). A terme on devrait pouvoir modifier les templates en mode wysiwyg via un éditeur qui reste à développer. Cet éditeur utilisera le CSS du site afin que le rendu soit le plus proche possible de l'apparence du site. Dans les templates on n'appellera plus des chemins physiques. Sur le principe, actuellement on peut utiliser XOOPS_UPLOAD_URL dans les templates afin de faire référence au répertoire d'upload de chaque site. En quelque sorte c'est une forme d'abstraction du chemin physique. Avec cette nouvelle version, il sera possible de faire référence à un module (dans les templates), en utilisant une notation du genre : identifiant_module#nom_de_la_page_du_module Par exemple : id_news_module#article Attention, il ne faut pas confondre le # (et ce qui se trouve après) présent dans ce format d'URL avec des ancrages internes à des pages tels que ceux que l'on peut utiliser en html.
C'est le sytème (Xoops) qui se chargera de faire le lien vers l'emplacement physique du module et d'en faire une url réécrite (cette fois-ci au sens url rewriting).
7. Les modules
Le développement de modules va se trouver grandement simplifié ET accéléré. La création d'un module simple pourrait être accessible à un plus grand nombre grâce aux nouveautés fonctionnelles dont disposera cette version. On pourra créer un module simple 'par exemple' de blog en moins de 5 minutes comme dans Ruby On Rails. Chaque module se verra définir un identifiant et décrirera (entre autre) ses propres pages (avec un id et une description). Ce fichier définira aussi les permissions du module.
Par exemple, "ce module est un module pour l'admin uniquement" (ce sera une recommandation, mais si l'administrateur ne change pas les permissions du module, ce sont les permissions décrites par le développeur dans le module qui seront utilisées).
Exemple avec le module d'authentification :
return array(
'xoBundleIdentifier' => 'mod_xoops_Identification',
'xoBundleDisplayName' => 'XOOPS default identification module',
//'xoClassPath' => '/xoops-module.php',
'allowFor' => array( XOOPS_GROUP_ANONYMOUS, XOOPS_GROUP_USERS ),
'moduleLocations' => array(
'login' => array(
'displayName' => 'User login',
'scriptFile' => '/login.php',
'parameters' => array(
'login' => array( '', XO_TYPE_STRING ),
'password' => array( '', XO_TYPE_STRING ),
'xoops_redirect' => array( '', XO_TYPE_STRING ),
),
),
'logout' => array(
'displayName' => 'Logout',
'scriptFile' => '/logout.php',
'allowFor' => array( XOOPS_GROUP_USERS ),
),
'lost-password' => array(
'displayName' => 'Lost your password ?',
'scriptFile' => '/lostpass.php',
),
),
'xoServices' => array(
'xoops_identification_LoginForm' => array(
'xoClassPath' => '/class/loginform.php',
),
),
);
Les classes Xoopsform permettant de faire des formulaires ont été réécrites, afin d'offrir une meilleure séparation entre les données, leur manipulation et leur représentation. Cela permettra de remplacer un type de contrôle par un autre en modifiant le template adéquat (les champs de formulaire étant créés dans le template), tout en offrant au passage de notables améliorations (une validation avancée des formulaires faite en temps réel). Dans l'absolu on devrait également pouvoir remplacer la génération des formulaires html classiques par des xforms par exemple. Smarty est conservé mais c'est une version modifiée et corrigée qui va remplacer la version actuellement utilisée. Des améliorations ont été apportées à certaines fonctions de Smarty afin de permettre une génération plus rapide des pages, et les plug-ins spécifiques qui vont apparaître dans cette version ont tous été conçus comme des extensions du compilateur de templates afin de ne pas avoir d'incidence sur la rapidité. Grâce aux plugins et aux différentes versions d'une même page dans un même template, cela permettra par exemple à chaque module de disposer d'une version RSS de son contenu !
Le moteur de thèmes (qui génère la page "autour" du contenu) est egalement extensible. On pourrait aussi imaginer d'avoir un plugin qui récupère tout le contenu envoyé aux pages afin de générer les balises meta. Dans l'absolu cela permet d'étendre le système à l'infini. Le contenu envoyé aux templates est passé aux plugins, traité par ceux-ci puis renvoyé au template. Les objets de Xoops sont des composants qui contiennent un mini xoops_version.php (xo-version.php). A terme il n'y aura plus besoin de développer des blocs car le contenu de la page d'un module pourra être visualisé sous la forme d'un bloc (et réciproquement). Ce qui implique qu'un bloc pourra s'afficher pour une (ou n) page(s) et non plus forcément pour toutes les pages d'un module comme aujourd'hui. Chaque page définie dans le fichier xo-version.php donnera une liste des paramètres qu'elle attend ainsi que leur type. Cela permet d'avoir une protection et une désinfection quasi automatique des paramètres passés aux pages. La sécurité se trouvera donc encore renforcée. Il suffira de passer les paramètres reçus par la page à une fonction du
noyau afin qu'ils soient nettoyés et qu'un "cast" (transtypage) soit réalisé. Le clonage de modules ne devrait plus être nécessaire.
Deux modules simples comme un module de contact et un module de création de pages indépendantes devraient être proposés avec cette version afin de servir d'exemples pour les développeurs de modules.
Des normes seront édictées pour les développeurs de modules afin d'aboutir à une certification de ceux-ci tant en terme de qualité que de sécurité.
8. Multisites
Une gestion complete du multisite est egalement en route. Toutes les nouvelles fonctionalites sont en effet realisées afin d'etre compatible avec un futur support officiel du multisite (notemment le nouveau gestionnaire de configuration). Meme si ce support necessitera des modifications de vieilles parties du noyau et de nombreux tests avant de se voir qualifié d'"officiel", son utilisation devrait neanmoins etre possible dans un cadre restreint (par des utilisateurs experimentes) des les prochaines versions.
Pour l'utilisateur lambda qui n'utilise qu'un site cela n'a pas forcément d'intérêt au premier abord mais lorsque l'on réalise plusieurs sites cela permet de gagner énormément de temps lors des mises à jour par exemple. Cela permet aussi d'avoir 2 versions de son site, une version de production et une version de développement (dans laquelle sont par exemple visibles les messages de debug). L'équivalent du mainfile actuel contiendra un paramétrage global par défaut. Dans ce nouveau "mainfile", on ajoutera le paramétrage des autres sites gérés par le noyau mais il ne sera nécessaire de ne décrire que ce qui change.
Par exemple si le nom du serveur de base de données ne change pas, il ne sera pas nécessaire de le décrire pour un site du moment qu'il est décrit dans la configuration générale. En fait on va pouvoir "surcharger" la configuration par défaut pour les différents sites en ne mettant que ce qui change. Les différents sites traités par un même noyau vont hériter (comme en programmation objet) d'une configuration par défaut qu'ils pourront modifier. Un même site pourra donc être paramétré, sur une première adresse, pour ne pas utiliser le mode debug alors que le même site mais paramétré sur une autre url, lui utilisera le mode debug donc sans que les utilisateurs normaux puissent voir les messages affichés dans le debug. Le paramétrage de ce fichier se fera dans un premier temps manuellement, mais il est prévu de développer une interface pour en gérer le contenu.
9. Redirections
Les redirections seront "matérialisées" dans le système par une utilisation des sessions. De manière pratique, lorsqu'un module aura besoin de faire une redirection, les données de redirection (comme par exemple l'url vers laquelle faire la redirection) seront mises en session, ensuite une VRAIE redirection http sera lancée puis le système utilisera les données mises en session afin de poursuivre la navigation (c'est la même technique qu'a utilisé gijoe dans son hack). On gardera une compatibilité avec le système actuel de redirections mais l'action mise en oeuvre suite à la demande de redirection, sera différente.
10. Documentation
 Tout ce que réalise Skalpa est documenté (l'API du noyau notamment) Un gros effort a été fait afin de documenter au maximum les choses.
La documentation du noyau a été réalisée à partir d'une version modifiée de phpdoc pour avoir une documentation de meilleure qualité. Le code du noyau ainsi que les fonctionnalités peuvent changer tant que le noyau reste en version Alpha. La documentation sera donc publiée en même temps que la version. Si l'on compare à une voiture on pourrait dire que la documentation décrite ci-dessus concerne les pièces détachées et il restera à écrire comment réaliser l'assemblage de ces pièces.
Conclusion
Une version alpha 2 de Xoops 2.3 devrait être publiée prochainement pour être suivie quelques temps après de versions beta. Le délai et le nombre de beta dépendront des bugs trouvés et du temps nécessaire à leur correction. Les beta versions apportent une stabilité dans les fonctionnalités, seul le code du noyau peut changer pour faire des ajustements ou des corrections de bugs. Suite à un retard d'un mois, la sortie prévue de la première beta est prévue pour le mois d'avril 2006 Alors avec tout ce que vous avez lu, ne croyez vous pas que cette version majeure pourrait s'appeler Xoops 3 ?
Skalpa, Hervé et Christian
| 
