JCMS 6.0 : les principales nouveautés

1. Un double mode de stockage des données

Dans JCMS 5.7 et antérieure, les données gérées par JCMS étaient stockées en totalité dans JStore. Ces données concernaient à la fois des objets manipulés explicitement par les utilisateurs (contenu, catégorie, groupe, membre, ...) mais aussi un ensemble de petits objets techniques (note de workflow, suivi des lecteurs, archives, vote de sondage, ...). Ces objets pouvaient dans certains cas devenir très nombreux (p. ex. les notes de workflows) ou entrainer une volumétrie difficilement prédictible (p. ex. les votes de sondage).

La mécanique de persistance de JStore est basée sur la journalisation des changements dans le fichier store.xml. L'accroissement du fichier store.xml est donc fonction des écritures (création, modification ou suppression). Le temps de démarrage de JCMS et certaines fonctionnalités (JSync, accès à l'historique, ...) sont proportionnelles au poids de ce fichier. Aussi, afin de garder un volume d'écriture faible, il n'était pas recommandé de persister dans JStore des données fréquemment mises à jour (préférences utilisateurs, information d'usage, statistiques, ...)

Pour faire face aux problèmes de volumétrie et de mise-à-jour fréquente, JCMS 6 introduit un double système de stockage réparti entre JStore et JcmsDB, une base de données relationnelle. L'idée est d'utiliser le système de stockage le mieux adapté aux objets gérés. Certains des nouveaux types sont gérés dans JcmsDB, certains types existant ont été déportés dans JcmsDB et les autres continuent à être gérés avec JStore.

1.1 Hibernate

JCMS 6 utilise le framework de mapping objet/relationnel (ORM) Hibernate 3.2 pour gérer les données dans JcmsDB. Grâce à son système de dialectes, Hibernate offre à la fois une grande indépendance du code vis-à-vis de la base sous-jacente et de bonnes performances. Hibernate supporte la grande majorité des SGBDR. Néanmoins, en pratique, il reste certaines spécificités propres à chaque SGBDR qu'il faut prendre en compte (p. ex. mots-clés réservés, longueurs des noms des tables, unicité des index, gestion des CLOB, ...). Aussi, afin de garantir un bon fonctionnement, JCMS 6 a été certifié sur certains d'entre eux.

1.2 SGBDR supportés

JCMS est livré avec le SGBDR embarqué Derby. Pour un site JCMS gérant des volumétries raisonnables, ce SGBDR est pleinement fonctionnel. Cependant, l'usage de Derby n'est pas compatible avec la réplication par JSync. Aussi, pour les sites devant gérer des volumétries de données plus élevées ou nécessitant de la haute disponibilité, JCMS 6 est certifié sur trois SGBDR externes :

  • MySQL 5.1 (moteur de stockage InnoDB)
  • Oracle 10g
  • PostgreSQL 8.3

L'utilisation d'un SGBDR externe nécessite d'acquérir et d'installer le module correspondant.

Dans les prochaines versions, JCMS sera certifié sur d'autres SGBDR (notamment Microsoft SQL Server).

1.3 Réplication (JSync)

Le protocole de réplication JSync n'opère que sur les données gérées dans JStore. Le SGBDR interne Derby ne peut pas être utilisé dans une architecture répliquée. Il faut donc utiliser MySQL ou Oracle. Selon la topologie des serveurs et la disponibilité à garantir, il est possible de choisir différentes architectures.

1.4 Base de données centralisée

Le leader et les réplicas y accèdent concurremment. Cette architecture est très simple mais ne garantit pas la haute disponibilité de la base de données.

Fig. 1. Base de données centralisée

1.5 Base de données répliquée

Le leader et chaque réplica accèdent à des instances répliquées de la base de données. Cette architecture garantit la haute disponibilité de la base et permet de concevoir des topologies souples (p. ex. une instance dans une DMZ et une instance dans le LAN). Par contre, tous les SGBDR ne permettent pas des écritures simultanées sur les mêmes tables. De plus, la mise à jour des instances est relâchée et des conflits peuvent apparaître.

Fig. 2. Base de données répliquée

1.6 Base de données en Cluster

Le leader et les réplicas accèdent concurremment au cluster. Cette architecture garantit la haute disponibilité de la base mais n'est pas forcement disponible en standard pour tous les SGBDR. Cependant, pour la plupart, il existe des solutions de mise en cluster.

Pour JCMS 6, si la haute disponibilité de la base de données doit-être assurée, nous préconisons la solution en cluster.

Fig. 3. Base de données en cluster

2. Evolution du modèle de données

2.1 Homogénéité des deux modes de stockage

Un effort particulier a été mené pour assurer une grande homogénéité du modèle de données quelque soit le mode de stockage utilisé. Dans les espaces de travail, les contributeurs utilisent les mêmes interfaces pour naviguer, rechercher, consulter, créer, modifier ou supprimer des publications qui sont gérées dans JStore ou dans JcmsDB. De même, les développeurs disposent dans l'API de méthodes homogènes pour retrouver et rechercher des données, les enregistrer et placer des contrôles, quelque soit leur mode de stockage.

Néanmoins, des différences subsistent entre les données gérées dans JStore et celles gérées dans JcmsDB. Ces dernières disposent de moins de fonctionnalités que celle de JStore mais peuvent être beaucoup plus nombreuses et subir des mises-à-jour très fréquemment.

2.2 Types de données gérés dans la base de données

Les types internes suivants sont désormais gérés dans la base de données :

  • Note de workflow (WFNote)
  • Suivi des lecteurs (ReaderTacker)
  • Archives (ArchivedPublication)
  • Données additionnelles (ExtraDBData)
  • Avis (Review)

Les modules peuvent aussi gérer leurs données dans la base de données. C'est notamment le cas pour les modules suivants :

  • Module Forum DB
    • Types DBForumTopic, DBForumPost et DBForumWatcher
  • Module Sondage
    • Types PollVote
  • Module Commentaire DB
    • Type Comment
  • Module Favoris
    • Type Bookmark

Enfin, l'éditeur de type permet de choisir le type de stockage pour les types de contenu et les types de formulaire. L'icône jcms6000-store indique que les données de ce type sont stockées dans JStore et l'icône jcms600-db indique qu'elles sont stockées dans la base de données.

Fig. 4. Choix du stockage lors de l'édition d'un type

2.3 Identifiant des données

Toutes les données stockées dans la base implémentent l'interface DBData et possèdent un champ rowId contenant l'identifiant de l'enregistrement (row). Cet identifiant est un entier unique dans la table mais pas dans la base. Or, JCMS a besoin de travailler sur des identifiants uniques d'objets. JCMS 6 produit des identifiants uniques pour les objets gérés dans JcmsDB en concaténant l'identifiant de l'enregistrement (rowId) et le nom de la classe de l'objet. JCMS 6 peut ainsi les distinguer des identifiants JStore et les utiliser de la même manière dans les URL.

2.4 Relation entre la base de données et JStore

Certaines données stockées dans la base de données peuvent référencer des données stockées dans JStore (p. ex. une WFNote référence une publication et un membre). Ceci est géré par une colonne contenant l'identifiant de la donnée JStore. Si une données stockée dans la base doit-être référencée par JStore, on exploite son identifiant unique JCMS.

2.5 Champs communs

Toutes les données dérivant de la classes Data comporte un certains nombre de champs communs :

  • rowId
  • date de création
  • date de mise à jour
  • auteur

2.6 Publications

2.6.1 Contraintes sur les publications stockées dans JcmsDB

Il est possible de stocker des publications dans la base de données. Cependant, le stockage dans la base de données impose plusieurs contraintes par rapport au stockage dans JStore.

Voici les fonctionnalités supportées :

  • Auteur
  • Date de création, de modification, de publication, de mise à jour et d'archivage
  • Archivage
  • Cloisonnement par espace de travail
  • Workflow (pstatus)
  • Editeur de type
  • Champs entiers, booléens, décimaux, dates, textes et liens
  • Indexation Lucene
  • Recherche par type, date, espace de travail et auteur
  • Interface de gestion dans l'espace de travail
  • Export et JCMS Open API

Et les limites :

  • Pas d'historique des mises jour
  • Pas d'accès aux données supprimées
  • Pas de gestion de droits (lecture/écritures) par liste d'accès
  • Pas de champ catégories
  • Pas de champ multilingue
  • Pas de champ multivalué
  • Pas de gestion des liens inverses
  • Pas de gestion des versions
  • Pas de gestion des rôles ouverts
  • Pas de copie de travail
  • Pas d'opérations globales par le panier
  • Pas d'import incrémental
  • Pas de choix du gabarit d'affichage
  • Les champs textes (textarea) sont limités par défaut à 64Ko.

Aussi, on privilégiera le stockage dans JcmsDB pour les données techniques ou avec une structure simple (p. ex. les formulaires ou les types de contenu utilisateurs).

2.6.2 Champs communs

Les types de publication gérés dans JcmsDB comportent un jeu de champs communs :

  • rowId
  • date de création
  • date de mise à jour
  • auteur
  • titre (monolingue)
  • pstatus
  • identifiant de l'espace de travail
  • date de publication
  • date d'expiration
  • date d'archivage

2.6.3 Types de contenu utilisateur (User Content)

La part des contenus produits par les utilisateurs (forum, commentaire, avis, ...) a tendance à augmenter. Par ailleurs, la volumétrie de ces contenus est difficilement prévisible. Aussi, ces contenus seront de préférence stockés dans la base de données.

Afin de mieux organiser les contenus, JCMS 6 distingue les Contenus Utilisateurs des Contenus produits par les rédacteurs. Dans les espaces de travail, cela ce concrétise par une nouvelle rubrique.

Fig. 5. Interface de gestion des contenus utilisateurs

Dans l'API, une nouvelle sous-classe de Publication, UserContent, complète les trois classes existantes : Content, PortalElement et Form.

2.6.4 Gestionnaire des publications

L'interface de gestion des publications peut lister les publications d'un type donné (stocké dans JcmsDB ou dans JStore). Les données stockées dans JcmsDB sont marquées par l'icône jcms600-db.

Le gestionnaire de contenu ne liste pas des publications issues des deux modes de stockage. L'option Tous les types ne liste que les types de données stockés dans JStore. La plupart des publications stockées dans JcmsDB étant des contenus utilisateurs ou des soumissions de formulaires, en standard, elles n'apparaissent que dans ces interfaces.

2.6.5 Indexation et recherche

Les publications gérées dans JcmsDB sont indexées comme les publications gérées dans JStore. Une recherche peut porter à la fois sur des publications stockées dans JcmsDB et dans JStore. Les résultats peuvent donc contenir des publications issues des deux modes de stockage. Du fait des limites imposées sur les publications gérées dans JcmsDB, seuls les critères de recherche textuelle, par type, par auteur, par date, par état et par espace de travail peuvent être utilisés.

2.6.6 Interopérabilités

Les publications gérées dans JcmsDB peuvent être exportées et manipulées via JCMS Open API mais ne peuvent pas être importées.

2.7 ExtraDBData

JCMS 5.7.1 avait introduit les ExtraData qui permettent d'ajouter des champs sur des types existants. Les ExtraData étaient gérées sous forme d'une HashMap dans JStore. JCMS 6 introduit en complément les ExtraDBData qui sont l'équivalent des ExtraData mais stockées dans JcmsDB. Elles peuvent par exemple être utilisées pour gérer des préférences utilisateurs (p. ex. la configuration du bureau virtuel d'un utilisateur) ou pour stocker des informations d'usage (p. ex. la date de dernière connexion d'un utilisateur).

