Fork me on GitHub

Migration des plugins de la version v1.x vers v2.0

Changements au niveau des JSP

Les changements sont les suivants :

  • Suppression du bean UserJspBean
  • Ajout d'un appel de la méthode init du JSPBean pour notamment initialiser la constantes correspondant au droit d'accès à la fonctionnalités courante. Les droits sont vérifiés par cette méthode. L'ancien code de vérification disparaît ainsi.

Nouveau code d'une JSP d'affichage :

<%@ page errorPage="../../ErrorPage.jsp" %>

<jsp:include page="../../AdminHeader.jsp" />

<jsp:useBean id="contact" scope="session" class="fr.paris.lutece.plugins.contact.web.ContactJspBean" />

<% contact.init( request, contact.RIGHT_MANAGE_ADMIN_SITE ); %>
<%= contact.getManageContacts ( request ) %>

<%@ include file="../../AdminFooter.jsp" %>                    
                        
Nouveau code d'une JSP d'action :
<%@ page errorPage="../../ErrorPage.jsp" %>

<jsp:useBean id="contact" scope="session" class="fr.paris.lutece.plugins.contact.web.ContactJspBean" />

<%
    contact.init( request, contact.RIGHT_MANAGE_ADMIN_SITE );
    response.sendRedirect( contact.doCreateContact( request ) );
%>
                        

Changements au niveau du JSPBean pour une page d'administration

Le JSP Bean doit étendre la classe PluginAdminPageJspBean

public class MyPluginJspBean extends PluginAdminPageJspBean
                        

Les méthodes d'affichage d'une page d'administration doivent définir le titre de cette page en utilisant une propriété définie dans un fichier de resource de type myplugin_messages.properties permettant l'internalitionalisation [voir i18n]. Elles doivent par ailleurs renvoyer le contenu de la page par la méthode getAdminPage de la classe de base qui complètera la mise en page et formatera le titre de la page.

La gestion du remplissage des templates est désormais faite de préférence à l'aide de Freemarker. On utilisera une HashMap nommée model pour fournir les valeurs de substitution des signets du template. Les constantes utilisées pour les noms des signets devront avoir le préfix MARK_ qui permettra de les distinguer des anciens signets préfixés par BOOKMARK_

public String getManageContacts( HttpServletRequest request )
{
    setPageTitleProperty( PROPERTY_PAGE_TITLE_CONTACTS );

    HashMap model = new HashMap(  );
    model.put( MARK_CONTACT_LIST, ContactHome.findContactsList( getPlugin(  ) ) );
    model.put( MARK_ORDER_LIST, getOrderList(  ) );

    HtmlTemplate templateList = AppTemplateService.getTemplate( TEMPLATE_CONTACTS, getLocale(  ), model );

    return getAdminPage( templateList.getHtml(  ) );
}
                        

Changements dans les templates

Les templates doivent désormais utiliser de préférence les signets et les possibilités de Freemarker notamment pour les listes et les combos. Des macros Freemarker sont disponibles dans le fichier commons.html.

La mise en page s'appuie désormais essentiellement sur les feuilles de style CSS2. Il faut donc utiliser les balises <div> prévues et supprimer les attributs class des autres balises ( a, table, tr ,td, ul, li, ...).

Voici un exemple de template intégrant :

  • Une nouvelle balise <div>
  • Toutes les valeurs litéralles sous forme de clé i18n
  • Le titre de la page : toujours en <h2>
  • Une table dont le seul attribut à définir est la largeur des cellules
  • Des signets Freemarker notamment pour gérer la liste des lignes de la table

