7 mars 2018 15:18:49 seb leridon avatar
Home History fr en

Evolutions de la Version 4

Version 4.0.0

Intégration du framework CSS Bootstrap

Tous les templates du back office et du front sont modifiés pour utiliser le framework Bootstrap et sa capacité à faire du Responsive Design.

Voir le détail des normes de mise en oeuvre : Intégration du framework Bootstrap dans Lutèce

Datastore

Création d'un système de stockage clés/valeurs. Ce dispositif permet de stocker des valeurs de configuration, des états et des logs d'exécution.

Le nom des clés doivent être préfixées par le nom du plugin.

Exemple de mise en oeuvre : le plugin SEO

private static final String KEY_SITEMAP_DEAMON_ENABLED = "seo.sitemap.daemon.enabled";
...
DatastoreService.setDataValue( KEY_SITEMAP_DEAMON_ENABLED, DatastoreService.VALUE_TRUE );
...
String strDeamonEnabled = DatastoreService.getDataValue( KEY_SITEMAP_DEAMON_ENABLED, DatastoreService.VALUE_FALSE );
if ( strDeamonEnabled.equals( DatastoreService.VALUE_TRUE ) )
{    
      ...
}

Préférences

Deux nouveaux services sont disponibles pour stocker des préférences utilisateurs : l'un pour ceux du Back Office l'autre pour ceux du Front.

Version 4.0.1

De nombreux bug fixes.

Version 4.1.0

Changement dans la gestion du fichier plugins.dat

Afin de gérer l'état des plugins et la configuration du pool dans des déploiements cloud (tels que CloudBees), il n'est plus possible de stocker ces valeurs dans le système de fichiers. Elles sont désormais sauvegardées dans le Datastore.

Le fichier plugins.dat est maintenant seulement utilisé pour initialiser le Datastore au démarrage. Si une clé est déjà dans le Datastore, la valeur figurant dans le fichier est ignorée.

Nouvelle gestion des propriétés du site et disparition du fichier webmaster.properties

Les propriétés du site (nom, balises méta, ...) sont désormais stockées dans le Datastore et non plus dans le fichier webmaster.properties qui disparaît.

Un nouveau mécanisme de Datastore permet de localiser des libellés et des textes d'aide associés aux clés (traductions i18n en ressource basées sur les clés Datastore).

Des plugins peuvent désormais ajouter leurs propriétés dans l'interface de gestion de l'Admin Feature "Propriétés du site".

Voir le plugin GTools qui met en œuvre ces deux dernières fonctionnalités.

Nouvelles clés ajoutés aux propriétés du site :

  • Home URL : permet de définir l'URL de la redirection faite par index.jsp (racine de la webapp)
  • No Reply Email : L'email no-reply se configure désormais dans cette interface à la place du config.properties

En cas de problème résultant de l'utilisation des anciennes clés du webmaster.properties par des plugins (plantage Freemarker par exemple), un fichier de properties contenant les clés manquantes peut être créé dans le répertoire WEB/conf/override/plugins par exemple.

Evolutions du Datastore

Le datastore dispose d'un système de cache administrable dans la gestion des caches.

De nouvelles fonctionnalités permettent :

  • de récupérer un groupe de clés/valeurs dans une ReferenceList à partir d'un préfixe de nom de clé
  • de localiser des groupes de clés (LocalizedDataGroup)
  • de savoir si une clé existe (existsKey)

Exemples de mise en oeuvre : SystemJspBean et plugin GTools

Remplacement dans les templates de clés par leur valeur dans le Datastore

Un nouveau formalisme permet de réaliser au moment du chargement du template une substitution de clés par leur valeur dans le Datastore.

La syntaxe est similaire à celle pour les clés d'internationalisation (i18n), le préfix étant ici #dskey. Exemple : 

<p>#dskey {monplugin.mafonction.maclé}</p>

Nouvelle balise meta generator

Cette balise méta se trouvant la section <head> des pages, indique que la page a été produite par Lutece comme suit : 

<meta name="generator" content="LUTECE 4.1.0" />

Pour ajouter cette balise dans une ancienne webapp, il suffit de rajouter la ligne suivante dans le section<head> du page_frameset.html. 

<meta name="generator" content="${meta_generator}" />

Nouvelle possibilité de définir la page par défaut du Back Office et celle du Front.

L'URL de la page d'accueil du Back Office et celle de redirection de la racine de la webapp peuvent être désormais modifiées.

Elles peuvent être définies par le biais des "Propriétés du Site" stockées dans le Datastore. Si l'on ne veut pas faire apparaître ces valeurs dans l'interface de gestion des propriétés du site, il suffit de supprimer les clés portal.site.site_property.admin_home_url et portal.site.site_property.home_url du Datastore et les valeurs seront récupérées par le biais des clés lutece.admin.menu.url et lutece.portal.redirect.url figurant dans le fichier lutece.properties ou une surcharge figurant le répertoire WEB-INF/conf/override dans le cas où les valeurs par défaut seraient modifiées.