Consultez l'article sur les ExtraData et les ExtraDBData pour plus d'informations.

2.8 ReaderTracker

Les ReaderTracker permettent de suivre les lecteurs d'une publication donnée. Elles remplacent les ReaderNotes. Elles sont stockées dans JcmsDB et il n'y a donc plus de contrainte de volumétrie pour les utiliser. En plus de la date de première consultation de la publication, elle mémorise pour chaque lecteur la date de dernière consultation et le nombre de consultation. Elles mémorisent aussi les accès non authentifiés.

Fig. 6. Exemple de suivi d'un contenu

2.9 Archives

A chaque fois qu'une publication est archivée, une ArchivedPublication représentant cette archive est créée. Jusqu'à JCMS 5.7, ces objets étaient stockés dans JStore. Ce stockage était fonctionnel mais n'était pas optimum car l'un des objectifs de l'archivage était de réduire le nombre d'objets en mémoire. Avec JCMS 6, ils sont désormais stockées dans JcmsDB.

3. Ergonomie

JCMS 6 intègre les dernières évolutions technologiques disponibles pour les interfaces Web : glisser/déposer, Ajax, menus contextuel, suggestion, ...Ces fonctionnalités sont intégrées dans l'interface standard de JCMS mais aussi proposées sous forme de composants pouvant être intégrés dans les interfaces métiers.

3.1 Fenêtre modale

JCMS 6 propose un nouveau système de fenêtres modales, les lightbox. L'usage des ces nouvelles fenêtres modales a été généralisé dans JCMS 6 en remplacement des fenêtres natives du navigateur. Outre un meilleur rendu qui focalise l'utilisateur sur la fenêtre (en grisant le fond), ces fenêtres permettent de proposer des interfaces de validation ou de confirmation riches (mise en forme du texte, formulaire, ...)

 