<div class="content-box" >
    <h2>#i18n{contact.contacts.tableLabel}</h2>
        
    <table>
        <tr>
            <th width="40%">#i18n{contact.contacts.columnTitleLabel}</th>
            <th width="40%">#i18n{contact.contacts.columnTitleEmail}</th>
            <th width="20%">#i18n{contact.contacts.columnTitleOrder}</th>
        </tr>
        <#list contact_list as contact >
	        <tr>
	            <td width="40%">
	                <a href="jsp/admin/plugins/contact/ViewContact.jsp?contact_id=${contact.id}" class="admin-menu">
	                    ${contact.name}
	                </a>
	            </td>
	            <td width"40%">
	            	${contact.email}
	            </td>
	            <td>
	            		<form action="jsp/admin/plugins/contact/DoModifyOrdreContacts.jsp">
	                    	<input type="hidden" name="contact_id" value="${contact.id}" />			
	                    	<@combo name="contacts_order" default_value="${contact.contactOrder}" items=order_list />
							<input type="submit" class="button" value="#i18n{contact.contacts.buttonChangeOrder}" />
	                     </form>
	             </td>
	        </tr>
        </#list>
    </table>

    <form action="jsp/admin/plugins/contact/CreateContact.jsp">
        <input type="submit" value="#i18n{contact.contacts.buttonAddContact}" class="button" />
    </form>

</div>
                

Changements dans l’arborescence du code

Certaines classes du noyau ont été déplacées : Les classes Plugin, PluginService PluginDefaultImplementation sont descendues dans un sous-package plugin du package fr.paris.lutece.portal.service. Il faut corriger les chemins à partir des erreurs fournies par une première compilation.

Utilisation de la boucle for

    List<RssGeneratedFile> listPushRssDatabase = RssGeneratedFileHome.getRssFileList(  );
    for(RssGeneratedFile generatedFile : listPushRssDatabase )
    {
      listFileNames.add( generatedFile.getName( ) );
    }
                

La nouvelle syntaxe de la boucle for introduit depuis la version Tiger de la J2SE permet d'éviter l'utilisation d'itérateur suivi de conversions explicites. Ceci améliore la lisibilité et réduit les erreurs d'execution. Le for permet de passer en paramètres une liste itérable(tel que Collection)).

Utilisation de types paramétrés - Generics

  Collection<Contact> selectContactList( Plugin plugin )
  {
      Collection<Contact> contactList = new ArrayList<Contact>(  );
                

L'utilisation des generics pour typer les collections réduit le besoin de conversion explicites de types à l'éxecution. Il faut donc désormais rajouter le type de la liste comme indiqué au dessus. Ici la methode selectContactList( Plugin plugin ) renvoie une Collection de Contact comme indiqué dans les balises.

Changements dans le fichier XML

La classe PluginDefaultImplementation ayant été déplacée, il ne faut pas oublier de modifier le package dans le fichier XML.

Certaines informations telles que la description du plugin ou celle d'une fonction d'administration doivent utiliser des clés de ressource pour être traduite dans d'autres langues ( i18n ).

Messages du module d'administration

L'utilisation de la page Message.jsp est désormais proscrite. Il faut utiliser la nouvelle classe AdminMessageService qui fournit une URL dynamique vers une page affichant un message.

// Mandatory fields
if ( request.getParameter( PARAMETER_CONTACT_NAME ).equals( "" ) ||
        request.getParameter( PARAMETER_CONTACT_EMAIL ).equals( "" ) )
{
    return AdminMessageService.getMessageUrl( request , Messages.MANDATORY_FIELDS , AdminMessage.TYPE_STOP );
}
                        

Gestion des Images

La gestion des images dans l'application ne se fait plus en filesystem mais via la servlet ImageServlet.java.

{         
    String strResourceType = PageService.getInstance().getResourceTypeId();
}                    
                        

Utilisation d'UrlItem

Le retour vers des pages Jsp dans les méthodes des classes JspBean doivent dans la mesure du possible utiliser la classe UrlItem :

{
   	UrlItem url = new UrlItem( JSP_ADMIN_SITE );           
   	url.addParameter( Parameters.PAGE_ID, nId );
    return url.getUrl();
}                 
                        

Utilisation des contextes Spring

Appel des DAO dans les fichiers de contextes Spring. Nécessite : modification des classes Home et DAO, ajout d'une interface DAO, ajout d'un fichier de contexte xml

                        

Modification du nom des tables

Les tables du coeurs sont préfixées core_, les tables des plugins sont préfixées par le <plugin_name>_