lutece.admin.menu.url=jsp/admin/AdminMenu.jsp
lutece.portal.redirect.url=jsp/site/Portal.jsp

Ajout d'un filtre d'authentification Front Office

Ce filtre d’authentification est destiné à vérifier dans le cas ou l’authentification obligatoire est activée que l’utilisateur est bien authentifié.

Ce filtre prend en compte une liste d’ URL publique afin de permettre un accès non authentifié à certaines pages du site.

La liste des URLs publiques est configurable dans la page dédiée à l’administration technique du portail et des plugins.

Par défaut cette liste est vide et devra être enrichie notamment des URLs nécessaires au fonctionnement du module d’authentification utilisé.

Exemple d'utilisation avec le module mylutece database

Les URLs à ajouter dans la liste des URLs publiques sont les suivantes

URL Valeur
URL d’affichage de la page de login jsp/site/Portal.jsp?page=mylutece&action=login
URL de traitement du login jsp/site/plugins/mylutece/DoMyLuteceLogin.jsp
URL de traitement du logout jsp/site/plugins/mylutece/DoMyLuteceLogout.jsp
URLd’affichage de la page de création de compte jsp/site/Portal.jsp?page=mylutecedatabase&action=createAccount
URL d’affichage de la page de perte de mot de passe jsp/site/Portal.jsp?page=mylutecedatabase&action=lostPassword
URL d’affichage de la page de perte de login jsp/site/Portal.jsp?page=mylutecedatabase&action=lostLogin
URLd’affichage de demande de réinitialisation de mot de passe jsp/site/Portal.jsp?page=mylutecedatabase&action=reinitPassword
L’ensemble des URLs de traitement des actions ci-dessus jsp/site/plugins/mylutece/modules/database/*

Evolutions de l'editeur BBCode

De nouvelles balises BBCode ont été ajoutées. Ces balises ont été déclarée dans le fichier editors.properties.

Ajout de macros Freemarker pour le front office

Des macros Freemarker, similaires aux macros utilisée en Back Office, ont été ajoutée afin d'être utilisée en Front Office. Il est donc désormais possible de surcharger les macros du Front Office sans surcharger les Macros du Back Office.

Ces nouvelles macros sont déclarées dans le fichier Webapp/WEB-INF/templates/commons_site.html

Nouveautés concernant le peuplement des beans et leur validation (JSR 303) pour les JspBean du back office

Support amélioré de la JSR 303 décrit dans la page suivante : Validation des Beans

Le code de création d'un objet dans la couche de présentation peut désormais être écrit de la manière suivante : 

// PersonJspBean.java
public String doCreatePerson( HttpServletRequest request )
{
    Person person = new Person(  );

    // Populate the bean with data coming from the request
    populate( person, request );

    // Check constraints
    List<ValidationError> errors = validate( person , VALIDATION_ATTRIBUTES_PREFIX );
    if ( errors.size(  ) > 0 )
    {
        return AdminMessageService.getMessageUrl( request, Messages.MESSAGE_INVALID_ENTRY, errors );
    }

    PersonHome.create( person );

    return JSP_REDIRECT_TO_MANAGE_PERSONS;
}

NB : la méthode populate peut charger les paramètres dont le nom respecte les normes LUTECE c'est à dire minuscules + underscores
NB : Les méthodes de peuplement et de validation sont disponibles pour les autres composants (XPages par le biais d'une nouvelle classe AbstractXPageApplication , JspBean Front, ...) et se trouvent dans lutece.util.bean.BeanUtil et lutece.util.beanvalidation.BeanValidationUtil.

Instanciation des XPage

Les objets XPage sont désormais instanciés pour chaque session HTTP au lieu d'être partagés.

Mise à jour des DataTableManager

Plusieurs tableaux de données peuvent désormais être utilisé sur une même page sans entraîner de mélange de tri, pagination ou filtre. Pour pouvoir utiliser plusieurs DataTableManager sur une même page, il faut obligatoirement qu'ils soient enregistrés en session, et non créé à chaque requête de l'utilisateur.

Gestion des préférences utilisateurs

Pour la gestion des préférences des utilisateurs du Front Office le service UserPreferencesService propose désormais la récupération du pseudo choisit par l’utilisateur et sa mise à jour. 

String strPseudo = UserPreferencesService.instance().getNickname( user );
String strPseudo = UserPreferencesService.instance().getNickname( strUserId );
UserPreferenceService.instance().setNickname( strUserId , strNewNickname );

Génération du contenu des portlets sans utiliser de feuille de style XSL

Les portlets peuvent désormais générer leur contenu de deux manières différentes :

  • soit en utilisant la méthode historique : à l'aide de feuilles de style XSL
  • soit en générant directement le contenu HTML à afficher.

Les portlets existant (utilisant donc des XSL) ont un fonctionnement inchangé. Les portlets souhaitant générer leur contenu HTML sans utiliser de XSL (par exemple avec des templates Freemarker) doivent étendre la classe fr.paris.lutece.core.business.portlet.PortletWithoutXsl et implémenter la méthode public String getHtmlContent( HttpServletRequest request )

Nouveau framework MVC pour le front et le back office

La library MVC a été mise en dépendance du noyau pour développer des XPages et des Admin Features en utilisant le paradigme MVC.

Cette bibliothèque propose :

  • Le dispatching des requêtes par le contrôleur pour traitement des actions et affichage des vues
  • L’identification des actions et des vues par annotations,
  • La population et la validation des beans (JSR 303)
  • La gestion des erreurs de validation directement incluse dans le modèle du template (marker « errors »)
  • La gestion des notifications ou messages informatifs incluse dans le modèle du template (marker « infos »)
  • La redirection HTTP des requêtes vers des vues évitant le recours à des JSP
Le générateur de plugin PluginWizard génère (à partir de sa version 3.2) des Admin Features utilisant ce framework MVC. Par ailleurs, le code source de ce plugin est un bon exemple d'utilisation du framework MVC pour réaliser des XPages.

Version 4.1.1

Ajout de la possibilité de ne pas mettre en cache le contenu de certains portlets

Le contenu des portlets d'une page peut être mis en cache de deux manières différentes :

grâce au cache des pages, qui enregistre en cache pour un utilisateur les différentes pages qui sont générées. grâce au cache des portlets, qui enregistre en cache pour chaque portlet le contenu généré.

Afin de permettre à certain portlet de ne pas afficher des données périmées sans désactiver ces deux caches, un mécanisme a été mis en place afin que chaque portlet puisse spécifier s'il autorise le contenu qu'il génère à être mis en cache ou non.

Cette autorisation passe par deux méthodes de la classe fr.paris.lutece.portal.business.portlet.Portlet :

// PersonJspBean.java
public boolean canBeCachedForAnonymousUsers( )
{
    return true;
}

public boolean canBeCachedForConnectedUsers( )
{
    return true;
}

La méthode canBeCachedForAnonymousUsers( ) sert à spécifier si le contenu du portlet peut être mis en cache pour les utilisateurs non connectés. La méthode canBeCachedForConnectedUsers( ) sert à spécifier si le contenu du portlet peut être mis en cache pour les utilisateurs connectés.

Lorsqu'une page est générée (et donc si elle n'est pas déjà présente en cache), la page vérifie si tous ses portlet autorise ou non la mise en cache du contenu pour l'utilisateur courrant (anonyme ou connecté). Si tous ses portlets l'autorise, alors le HTML généré est enregistré dans le cache des pages (s'il est activé). Si au moins un portlet ne l'autorise pas, alors la page générée n'est pas enregistrée dans le cache des pages.

Le fonctionnement du cache des portlet reste relativement identique à l'ancien fonctionnement, à l'exception près que le contenu généré n'est enregistré en cache que si le portlet l'autorise pour l'utilisateur courrant (anonyme ou connecté).

L'implémentation par défaut de ce mécanisme autorise les mises en cache pour tous les portlets. Pour modifier ce comportement pour un portlet, il suffit de surcharger les deux méthodes décrites ci-dessus.

Attention, la désactivation du cache pour les utilisateurs non authentifié peut causer une importante diminution des performances !

Version 4.2

L'implémentation mère des XPages est Serializable ce qui permet aux implementations spécifiques qui ne sont pas définies explicitement Serializable de fonctionner dans un contexte où les variables de session peuvent être sérialisées.

Cette version n'apporte pas que très peu de nouvelles fonctionnalités. C'est une version qui corrige un certain nombre de problèmes des versions 4.1.x.

Version 4.3

Le choix d’incrémentation du numéro de version intermédiaire (et non celui mineur) est justifié par les deux modifications importantes suivantes :

Nouvelles macros Freemarker

4 macros Freemarker permettant de simplifier la création de formulaires ont été créées :

  • fieldInputText : permet d'afficher un champ texte. Cette macro possède les paramètres suivants :
    • i18nLabelKey (type texte) : Clé i18n du label à afficher (obligatoire).
    • inputName (type texte) : Nom de l'input généré (obligatoire).
    • mandatory (type booléen) : Indique si le champ est un champ obligatoire ou non (facultatif).
    • value (type texte) : valeur par défaut (facultatif).
    • maxlength (type entier) : nombre de caractères maximal du champ (facultatif).
    • i18nHelpBlockKey (type texte) : clé i18n du texte d'aide (facultatif).
    • cssClass (type texte) : classe CSS de l'input généré (facultatif).
  • fieldInputCalendar : permet d'afficher un champ texte avec un calendrier. Cette macro possède les paramètres suivants :
    • i18nLabelKey (type texte) : Clé i18n du label à afficher (obligatoire).
    • inputName (type texte) : Nom de l'input généré (obligatoire).
    • mandatory (type booléen) : Indique si le champ est un champ obligatoire ou non (facultatif).
    • value (type texte) : valeur par défaut (facultatif).
    • i18nHelpBlockKey (type texte) : clé i18n du texte d'aide (facultatif).
    • cssClass (type texte) : classe CSS de l'input généré (facultatif).
    • language (type texte) : langue du datepicker (facultatif, valeur par défaut : 'fr')
  • fieldInputCheckBox : permet d'afficher une case à cocher. Cette macro possède les paramètres suivants :
    • i18nLabelKey (type texte) : Clé i18n du label à afficher (obligatoire).
    • inputName (type texte) : Nom de l'input généré (obligatoire).
    • checked (type booléen) : Valeur par défaut de la case à cocher (obligatoire).
    • mandatory (type booléen) : Indique si le champ est un champ obligatoire ou non (facultatif).
    • value (type texte) : valeur par défaut (facultatif).
    • i18nHelpBlockKey (type texte) : clé i18n du texte d'aide (facultatif).
    • cssClass (type texte) : classe CSS de l'input généré (facultatif).
  • fieldInputText : permet d'afficher un champ texte long. Cette macro possède les paramètres suivants :
    • i18nLabelKey (type texte) : Clé i18n du label à afficher (obligatoire).
    • inputName (type texte) : Nom de l'input généré (obligatoire).
    • mandatory (type booléen) : Indique si le champ est un champ obligatoire ou non (facultatif).
    • value (type texte) : valeur par défaut (facultatif).
    • maxlength (type entier) : nombre de caractères maximal du champ (facultatif).
    • i18nHelpBlockKey (type texte) : clé i18n du texte d'aide (facultatif).
    • cssClass (type texte) : classe CSS de l'input généré (facultatif).

Exemple :

Le code suivant permet d'avoir un formulaire avec trois champs noms, prénoms et date de naissance : 

<form action="" class="form-horizontal">
    <@fieldInputText i18nLabelKey='myplugin.user.labelFirstName' inputName='firstname' value=firstname!'' mandatory=true maxlength="255" />
    <@fieldInputText i18nLabelKey='myplugin.user.labelLastName' inputName='lastname' value=lastname!'' mandatory=true maxlength="255" />
    <@fieldInputCalendar i18nLabelKey='myplugin.user.labelBirthDate' inputName='birth_date' value=birth_date!'' cssClass='input-small' />

    <div class="form-actions">
        <button class="btn btn-primary btn-small">
            <i class="icon-ok icon-white"> </i>Valider
        </button>
    </div>
</form>

Ajout de l’information email à l’objet LuteceUser

L'objet LuteceUser dispose désormais d'un attribut Email en lecture seule. L'implémentation par défaut de la nouvelle méthode getEmail()renvoie null. Il appartient à chaque module d''authentification de fournir sa propre implémentation.

Cette solution a été préférée à une méthode abstraite qui aurait rendu incompatibles les versions actuelles des modules.

Pour bénéficier de l’email, les modules d’authentification doivent s’appuyer sur la version 3.1 de MyLutece (qui elle requiert au minimum la version du core 4.3).

Ainsi la version de MyLuteceDatabase 3.1 qui utilise l’email requiert au minimum Lutece v4.3.

Une configuration pour utiliser par exemple les plugins Avatar et AvatarServer avec MyLuteceDatabase requiert donc les versions taguées :

  • MyLuteceDatabase 3.1
  • MyLutece 3.1
  • Lutece 4.3

Version 4.4

Nouvelle macro Freemarker pour les formulaires

  • fieldInputCombo : permet d'afficher une liste déroulante. Cette macro possède les paramètres suivants :
    • i18nLabelKey (type texte) : Clé i18n du label à afficher (obligatoire).
    • inputName (type texte) : Nom de l'input généré (obligatoire).
    • items (type ReferenceList) : Listes des objets à ajouter dans la liste déroulante (obligatoire).
    • mandatory (type booléen) : Indique si le champ est un champ obligatoire ou non (facultatif).
    • value (type texte) : valeur par défaut (facultatif).
    • i18nHelpBlockKey (type texte) : clé i18n du texte d'aide (facultatif).
    • cssClass (type texte) : classe CSS de l'input généré (facultatif).

Export des composants blobstore

Les classes du blobstore présentes dans le core jusqu'à la version 4.3.0 ont été déplacées dans la librairie library-blobstore.

Cette solution permet d'améliorer la modularité du core et d'accéder aux fichiers du blobstore dans des batchs.