Fig. 7. Exemple de fenêtre modale

3.2 Bulle d'aide

JCMS 6 intègre un nouveau système de bulles d'aide qui offre une bien meilleure ergonomie que l'attribut title qui était utilisé dans les précédentes versions de JCMS. Chaque bulle d'aide peut avoir une mise en forme spécifique, contenir du texte riche, des liens, des images, ... Par ailleurs, ces nouvelles bulles d'aide participent à l'amélioration des performances en allégeant le poids de pages. Le contenu de la bulle n'est chargé que lorsque l'utilisateur la fait apparaître.

Fig. 8. Exemple de bulle d'aide (verrouillage d'un document)

3.3 Pager

La présentation du système de pagination, ou pager, de JCMS 6 a été revue et il est possible de définir de nouvelles présentations par gabarit JSP et par feuille CSS.

Le pager est compatible avec la technologie Ajax-Refresh de JCMS 6 qui peut rafraichir uniquement la zone paginée à chaque changement de page. Ceci est notamment valable dans les Portlets Requête/Itération ou les résultats de recherche. Malgré ce rafraichissement partiel, le code HTML du pager est aussi compatible avec les robots d'indexation pour garantir un bon référencement.

Consultez l'article sur la pagination avec le tag <jalios:pager> pour plus d'informations.

3.4 Portlet Calendrier

Dans les versions précédant JCMS 6, la portlet Calendrier (en vue mois) était l'une des plus consommatrice en temps de traitement et en poids HTML. Cette consommation était d'autant plus importante qu'il y avait beaucoup d'événements présents dans le mois affiché.

Avec JCMS 6, la portlet Calendrier utilise les nouvelles bulles d'aide pour ne charger le détail des événements que lorsque l'utilisateur laisse le pointeur de la souris sur un jour. Ainsi le poids et le temps de traitement de l'affichage sont relativement constants. Par ailleurs, la portlet utilise la technologie Ajax-Refresh pour naviguer rapidement dans le calendrier (par mois, par semaine, par jour, ...)

Enfin, la portlet met désormais en avant, par un fond de couleur, les jours pour lesquels il existe des événements qui concernent l'utilisateur.

Fig. 9. La portlet Calendrier

3.5 Edition du portail

Un menu contextuel est présent sur chaque portlet. Il permet d'agir rapidement sur la portlet (édition, suppression, déplacement, ...) ainsi que sur son paramétrage : choix du gabarit, de l'habillage, du cache, ...

L'interface d'édition du portail de JCMS 6 offre le déplacement des portlets par glisser/déposer. Cette fonctionnalité est disponible pour les portlets contenues dans des Portlets Colonnes ou dans des Portlets JSP Collection. Pour rester compatible avec l'ensemble des navigateurs supportés, le déplacement par glisser/déposer n'est pas disponible pour les portlets contenues dans les Portlets Ligne. Il faut utiliser le menu contextuel pour déplacer ces portlets.

Fig. 10. Nouvelle interface d'édition du portail

3.6 Autres nouveautés

3.6.1 Gabarit menu déroulant

Le gabarit d'affichage en menu déroulant de la Portlet Navigation a été complètement réécrit afin d'être plus portable, accessible et aisément remaniable en CSS.

3.6.2 Gabarit détaillé/résumé

La Portlet Requête/Itération dispose d'un nouveau gabarit d'affichage présentant le premier contenu en affichage détaillé et les suivants en affichage synthétique.

3.6.3 Gabarit d'affichage des membres

Le gabarit d'affichage détaillé d'un membre a été mis-à-jour pour offrir une meilleure lisibilité. En complément des informations du membre, la date de dernière connexion est affichée.

Fig. 11. Nouveau gabarit d'affichage des membres

3.6.4 Entête des publications

La barre d'icônes en entête des publications (imprimer, envoyer à un ami, ...) dispose d'une nouvelle présentation plus discrète et plus facilement extensible par les modules. Par exemple, le module Favoris ajoute un icône dans cette barre. Cet icône permet de placer le contenu affiché dans ses favoris.

3.6.5 PDA

Avec JCMS 6, en plus de la page d'accueil PDA, il est possible de préciser une page d'accueil spécifique pour un PDA en particulier. Pour cela, il suffit de déclarer la JSP d'accueil pour ce PDA via la propriété small-device.home.Name avec Name le nom du PDA tel qu'il est décodé par JCMS (p. ex. small-device.home.IPhone).

Par ailleurs, JCMS 6 supporte la détection automatique du navigateur BlackBerry en plus des navigateurs déjà supportés (iPhone, Windows Mobile, i-Mode, OperaMini et Android).

3.6.6 Avis

Le type Avis est maintenant un type généré dérivant de la classe UserContent et stocké dans JcmsDB.

3.6.7 Rôles ouverts

Dans les formulaires d'édition, le choix des membres pour les rôles a été revu : les membres sont triés par ordre alphabétique et seuls les rôles correspondant à l'état courant sont proposés.

3.6.8 Historique des versions

Dans l'historique des versions, la comparaison de champ texte propose, en plus de l'affichage des changements, un affichage de comparaison deux à deux du contenu du champ.

3.6.9 Correcteur orthographique

JCMS 6 intègre la dernière version du correcteur XMLMind Spell Checker 1.3. Par ailleurs, il est possible d'ajouter de nouveaux dictionnaires (dans le répertoire WEB-INF/jalios/dictionaries/xsc/ ou via propriété spellchecker.xsc.dict-path). Enfin, il est possible de brancher un autre correcteur orthographique (en développant une classe implémentant com.jalios.jcms.spellchecker.SpellChecker et déclarée via la propriété spellchecker.class).

3.6.10 Boîte des avertissements

Afin d'offrir un retour rapide des événements survenus sur le site, une boîte Avertissement a été ajoutée dans l'espace d'administration de JCMS 6. Celle-ci affiche les 5 derniers avertissements survenus.

Fig. 12. Boîte des avertissements

3.6.11 Export des changements en CSV

Afin d'aider les phases de migration, le gestionnaire des changements de JCMS 6 propose d'exporter au format CSV l'ensemble des fichiers ayant subi un changement afin de gérer cette liste dans un tableur.

3.6.12 TinyMCE 3

JCMS 6 intègre la dernière version majeure de l'éditeur de texte riche TinyMCE 3.

4. Modules

4.1 Module Bureau Virtuel

Ce module complémentaire est disponible en option dans le tarif JCMS.

L'objectif du bureau virtuel est de proposer aux utilisateurs un portail personnalisé ou ils peuvent choisir et assembler à leur guise les services qu'ils souhaitent utiliser.

Le webmaster est libre de proposer les services qu'il souhaite :

  • des informations internes : les nouveautés, les projets en cours, les utilisateurs connectés, ...
  • des informations externes : des flux RSS préconfigurés, des flux RSS libres (l'utilisateur peut saisir l'URL des flux RSS qu'il souhaite lire)
  • des outils personnalisés : agenda, favoris, workflow, gestion des documents, ...
  • des portlets métiers
  • des widgets : via la Portlet Widget il est possible d'utiliser la plupart des widgets proposés par Google (cours de la bourse, météo, cartes et plans, trafic routier, ...). Il est aussi possible de laisser l'utilisateur choisir les widgets qu'il souhaite utiliser

Les utilisateurs peuvent personnaliser leur bureau en plaçant les services dans des onglets, en choisissant le nombre et la taille des colonnes pour chaque onglet et en sélectionnant un habillage pour leur bureau.

Fig. 13. Exemple de bureau virtuel

L'ergonomie du bureau virtuel est très proche de celle des outils tels que Netvibes ou iGoogle. Chaque service peut être déplacé par un simple glisser/déposer. Un utilisateur peut choisir le titre et la couleur de la boîte du service. Certains services proposent plus d'options (p. ex. le service RSS permet de choisir le nombre d'articles à afficher).

Chaque service est matérialisé par une portlet et une couche de personnalisation. Les portlets sont les mêmes pour tous les utilisateurs. La couche de personnalisation de chaque service et le paramétrage du bureau sont propres à chaque utilisateur et sauvegardés dans JcmsDB.

Fig. 14. Paramétrage d'un service du bureau virtuel

Pour proposer un nouveau service, il suffit de créer une nouvelle portlet et de lui positionner l'aptitude Bureau Virtuel (dans l'onglet avancé du formulaire d'édition de la portlet). Il est aussi possible de définir des droits de consultation pour limiter les utilisateurs autorisés à utiliser ce service.

De nombreuses portlets de JCMS peuvent être utilisées dans le bureau virtuel, notamment :

  • Portlet RSS
  • Portlet Workflow
  • Portlet Calendrier
  • Portlet Favoris
  • Portlet Notification
  • Portlet Requête/Iteration
  • Portlet Membres authentifiés
  • Portlet Explorer
  • Portlet Google Talk
  • Portlet Widget
  • Portlet Exchange
  • ...

Les services peuvent être proposés soit en paramétrant l'une de ces portlets, soit en développant une nouvelle portlet (ou un simple JSP en utilisant la Portlet JSP).

Pour en savoir plus, consultez l'article Présentation et Utilisation du Bureau Virtuel.

4.2 Module Favoris

Ce module complémentaire est disponible en option dans le tarif JCMS.

Le module Favoris propose la Portlet Favoris qui remplace celle des précédentes versions de JCMS. Les favoris sont propres à chaque utilisateur. Afin de supporté de grandes volumétrie, ils sont stockés dans JcmsDB. Les favoris peuvent être soit sur des URL de sites externes, soit des liens vers des publications internes. Pour les sites externes, l'icône du site (favicon) est affiché. Pour les publications internes l'icône d'édition est ajoutée.

Pour ajouter des publications internes, on peut soit utiliser l'interface d'ajout de favoris soit cliquer sur l'icône Ajouter à mes favoris dans la barre d'icônes présente dans l'affichage de toute publication.

Fig. 15. La portlet Favoris

4.3 Modules Forum

Ces modules complémentaires sont disponibles en option dans le tarif JCMS.

La gestion du forum a été déportée en module. Deux modules forums accompagnent JCMS 6 : Forum JStore et Forum DB

Le module Forum JStore reprend a l'identique la fonction Forum de JCMS 5.7.

Le module Forum DB gère l'ensemble des discussions dans JcmsDB. Il peut donc prendre en charge une plus grande volumétrie de discussion. L'objet DBForum englobant un ensemble de discussions reste dans JStore. Des restrictions ont été introduites suite au passage dans JcmsDB :

  • les discussions ne sont plus catégorisées (mais les forums peuvent l'être)
  • il n'est plus possible d'attacher un document à un message
  • en cas de migration, les identifiants des discussions étant changés, les URL des anciennes discussions ne sont plus valident

4.4 Module Sondage DB

Ce module complémentaire est disponible en option dans le tarif JCMS.

La fonctionnalité Sondage a été externalisée dans le module DB Poll. Pour faire face à de grande volumétrie, tous les votes sont désormais stockés dans JcmsDB. La portlet sondage et l'affichage de tous les sondages ont été complètement revus afin d'offrir une présentation plus élégante et plus accessible. Enfin, il est possible d'associer une image à un sondage.

Fig. 16. La portlet Sondage

4.5 Module Exchange

Ce module complémentaire est disponible en option dans le tarif JCMS.

Ce module propose quatre portlets affichant des informations issues d'un serveur Microsoft Exchange. L'accès Outlook Web Access (OWA) est nécessaire.

  • la boîte de réception mail : la portlet affiche les mails reçus et propose un lien pour les consulter sur OWA ;
  • la liste des tâches : la portlet affiche la liste des tâches et permet des les éditer ;
  • le calendrier : la portlet affiche les événements dans une Portlet Calendrier ;
  • Les contacts : la portlet affiche la liste des contacts, permet de faire des recherche et de les éditer.

     

Fig. 17. Les portlets Exchange

4.6 Autres modules

4.6.1 Module Commentaire DB

Ce module complémentaire est disponible en option dans le tarif JCMS.

Le module Commentaire DB remplace le module Commentaire de JCMS 5.7. Il reprend les mêmes fonctionnalités que ce dernier mais, comme son nom l'indique, les commentaires sont stockés dans JcmsDB.

4.6.2 Module Import de document

Ce module complémentaire est disponible en option dans le tarif JCMS.

Ce module permet de charger automatiquement des documents dans JCMS à partir d'un répertoire donné. A chaque fois qu'un nouveau fichier (ou une nouvelle version) arrive dans ce répertoire, il est déposé dans JCMS sous forme d'un document. Des informations contextuelles sont positionnées pour les DataController afin de pouvoir déclencher des traitements spécifiques à cet import (p. ex. catégorisation, droits, indexation spécifique, ...)

4.6.3 Module Portlet de dépôt

Ce module complémentaire est disponible en option dans le tarif JCMS.

Cette portlet offre une interface très simple pour le dépôt de document. L'utilisateur n'a qu'à sélectionner le fichier qu'il souhaite déposer. S'il estime que le téléchargement va prendre du temps, il peut demander à être notifié par mail à la fin du téléchargement. La portlet peut être paramétrée pour positionner des catégories et des droits par défaut. Enfin des informations contextuelles sont positionnées pour les DataController afin de pouvoir déclencher des traitements spécifiques à ce dépôt.

Fig. 18. La portlet de dépôt

4.6.4 Module Google Maps

Ce module complémentaire est disponible en option dans le tarif JCMS.

Ce module place des données JCMS sur une carte Google Maps. Un champ « Géolocalisation » est ajouté dynamiquement sur les données déclarées comme pouvant être géolocalisées. La géolocalisation peut se faire soit en indiquant les coordonnées longitude/latitude, soit en indiquant une adresse postale ou un lieu. Les données à présenter sont indiquées dans la Portlet GoogleMaps via une requête. La portlet dispose de différentes options permettant d'agir sur la présentation (dimension, centrage, zoom par défaut, vue par défaut, interface de contrôle, ...)

Fig. 19. La portlet GoogleMaps

4.6.5 Module carrousel

Ce module présente une série d'images dans un carrousel. Plusieurs modes de présentation et de défilement sont proposés.

Fig. 20. Exemple de carrousel

4.6.6 Compatibilité des modules JCMS 5.7

Les modules développés pour JCMS 5.7 doivent généralement être adaptés pour fonctionner sur JCMS 6. Dans le cas le plus simple, il suffit généralement de recompiler les classes pour être compatible avec les nouvelles signatures des méthodes (types génériques). Pour les cas plus évolués il faut revoir les déclarations des gabarits et adapter certains codes Java et JSP.

La plupart des modules Jalios existant pour JCMS 5.7 sont disponibles en version compatible pour JCMS 6.

5. Interopérabilité

On entend par interopérabilité la capacité à rendre JCMS compatible avec les autres composants du système d'information de l'entreprise. Dans ce cadre, JCMS peut alors être vu comme un service offrant les fonctionnalités de gestion de contenu et de gestion documentaire. JCMS 5.7 avait commencé à répondre à ce besoin en introduisant le mécanisme d'import/export permettant de faire communiquer un site JCMS avec d'autres sites.

JCMS 6 enrichit ses capacités d'interopérabilité en fournissant une API de type Web Service, un système d'authentification unitaire (AuthKey) et la préservation des références lors des imports.

5.1 JCMS Open API

JCMS 6 intègre JCMS Open API, une API web service REST offrant un accès aux fonctionnalités de JCMS. Les web services REST sont une alternative à SOAP et visent notamment à simplifier les principes en capitalisant sur les fondamentaux du Web (HTTP et URI). Il n'existe pas de norme REST mais plutôt des principes. JCMS Open API respecte ces principes tels qu'ils sont présentés dans l'ouvrage RESTFul Web Services.

JCMS Open API permet actuellement de :

  • Consulter, créer, modifier et supprimer toute donnée de JCMS (publication, catégorie, membre, ...)
  • Faire des recherches sur les publications
  • Consulter les structures des types de publication et des workflow
  • Consulter l'état du site (environnement, état des données, des synchronisations JSync, sessions ouvertes, ...)
  • Arrêter / Démarrer les écritures
  • Déclencher les imports

Les modules peuvent ajouter leur propre accès JCMS Open API.

Les données renvoyées par les méthodes de JCMS Open API sont en XML avec la même structure que les flux d'export.

Exemples de requêtes Open API :

Ressource Résultat
/rest/data/Article Retourne l'ensemble des descriptions XML de tous les articles contenus dans le site.
/rest/data/j_300 Retourne la description XML de l'article d'identifiant j_300.
/rest/data/j_2 Retourne la description XML du membre d'identifiant j_2.
/rest/search ?types=Article&cids=c_1234 Retourne la description XML de tous les articles rattachés à la catégorie c_1234.
/rest/admin/status Retourne la description XML de l'état courant du site.

Les fonctionnalités de JCMS Open API seront enrichies au gré des nouvelles versions de JCMS. Il est notamment prévu de pouvoir piloter la synchronisation JSync , la gestion des caches, la gestion des index de recherche et le déploiement.

Pour en savoir plus, consultez l'article JCMS 6.0 : JCMS Open API.

5.2 JCMS Open API Client

JCMS Open API est indépendant de tout langage. Il est donc possible de piloter un site JCMS depuis des scripts Perl, PHP, shell (en utilisant par exemple cURL), ... Afin de simplifier le développement pour les développeurs Java, Jalios fournit JCMS Open API Client. Il s'agit d'une bibliothèque Java simplifiant les requêtes à Open API. Elle fournit notamment un mécanisme permettant de gérer l'authentification par session, une navigation XPath dans les résultats et une API d'écriture simplifié.

Pour en savoir plus, consultez l'article JCMS 6.0 : JCMS Open API.

5.3 AuthKey

Certains traitements liés à l'interopérabilité nécessitent d'être authentifiés (p. ex. écriture dans les données, opérations d'administration, accès à un flux RSS situé sur un site privé, ...) Une première solution consiste à gérer l'authentification via la session J2EE. Cette solution impose que le client effectue une phase d'authentification et qu'il préserve le cookie de session J2EE. Ceci est faisable avec JCMS Open API Client mais ce n'est pas le cas avec le processus d'import de JCMS et encore moins avec des clients externes à JCMS. Par exemple, cette approche n'est pas adaptée pour intégrer dans un client RSS, un flux RSS situé sur site JCMS privé.

Pour répondre à ce besoins, JCMS6 propose un nouveau mécanisme d'authentification unitaire. Le principe consiste à ajouter dans l'URL effectuant le traitement, un paramètre contenant une clé d'authentification (ou authKey). Cette clé est produite pour un membre donné et n'est valable que pour cette URL et pour une durée donnée. Lorsqu'on accède à l'URL, JCMS 6 décode la clé et retrouve le membre signataire, il exécute ensuite le traitement demandé au nom de ce membre. Dans l'exemple du flux RSS ci-dessus, il suffit donc de générer la clé d'authentification pour l'URL du flux RSS et de l'ajouter dans cette URL (paramètre authKey).

La clé d'authentification peut-être produite pour une URL précise ou pour un préfixe d'URL. Dans ce dernier cas, il pourra être réutilisé pour toute URL commençant par ce même préfixe. Par exemple, dans le cas de JCMS Open API, il est possible de produire une clé d'authentification pour toutes les requêtes commençant par /rest/data/.

JCMS 6 propose dans l'espace d'administration une nouvelle interface permettant de générer les clés d'authentification. Outre l'indication de l'URL et du membre signataire, il est possible de définir d'autres restrictions : durée de validité, contrôle de l'adresse IP de l'appelant et les méthodes HTTP autorisée.

Fig. 21. Interface de génération des clés d'authentification

5.4 Import/Export

JCMS 6 complète le mécanisme d'import/export introduit avec JCMS 5.7. Lors des imports, JCMS rétablit les références entre contenus importés. Ainsi, si on importe un contenu ayant des liens vers d'autres contenus, les liens seront valides dès lors que les contenus pointés ont aussi été importés. JCMS 6 prends en compte tous les types de liens sur contenu : champ liens, lien Wiki, lien HTML (champ wysiwyg).

Enfin, l'ExportPolicyFilter a été enrichi pour permettre le développement de contrôles plus fins lors de chaque export.

6. Accessibilité

Un effort important a été mené pour rendre le front-office de JCMS 6 le plus accessible possible. La notion d'accessibilité reste encore floue : plusieurs acteurs proposent des référentiels d'accessibilité (WAI/WCAG, RGAA, AccessiWeb, ...). Heureusement, il existe un fort recouvrement dans les critères de ces différents référentiels. Pour JCMS 6, nous avons opté pour les critères du RGAA, qui sont bien documentés et reprennent en grande partie ceux de WCAG.

Il est important de noter que les problématiques d'accessibilité ne sont pas à la seule charge du CMS. Elles doivent être prises en compte sur l'ensemble du projet : de la phase de conception, notamment la charte graphique, jusqu'à la phase d'exploitation, en formant les contributeurs aux problématiques d'accessibilité.

Le traitement de l'accessibilité dans JCMS 6 a donc consisté à fournir des gabarits, des composants et des fonctionnalités qui facilitent le respect des critères d'accessibilités. On peut notamment citer :

  • Une complète conformité au standard XHTML ;
  • Une utilisation systématique des CSS pour la présentation ;
  • Une feuille CSS adapté au média print ;
  • La gestion de zone de texte invisible pour placer des informations réservées aux lecteurs d'écran et aux navigateurs textuels ;
  • Un enrichissement des informations sur les fichiers (types, poids, unités, ...) ;
  • Des formulaires compatibles avec les lecteurs d'écran ;
  • Indication du changement de langue dans les champs ;
  • Intégration de TinyMCE 3, qui offre un bon respect des critères d'accessibilité.

Le module DevTools contient un nouvel outil facilitant la tâche de validation d'un site. Il produit sur une unique page l'ensemble des éléments présents sur le front-office : portlets, habillages (skins), gabarits d'affichage détaillés et synthétiques, formulaires, ... Il est alors possible de lancer une validation de cette page avec des outils tels que TotalValidator qui passe en revue toute une série de critères (XHTML, WCAG, ...)

Fig. 22. Exemple de validation avec Total Validator

Pour en savoir plus, consultez l'article JCMS et l’accessibilité.

7. Des performances accrues

7.1 Optimisation du front-office

7.1.1 Ajax

L'utilisation de la technologie Ajax améliore non seulement l'ergonomie mais aussi les performances. Le chargement partiel de certaines zones de l'interface et le chargement à la demande de l'utilisateur réduisent la taille des pages transférées. Seul le contenu nécessaire est chargé et les chargements suivants sont réduits.

7.1.2 Optimisation du chargement des JavaScripts

L'ouvrage High Performance Web Sites, qui compile les travaux de recherche menés par l'équipe Exceptional Performance de Yahoo!, présente 13 règles pour optimiser le chargement des pages. L'extension Firefox YSlow permet de vérifier le respect des 13 règles sur une page donnée.

JCMS 5.7 respectait déjà une partie de ces règles (placement des CSS en début de page, fusion des fichiers CSS et JavaScript, compression Gzip, ...).

JCMS 6 complète cette intégration en fournissant une couverture plus large dans la fusion des JavaScript et en plaçant les JavaScript en fin de page (règle 6). Le respect de cette dernière règle offre à l'utilisateur une impression de chargement plus rapide de la page. Le chargement des JavaScript bloque tous les autres chargements (images, css, ...). Ainsi, en repoussant leur chargement à la fin, le navigateur dispose rapidement de toutes les ressources nécessaires pour effectuer le rendu de la page.

Le placement des JavaScript en fin de page a des conséquences sur l'intégration des JavaScript spécifiques de l'application. Les fichiers JavaScript doivent être inclus dans la page avec la méthode context.addJavaScript() et les scripts contenus directement dans les pages doivent être revus afin de remplacer la balise <script> par le tag <jalios:javascript>.

Grâces aux optimisations menées par les ingénieurs de Jalios, les sites JCMS 6 obtiennent généralement la note A aux règles 5 (Put CSS at the top), 6 (Put JS at the bottom), 7 (Avoid CSS expression), 9 (Reduce DNS lookup), 11 (Avoid redirect) et 12 (Remove duplicate scripts). La fusion des javascripts et des CSS donne généralement une bonne note à la règle 1 (Make fewer HTTP requests). La note A peut-être atteinte sur les règles 3 (Add an Expires header) et 4 (Gzip components) en configurant correctement le serveur Web. Enfin la règle 2 (Use a CDN) ne concerne pas directement JCMS et elle est inadaptée pour la majorité des sites car elle impose de faire distribuer les ressources statiques par un Content Delivery Network.

Fig. 23. Exemple de rapport YSlow

7.2 Réduction du poids des données

Au fil du temps, les données de JCMS avaient eues tendance à prendre de l'embonpoint. Dans JCMS 5.7, la création d'une publication vide consommait 1460 octets, celle d'un membre 880 octets. Dans JCMS 6, tous les objets ont subi une cure d'amaigrissement. Le tableau ci-dessous indique les gains obtenus.

  JCMS 5.7 (octet) JCMS 6.0 (octet) Gain (octet)
Data 207 91 116
Member 880 212 668
Publication 1460 275 1185
FileDocument 1690 379 1311
Article 300 1570
PortletQFE 2105 538 1567
TestType (87 champs) 4536 830 3706

Cette réduction a un effet direct sur la mémoire consommée et permet de charger plus d'objets. Elle améliore aussi les performances de JCMS. La réduction a été faite en différant l'allocation de nombreuses collections (Set et Map), ce qui a fortement réduit le nombre d'objets alloués. Le garbage collector ayant moins d'objet à gérer, il se déclenche moins souvent et les traitements prennent moins de temps.

Il est difficile de donner un ratio précis de réduction induit par le passage d'un site sur JCMS 6. D'une part, la réduction porte sur le poids minimum des objets. D'autre part, elle est aussi impactée par le déport des objets dans JcmsDB. A titre d'exemple, sur un site de taille modeste (16000 objets) avec moins de 2% d'objets déportés en base de données, lors du passage de JCMS 5.7.4 à JCMS 6 la consommation mémoire au chargement du store a été réduite de 30%. Le site JaliosXperience, dont 85% des objets ont été déportés en base de données, a vu sa consommation mémoire au chargement divisée par trois.

7.3 Accès à l'historique des versions

JCMS permet de consulter l'historique des versions de toute publication. Pour construire cet historique, JCMS relit partiellement le store afin de retrouver l'ensemble des modifications subies par la publication. Depuis les versions 5, JCMS optimise la lecture du store en faisant un premier saut jusqu'à la première opération portant sur la publication. Néanmoins, cette lecture peut-être est coûteuse si le store est gros et d'autant plus que la publication consultée est ancienne. JCMS 6 améliore les performances en utilisant un cache sur les historiques de version. Ainsi, toutes les opérations de navigation dans l'historique (consultation d'une version précédente ou comparaison deux à deux) sont immédiates.

7.4 Accès à la base de données

JStore gère ses objets en mémoire ce qui lui confère d'excellentes performances. JStore ne charge qu'une seule fois un objet et dispose de nombreux index contenant les références des objets (p. ex. l'ensemble des objets d'une certaines classe, l'ensemble des publications attachées à une catégorie, l'ensemble des publications d'un membre, ...) L'accès aux données et donc non seulement rapide mais n'entraine aucune création d'objets. En conséquence, la consommation mémoire liée à JStore est très stable et ne varie qu'en fonction des écritures (qui sont très nettement inférieures aux lectures). Ceci permet à la fois de définir l'allocation mémoire nécessaire au site et aussi d'alléger le travail du garbage collector.

Dans JCMS 6, l'accès aux données stockées dans JcmsDB se fait via Hibernate. Lors d'une requête à JcmsDB, toute une série de traitements est déclenchée :

  1. JCMS construit une requête Hibernate (Criteria ou HQL)
  2. Hibernate analyse cette requête et construit la ou les requêtes SQL optimisées pour le SGBDR sous-jacent (grâce aux dialectes),
  3. Hibernate ouvre une connexion au SGBDR et exécute la requête SQL (via JDBC)
  4. Le SGBDR traite la requête et retourne la liste des enregistrements correspondant
  5. Hibernate parcourt cette liste et construit pour chaque enregistrement l'objet Java correspondant.

Ce mécanisme fait donc intervenir des entrées/sorties (connexion à la base, transfert des résultats), du calcul et de l'allocation mémoire dans la webapp. Pour garantir de bonnes performances et une consommation mémoire réduite sur les données gérées dans JcmsDB, plusieurs optimisations ont été faites dans JCMS 6.

7.4.1 Un modèle relationnel simple

Les données gérées en standard par JCMS dans JcmsDB utilisent un modèle très simple (une table par classe) avec très peu de relations entre tables car la structure est gérée dans les objets du store. Les requêtes SQL sont donc très simples et ne nécessitent généralement aucune jointure.

7.4.2 Index sur les colonnes

Les index sont une technique éprouvée pour améliorer les performances d'une base de données. Ils évitent au SGBDR d'avoir à faire un parcourt complet de tous les enregistrements d'une table. En contrepartie, ils occasionnent des traitements supplémentaires lors des écritures et augmentent la consommation mémoire et/ou disque du SGBDR.

Les SGBDR positionnent un index sur la clé primaire d'une table (rowId dans le cas de JCMS). En complément, sur toutes les tables générées par Hibernate, JCMS déclare des index sur les principales colonnes intervenant dans les clauses WHERE des requêtes SQL. Par exemple, le type Avis comporte des index sur les colonnes authorId, pstatus, workspaceId et publicationId. Ainsi lorsqu'un contributeur consulte dans son espace de travail la liste de ses avis à l'état publié les index workspaceId, authorId et pstatus et peuvent être utilisés.

7.4.3 Tri par défaut sur la clé primaire

Le tri des résultats d'une requête SQL (clause orderby) est une opération habituellement coûteuse. Une technique d'amélioration consiste à avoir un index présent sur la colonne de tri. Dans JStore, le tri par défaut est un tri sur la date de création (cdate). Afin d'éviter d'avoir à déclarer un index sur la colonne cdate de toutes les tables, le tri par défaut opère sur la clé primaire (rowId) qui est naturellement indexée. Le rowId n'est pas une date mais possède la même propriété d'évolution croissante qui garantit un tri identique à la cdate.

7.4.4 Pagination des résultats

Pour permettre à un utilisateur de naviguer dans des volumes important, une technique consiste à paginer les résultats. Le système de pagination de JCMS (<jalios:pager>) a été optimisé pour permettre de paginer des données issues de JcmsDB de façon performante même pour les tables très volumineuses.

7.4.5 Optimisation du nombre de requêtes SQL

L'ensemble du code de JCMS (classes Java et JSP) a été analysé pour optimiser le nombre et le type de requêtes SQL.

Les requêtes de comptage (count(*)) sont privilégiées quand il s'agit de savoir si il y a des données correspondant à certains critères.

Des caches ont été mis en place sur certaines données (p. ex. le nombre d'avis associés à une publication).

7.4.6 Pool de connexions

JCMS 6 est livré avec le gestionnaire de connexion C3P0 qui est par défaut désactivé. Pour l'activer, il suffit de décommenter dans le fichier WEB-INF/data/custom.prop les lignes commençant par hibernate.cfg.common.prop.hibernate.c3p0 puis redémarrer JCMS.

8. Outils pour les développeurs

8.1 Ajax-Refresh

La technologie Ajax permet de construire des interfaces web plus réactive en ne modifiant qu'une partie de la page la où auparavant il fallait recharger la page entière. Même si des frameworks existent, Ajax n'est pas toujours simple à mettre en œuvre et nécessite généralement des compétences en développement JavaScript. Par ailleurs, ce chargement partiel et retardé du contenu des pages modifie la cinématique des échanges ce qui entraine de nombreuses questions :

  • Comment gérer l'historique de navigation ?
  • Comment continuer à garantir un bon référencement ?
  • Comment respecter les critères d'accessibilité ?
  • Comment préserver le contexte d'exécution (catégories courante, portail courant, ...) ?
  • Comment rebrancher les événements Javascript et charger les feuilles CSS ?

Pour faire face à ce besoin et prendre en compte ces questions, les ingénieurs de Jalios ont élaborés Ajax-Refresh qui simplifie l'utilisation de la technologie Ajax pour un cas précis : le rafraichissement d'une partie de la page (p. ex. une portlet). Il ne s'agit pas d'un nouveau framework Javascript mais d'une modèle déclaratif avec une simple convention de nommage.

Dans le cas général, la zone à rafraichir doit-être identifiée par une balise <div class="ajax-refresh-div">. Les déclencheurs du rafraichissement peuvent être des liens ou des boutons qui doivent être identifiés avec la classe CSS ajax-refresh. Il est possible de demander une confirmation avant le rafraichissement (classe CSS confirm). La zone est rafraichie avec le contenu de la JSP ciblée par le lien ou par le formulaire. Lors de l'appel Ajax de la JSP (XmlHttpRequest), JCMS 6 préserve le contexte d'exécution (authentification, catégorie courante, portail courant, ...). Dans le cas ou le rafraichissement concerne de la navigation (p. ex. le pager), l'historique du navigateur est contrôlé afin de permettre de revenir sur l'état précédent de la page. Les liens déclenchant les rafraichissements sont des liens standards. Ajax-Refresh les enrichit dynamiquement. Ainsi, les critères d'accessibilité et de référencement peuvent être respectés.

Pour les développeurs de portlets, l'utilisation est encore plus simple puisque toute portlet JCMS 6 est préconfigurée pour être rafraichie par Ajax-Refresh. Le développeur n'a plus qu'à indiquer avec la classe CSS ajax-refresh les liens et les boutons déclenchant les rafraichissements.

Exemple pour le cas général :

<div class="ajax-refresh-div">
<%= new Date() %><br/>
<a class="ajax-refresh" href="testLink.jsp">Refresh</a>
</div>

Exemple pour une portlet :

<%@ include file="/jcore/doInitPage.jsp" %>
<%= new Date() %>
<a class="ajax-refresh" href="<%= ServletUtil.getResourcePath(request) %>">Refresh</a>

Un article présentant en détail la technologie Ajax-Refresh sera bientôt diffusé sur ce site.

8.2 Bibliothèques JavaScript

JCMS 6 simplifie la tâche des développeurs en intégrant un ensemble de bibliothèques JavaScript, notamment

  • Prototype 1.6 : une toolkit Javascript offrant une API de haut niveau et homogène quelque soit le navigateur sous-jacent ;
  • Script.aculo.us 1.8 : une librairie permettant de faire du glisser/déposer, de la recherche prédictive (auto-completion) et des effets visuels.

8.3 Sprites

Dans une page HTML il n'est pas rare de trouver plusieurs dizaine d'images et icones, chacune nécessitant une requête HTTP. Or, la première règle de High Performance Web Site vise à réduire le nombre de requêtes HTTP. Pour cela, une solution consiste à regrouper les icônes en une seule image et à utiliser des règles CSS pour faire apparaître l'icône désirée.

Dans cet esprit, JCMS 6 intègre le jeu d'icônes FamFamFam Silk Set, plus de 700 icônes, en une seule image. Pour afficher l'une de ses icônes il suffit donc d'indiquer son nom dans la classe CSS de l'image.

Exemple :

jcmsContext.addCSSHeader("css/fff-sprite.css");
<img class="icon ss_sprite ss_add" src="s.gif" alt="Add"/>

Le module DevTools fournit une page listant l'ensemble des icônes et le nom de la classe CSS associée.

8.4 Gabarit des types

JCMS 6 dispose d'un nouveau mécanisme permettant la sélection dynamique des gabarits d'affichages selon l'usage. Par exemple, une portlet peut avoir un affichage différent selon qu'elle est placée dans une colonne du portail, en pleine page du portail, dans le bureau virtuel, dans un affichage PDA, dans le tableau de bord d'un espace collaboratif, vocalisée par un lecteur d'écran, ...

Fig. 24. La même portlet est présentée différemment selon son contexte d'affichage

Cette mécanique concerne aussi les gabarits d'édition qui peuvent être différents selon le contexte d'utilisation (espace de travail, front-office, popup, bureau virtuel, ...)

Fig. 25. Exemple de formulaire d'édition contextuels à la zone d'édition (front-office et back-office)

Pour cela JCMS 6 introduit la notion d'usage et permet d'associer un JSP de présentation à chaque usage. JCMS 6 propose des usages standards (full, query, box, edit, editFront). Les modules peuvent proposer de nouveaux usages (p. ex. pda, virtualdesktop, text-to-speech, ...).

Le formulaire d'édition d'une portlet a été enrichi pour sélectionner un gabarit particulier selon l'usage :

Fig. 26. Interface de sélection des gabarits

Un article présentant en détail la nouvelle gestion des gabarits sera bientôt diffusé sur ce site.

8.5 Data Image

Dans JCMS 6, tout objet dérivant de la classe Data dispose de la méthode getDataImage() qui renvoie l'image associée à cette objet. Le choix de cette image varie selon la classe de l'objet :

  • Membre: la photo du membre;
  • Catégorie: le champ image de la catégorie;
  • Document: l'imagette associée au document;
  • Portlet: il est possible d'associer à chaque portlet une image (onglet Information).;
  • Publication: il est possible de choisir dans l'éditeur de type le champ image servant à cet usage.

En plus de la méthode getDataImage(), les portlets disposent de la méthode getPortletImage(). Celle-ci renvoie l'image de prévisualisation du gabarit d'affichage sélectionné si l'image de la portlet n'est pas renseignée.

8.6 ExtraData et ExtraDBData

Avec JCMS 6, les ExtraData et les ExtraDBData supportent l'héritage. Il est donc possible de définir une ExtraData valable pour toutes les publications voire pour toutes les données (Data) de JCMS.

Pour plus de détails, reportez-vous à l'article sur les ExtraData.

8.7 Types génériques

L'API de JCMS 6 fait abondamment usage des types génériques offert par Java 5. Ceci garantit un code plus robuste (en contrôlant le typage à la compilation) et améliore généralement la lisibilité de l'API et du code, en précisant, notamment, le type des objets contenus dans les collections (List, Set, ...)

8.8 Compatibilité

Pour connaître la compatibilité de JCMS 6 avec les systèmes d'exploitation, JVM, serveur d'application, SGBDR, serveur LDAP et navigateur, reportez-vous au manuel d'installation et d'exploitation de JCMS 6.

En résumé...

JCMS 6 est une version majeure. Elle comporte des nouveautés techniques importantes en termes de stockage, de performances, d’ergonomie et d’interopérabilité. Ces nouveautés repoussent les limites et permettent de nouveaux usages. La sortie de JCMS 6 est accompagnée par la sortie d’un ensemble de modules exploitant ce nouveau cœur technique et fournissant de nouvelles fonctionnalités.

Sujet
Produits
Publié

19/01/09

Rédacteur
  • Olivier Dedieu