Liferay Development Standards

Directorate General of Administration Directorate of Information Technology

STANDARDS

LIFERAY DEVELOPMENT STANDARDS

Document type:  working  validation in progress  approved for distribution

Reference: 03a6b184ea595e66ad5a6b558efe7816.docx

Purpose of the document

The purpose of this document is to describe the standards for developing a Liferay application at the CoE.

NB: Any non-compliance with the standards or practices described in this document must be reported by the supplier prior to the start of works and validated by the Council of Europe (DIT).

03a6b184ea595e66ad5a6b558efe7816.docx [Normes] Dernière modification 03 mai 2016 à 12:18:00 Auteur

Version : 1.1 Page 1 / 29 Standards LIFERAY DEVELOPMENT STANDARDS

This document is the property of the Council of Europe. It may not be reproduced or communicated without the prior agreement of the author.

Contents

1 INTRODUCTION

1.1 PURPOSE

This document sets out the standards to be applied when developing a Liferay-based application for the Council of Europe.

All the rules described in this document must be scrupulously complied with, and corresponding checks will be made on each delivery.

For the standards governing implementation of applications in general, please refer to the document describing the Council of Europe information system standards enclosed with the developer's toolkit.

Failure to comply with the standards and norms of the Council of Europe may result in a delivery being rejected.

1.2 WARNING SIGNS USED IN THIS DOCUMENT

The following pictograms are used throughout this document to emphasise important points or ideas.

Important information

Risk relating to parametering or a specific action

Action to be avoided

Action mandatory

1.3 REFERENCE DOCUMENTATION

It is imperative that the following documentation, contained in the developer's toolkit, be taken into account for developments:

JS/CSS/HTML documentation SVN documentation J2EE documentation Graphic charter

2 GOOD PRACTICES FOR LIFERAY PORTAL DEVELOPMENTS

2.1 GENERAL POINTS

2.1.1 USE OF TRANSVERSAL TOOLS

The Council of Europe has implemented a number of transversal tools to meet the Organisation’s needs:

- Records management (RMS – Records Management System) - Document management (DMS) - Photolibrary - Videolibrary - Meta directory - Enterprise search - CAS-SSO

The tools listed above must be used for any new solution implementing one or many of the functionalities already covered by these tools unless written derogation from the DIT.

2.1.2 NORMES - LIFERAY DEVELOPMENT STANDARDS

Any specific development must be carried out in compliance with the Liferay development standards.

2.1.3 COMMON SOURCES OF THE WEB PLATFORM

No changes must be made to the common sources of the Liferay web platform, whether to Liferay "standard" source files or to source files linked to developments carried out specifically for the implementation of a shared solution.

Should modification of these common sources be considered to be absolutely necessary, it is imperative to request validation by the DIT.

2.1.4 STRUCTURES AND TEMPLATES

The structures and templates are versioned in the source control tool (templates_structures folder).

The structures and templates must be validated by DIT to avoid any conflict with existing structures and templates.

2.1.5 MANAGEMENT OF ROLES

The roles used on the Council of Europe's Liferay platform are not the basic roles of Liferay, except for guest, user, site member, site owner and administrator. The" administrator" role is allocated only to those providing technical support for the web platform (DIT).

The main generic roles established on the web platform are briefly described in the table below.

Name of role Description 0 – Guest Unauthenticated site user who can just browse the public pages of CoE sites. 1 – User (USR) Authenticated user who can browse the public pages of CoE sites and, by default, participate in the use of all the collaborative tools (forum, wiki, blogs, comments etc) unless a specific restriction applies. 2 – Contributor (CTB) Has permissions to create webcontent (articles) and edit webcontent (articles). 3 – Reviewer (RVW) Has permissions to validate webcontent (articles) submitted for validation and to disable webcontent (articles). 4 – Editor (EDT) Has permissions to create and edit pages. Also has permissions to assign layouts and to add and delete applications. Can access / add / administrate the applications below: 5 Publisher (PBL) Has permissions to publish/unpublish pages, the contents of pages or a whole site. Also has permissions to delete pages. Can access / add / administrate the applications below: 6 Site administrator (SAM) Has permissions to manage user access. Can access / add / administrate the applications below: - Asset publisher - Blog and Recent bloggers - Forum - Calendar - Iframe - Page Comments - Page Flags - Page RatingsTag admin - Polls - Wiki - XSL Content 7 Super Site Administrator (SSA) Has permissions to manage all the sites of a given instance 8 Administrator Overall administrator of the application and all the sites.

These specific roles are "site roles". The rights and permissions assigned to each role may be subject to modification.

For a detailed description of the rights of the different roles, please ask the DIT project coordinator.

Any specific need regarding the setting up of new roles must be validated by the DIT.

LIFERAY VERSION USED

The Liferay version used at present is: 6.2.10 EE

TECHNICAL ENVIRONMENT USED

The following choices have been made with regard to the Liferay technical environment - Java virtual machine: 1.7.0_91 - Application server: Tomcat 7.0.42 - Database server: MySQL 5.4.42

2.1.6 HEAVY PROCESSING

You are advised not to incorporate heavy application processing at the level of the internet platform. The following types of processing must be carried out in a dedicated environment (full application, background processing etc) - report generation - major background processing - …

2.1.7 USING EXTERNAL BASES

Access to external bases will be read-only, and web services will be the preferred means of retrieving external data. Otherwise, views will have to be created on the database.

1.1.1. Using an SQL connection 1.1.1.1. Retrieving the connection If access to a database is required, a connection pool must be set up for that base. Direct database access is prohibited.

It is recommended that views or stored procedures are used for queries. In all cases, if adaptations of views or stored procedures are necessary, they will have to be carried over in the project sources managing the database in question.

Example of set-up: The configuration files will have to be integrated in the compilation process so that they can be parametered (cf Setting up a specific compilation Setting up a specific compilation )

Rule for naming the resource

PORTLETNAME_DATABASENAME

Declaring the resource in the context

In your project you must add the following file: /docroot/META-INF/context.xml

Declaring the resource in the webapp

In the web.xml file, you must add this section:

jdbc/XXXXXXXX javax.sql.DataSource Container

Retrieving the datasource

Context envContext = new InitialContext(); DataSource ds = (DataSource)JNDIUtil.lookup(envContext,"jdbc/XXXXXX"); con = ds.getConnection();

1.1.1.2. Releasing the connection The SQL connections must be properly closed in a finally block

A utility could be installed to simplify the writing of the finally block

Example:

try { //connection in use } catch (Exception e) { logger.error("Error in sql", e); } finally{ if (rs != null) { try { rs.close(); } catch (SQLException e) { logger.error("SQL Error : Could not close the Result Set"); } } if (p != null) { try { p.close(); } catch (SQLException e) { logger.error("SQL Error : Could not close the Query"); } } if (con != null) { try { con.close(); } catch (SQLException e) { logger.error("SQL Error : Could not close the Connection"); } } }

2.1.8 THEME, TEMPLATE, CSS

Any addition / modification of theme, page template or CSS must be validated by the Directorate of Communication.

Any specific need regarding the theme must be dealt with as follows: - in the event of a minor change to the standard theme supplied by Directorate of Communication (eg: additional specific settings), if possible apply the change to the standard theme after having had it validated by the Directorate of Communication (where this change can be shared for all the Council of Europe's sites); - in the event of a change to the standard theme not intended to be shared for all sites, carry out an extension of the existing standard theme; - for a very specific need, create a new theme as an extension to the classic Liferay theme.

2.2 USING METADATA

The Council of Europe's shared metadata will be made available on each Liferay instance. This data source should be deployed if these lists must be used for specific needs. The following Liferay services will provide access to this information:

//retrieval of a category (metadata item value) AssetCategory category = AssetCategoryLocalServiceUtil.getAssetCategory(categor yId); //retrieval of a vocabulary item (metadata) AssetVocabulary vocabulary = AssetVocabularyLocalServiceUtil.getAssetVocabulary(cat egory.getVocabularyId());

DEVELOPING PORTLET PLUGINS WITH THE PLUGINS SDK

A plugin for developing portlets has been created by Liferay. This development plugin provides ANT scripts for compilation, building of WAR files and deployment. For each stable version of the product, Liferay supplies (via a download) an adequate development kit for customising the product and developing new plugins to meet the different functional requirements.

2.3 JSP OVERLOADING (DIT VALIDATION REQUIRED)

It is recommended that you follow the steps below if the project requires the overloading of certain JSP files of native Liferay portlets  Copy the portlet file from the Liferay sources: webapps/ROOT/html

 Add a header to each file as in the example below:

<% * Project name: COE * Liferay version: Liferay 6.1.x * Modification: Adding preview button in the blog portlet * Author: surname first name %>

If the page to be modified contains a lot of customisations, it is preferable to place these customisations in a separate file and include it in the original page using an "include" as in the example below:

<%@ include file="/html/portlet/calendar/init.jsp" %>

2.4 WHEN TO USE THE EXT ENVIRONMENT? (DIT VALIDATION REQUIRED)

It is recommended that development be carried out in the Liferay extension environment only when necessary, as in the following cases (the server must be rebooted after EXT deployment):

 Customising the Liferay portal (appearance, organisation, overloading of classes, SSO connection, LDAP etc)  Deploying the Liferay portal in its application server.

In all cases, any modification of the EXT environment requires the prior agreement of the DIT (risk of conflict).

The extension environment provides a set of ANT tasks making it possible to automate deployment to the application server:  Overloading of authentication phase (SSO, LDAP, NTLM etc)

 Overloading of LDAP synchronisation,  Creation of business classes supplementing native Liferay objects,

 Creation of Liferay WebServices to communicate with other applications,  Portal customisation (Groups by default, compression of javascripts etc),

 Modification of Liferay Struts actions  Modification of Liferay Spring config

 Addition of a filter in web .xml  Use of.jar dependency shared between several portlet resources, hooks…

 Addition / configuration of the Portal-ext.properties file  etc.

The tree structure of the extension environment is as follows:

 "ext-impl": Liferay overloading java classes and configuration files,

 "ext-lib/portal": these libraries are deployed in the "WEB-INF/lib" directory of the Liferay web app. They are therefore visible to the portal.  "ext-lib/global": these libraries are deployed in the Tomcat "common/lib/ext" for example.

 "ext-service": classes generated by Service Builder (remote or local services)  "ext-web": overloading of the web part of Liferay.

To summarise, the important folders are:  "ext-impl"  "ext-web"

The main overloading files are:  "/ext/ext-impl/classes/portal-ext.properties": this file is used to overload the value of the properties of the "portal.properties" source file.

 "/ext/ext-impl/classes/system-ext.properties": this file is used to overload the value of the properties of the "system.properties" source file.  "/ext/ext-impl/classes/content/Language-ext.properties": this file is used to overload the value of the language keys or create others. Files specific to each language can be created. Example for Spanish: Language-ext_es.properties.

The different ANT scripts available in the extension environment make it possible to deploy all or part of the portal.

 "clean": removes all traces of compilation and deployment,  "deploy": is used for compilation, file merging and deployment of all modules,

 "deploy-impl-jar": is used for compilation, building the jar file and deployment of Liferay implementation classes  "deploy-properties": merges and deploys only the Liferay properties files

 "deploy war": deploys the war file already built.

The "build.xml" files located in the "ext-impl", "ext-service" and "ext-web" files are more specific ANT sub-tasks.

2.5 USING THE PORTAL-EXT.PROPERTIES FILE

The "portal-ext.properties" settings file makes it possible to overload the portal.properties reference file. The latter contains ALL the parameters, with their default values. Other project-specific parameters may be defined in this file (Url in a portlet, parameters, size of a resource, default value etc). The "portal-ext.properties" settings file must be placed under /webapps/ROOT/WEB- INF/classes/.

If using settings specific to the environment (SMTP address, IP address of the server, apache server etc), you are advised to separate the 2 files:  portal-ext.properties in: /webapps/ROOT/WEB-INF/classes/ : containing the parameters that do not depend on the environment;  portal-ext.properties in: TOMCAT_HOME : containing the environment-specific parameters.

This solution allows you to simplify deployment and have the same deliverable for the different environments.

An example of the adding of properties keys to the "portal-ext.properties” is shown below:

#My properties keys my.properties=my personal properties

The configuration is located in the portal context file: /conf/localhost/liferay.xml.

Simply configure the right type of database, for example:

The driver used must be placed in the "ext-lib/global" folder in order to be visible at the level of the application server which manages the "jdbc/LiferayPool" data source.

2.6 USING THE PORTAL-INSTANCE_WEB_ID.PROPERTIES FILE

The "portal-INSTANCE_WEB_ID.properties" settings file makes it possible to overload the portal.properties reference file for a given instance. Please note that not all Liferay properties are compatible with this operating mode.

2.7 EXTENDING THE LIFERAY BASE

The Liferay tables can be extended to customise the portal with regard to persistence. This manipulation is complex but may come in handy. It must be very closely followed to facilitate portal version changes: https://web.liferay.com/fr/community/wiki/-/wiki/Main/Extending+Liferay+Tables+in+Another+Database

It is possible to create additional queries to supplement Liferay services. To do so, follow this tutorial: https://web.liferay.com/fr/community/wiki/-/wiki/Main/How+to+create+a+custom+query+in+ext+for+Life ray+models

2.8 DEVELOPING A THEME

2.8.1 NAMING Theme projects must be named as follows: PROJECT_NAME-theme

2.9 DEVELOPING A LAYOUT

A layout is a grid used to arrange the portlets on the page. The configuration of the default layout when a page is created can be set in the "portal-ext.properties" file. For a column layout, simply add the following line.

layout.default.template.id=1_column

2.9.1 NAMING Layout projects must be named as follows: PROJECT_NAME -layouttpl

2.10 DEVELOPING A WEBCONTENT TEMPLATE

A webcontent template is used to manage the display of webcontent with which it is associated. Access to Liferay services is authorised on the platform, but their use is restricted to read-only access. You must not use any methods allowing additions, modifications or deletions within the templates. For logging and backup purposes, these templates and their associated structure must be backed up in the SVN repository, and a "templates_structures" directory on the repository root is provided for this purpose. Example of use of a Liferay service

#set ($DLFileEntryService = $serviceLocator.findService("com.liferay.portlet.docum entlibrary.service.DLFileEntryLocalServiceUtil"))

#set ($uuid = $httpUtil.getParameter($data, "uuid",false)) #set ($groupId = $httpUtil.getParameter($data, "groupId",false)) #set( $Integer = 0 ) #set ($fileEntry = $DLFileEntryService.getFileEntryByUuidAndGroupId($uuid , $Integer.parseInt($groupId)))

? $fileEntry.getName() ($fileEntry.getSize())

2.11 LIFERAY PLUGINS SDK

Portlet creation may be facilitated by the use of the Liferay development plugin. This plugin is a project with ANT scripts for compilation, creation of WAR files, deployment of portlets etc. The "build.properties" file can be overloaded by each developer locally by copying it and renaming it "build.[Name].properties".

The three main functions of the "build.xml" file are to compile, create WAR files and deploy the themes, layouts and portlets in the portal. Each sub-folder has ANT scripts with more specific tasks.

Some of the classic errors and problems in deployment using the plugin are referenced at: http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Plugin+Deployment+Troubleshooting

Similarly, for the hot deploy of portlets and themes: http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Hot%20Deploy%20Troubleshooting

2.12 DEVELOPING A PORTLET PLUGIN

The framework to be used to develop a portlet plugin is MVC portlet. One template will be used to create all the portlets, which makes for consistency between portlets and simpler maintenance. If a resource is shared between portlets, it must be placed in the tomcat lib folder.

The portlets must be organised as follows:  "html": folder holding all the portlet's "jsp", "css", "js" etc files,

 "src": portlet's java sources  file describing the portlet

If the project requires the creation of several portlets with the same functional perimeter, it is recommended that they be grouped in the same project. The list of portlets is defined in liferay- portlet.xml.

The resources / dependencies of the Liferay .jar files must not be copied to the portlets.

2.12.1 NAMING A portlet has a "technical" name and a "display" name. Both these names must follow similar naming rules.

The technical name must comply with the following format: coe[-site/department][-functionality]

Example:  coe-search: for the common search portlet (shared developments will have names of this type)  coe-fej-calendar: for the calendar specific to the site of the European Youth Foundation ("FEJ" being the abbreviation of its title in French)

The name displayed to users (in back office or front office) must follow the same naming convention: CoE[ site/department][ functionality]

Example:

 CoE Search: for the common search portlet (shared developments will have names of this type)  CoE FEJ Calendar: for the calendar specific to the site of the European Youth Foundation ("FEJ" being the abbreviation of its title in French)

The portlet's technical name is defined in the portlet.xml file in the portlet-name tag. The "display" name is defined in the portlet.xml file in the display-name tag and in the associated translation files thanks to the javax.portlet.title property

2.13 ORGANISATION OF PORTLETS IN THE SDK

The "portlet" folder contains all the portlets to be developed in the project. It is made up of different sample portlets providing a base and a concrete support for the developer.

2.14 ADDING TRANSLATIONS

2.14.1 TRANSLATION OF THE PORTAL

We recommend putting all the translations in a single translation hook:  Hook name: Projectname-portaltranslation-hook

 Example of liferay-hook.xml (here, in version 6.0):

/localized/resources/Language_en.properties

/localized/resources/Language_fr.properties

2.14.2 TRANSLATION OF A PORTLET

We recommend placing the translations in the portlet. You must create one language file per entry in the portlet.xml file. An exception may be tolerated in cases where it is necessary to create several portlets meeting the same need for display reasons.

2.15 DEFINING NAMING RULES FOR PORTLET PROPERTIES

You are advised to have a naming rule for portlet properties in a project. The following 2 methods may be used to retrieve a variable in a portlet:

1. portal-ext.properties file: a. Declaring a property in the portal-ext.properties file a.i. Advantage: the variable is available for the entire portal. a.ii. Drawback: the server has to be rebooted for the variable to be taken into account. b. These properties have the advantage of being available everywhere on the portal and can therefore be used by all the portlets. c. Retrieval method: String nameOfVariable = "com.coe.projetName.context.nameOfVariable"; String value = PropsUtil.get(nameOfVariable);

2. Liferay portal variable: a. Declaring "custom attributes" a.i. Advantage: no rebooting of the server. a.ii. Drawback: the variable can be modified/ deleted by an administrator, making it necessary to test in the portlet to see whether the variable exists, to avoid the portlet becoming unavailable.

b. Adding a custom attribute for an organisation and assigning read-only permission to the guest role c. Retrieval method: User user; Organization organization ; ExpandoBridge bridge = ExpandoBridgeFactoryUtil.getExpandoBridge(user.getComp anyId(), Organization.class.getName(), organization.getPrimaryKey()); String customerID = (String)bridge.getAttribute("nameOfVariable");

d. Modifying a variable: ExpandoBridge bridge = ExpandoBridgeFactoryUtil.getExpandoBridge(user.getCompanyId(), Organization.class.getName(), organization.getPrimaryKey()); bridge.setAttribute("nameOfVariable","valueOfVariable");

The properties declared must comply with a defined naming system, such as: For portlets: com.coe.project.{PORTLET NAME}.{VARIABLE NAME} For structures: com.coe.project.{PORTLET NAME}.structure.{VARIABLE NAME}

The properties declared must be annotated with at least the following information: 1. Reference portlet 2. Author 3. Creation date

Example: @portlet MyPortlet @author First name SURNAME @date 12/01/2010

2.16 USER PREFERENCES FOR PORTLETS

When using user preferences in a portlet, an initialisation of preferences with a default value must systematically be added in the portlet's portlet.xml file, as shown in the example below:

width 100% scrolling no

2.17 DEFINING A NAMING RULE FOR CUSTOM ATTRIBUTES

The naming rule is: prefix_projectname_{PORTLET NAME or hook name etc…}_{VARIABLE NAME} Below: an example of the use of custom attributes; developments must be systematically tested with simple USER and Admin accounts to ensure they function correctly in all cases.

//// Adding a custom attribute table and/or adding a custom attribute: protected void addCustomAttribute(String pAttribut, String pValue, long pUserId) throws Exception { ExpandoTable table = null; try { table = ExpandoTableLocalServiceUtil.addTable(User.class.getName(), "BIBLIOCOMGPM_PTL"); } catch (DuplicateTableNameException dtne) { table = ExpandoTableLocalServiceUtil.getTable(User.class.getName(), "BIBLIOCOMGPM_PTL"); } try { ExpandoColumnLocalServiceUtil.addColumn(table.getTableId(), pAttribut, ExpandoColumnConstants.STRING); } catch (DuplicateColumnNameException dcne) { ExpandoValueLocalServiceUtil.deleteValue(User.class.getName(), table.getName(), pAttribut, pUserId); } ExpandoValueLocalServiceUtil.addValue(User.class.getName(), table.getName(), pAttribut, pUserId, pValue); } //// Retrieval of the custom attribute: protected Serializable getCustomAttrBiblioComGpm(String pAttribut, String pTableName, long pUserId) throws SystemException { Serializable value = null; /* * Retrieval of the value of the custom attribute */ try { value = ExpandoValueLocalServiceUtil.getData(User.class.getName(), pTableName, pAttribut, pUserId);

} catch (Exception pe) { if (_log.isErrorEnabled()) _log.error("PortalException ----- " + pe); } return value; } ///Example of call-up of addition method: try { addCustomAttribute("biblioComGpmAttr_" + instanceId, attribute.toString(), themeDisplay.getUserId()); addCustomAttribute("biblioComGpmSaveFilter_" + instanceId, saveFilter.toString(), themeDisplay.getUserId()); } catch (Exception e) { if (_log.isErrorEnabled()) _log.error(e); }

///// Example of call-up of retrieval method: Serializable custom = getCustomAttrBiblioComGpm("biblioComGpmAttr_" + instanceId, "BIBLIOCOMGPM_PTL", themeDisplay.getUserId()));

2.18 LOCATION AND NAMING RULES

An example of the naming rule to be followed by all new projects at the CoE is shown below.

Translations must be integrated in the global files for the portal and comply with the following pattern:  For titles: com.coe.project.{Portlet name}.{Variable name}

 For error messages: com.coe.project.error. {Portlet name}.{Variable name}

At least all the portlets must be located in the default portal language in the portal translation file. The implementation of languages (supported-locale) must not be integrated in the portlet.xml file.

The portal's default translation file must be maintained at the same level of translation as that of the default language.

The translation variables must be annotated with at least the following information: 1. Reference portlet 2. Author 3. Creation date

Example: ## @portlet MyPortlet ## @author First name SURNAME ## @date 12/01/2010

The variables must be entered in the translation files of the Hook on /hooks/PortalTranslation. Use the following code in the view for displaying the messages which must be located in the portal translation files:

The packages integrated in the portlets must be prefixed by: com.coe.{project}.{Portlet name}

This prefix will be represented in the rest of the document by {PREFIX}.

The tree structure of Java packages in the portlet must follow the pattern below:  {PREFIX}.domain

o Contains all the domain classes (Values Object, PoJos)

 {PREFIX}.service

o Contains all the service access classes (web service, underlying Liferay-type application service)  {PREFIX}.web

o Contains the view controllers

 {PREFIX}.validator

o Contains the validators

 {PREFIX}.util

o Contains all the Utils classes

 {PREFIX}.exception

o Contains all the portlet's exceptions

2.19 USING THE SERVICE BUILDER / DATABASE

The database tables must be created from a "service builder" service portlet and comply with the following prefixing rule: projectname_{portletname}_{tablename} Be careful with the case used: it is imperative that table names are in lower case and that underscore ("_") is used as a separator, and there must be no spaces.

SQL scripts, if used, must be delivered in a file entitled script{Portlet name}.sql, and each sql instruction must be annotated.

2.20 USING LOGGERS

Liferay loggers are the only loggers allowed. When declaring the logger, it is retrieved using the com.liferay.portal.kernel.log.LogFactoryUtil class

2.21 RULE FOR MANAGING MESSAGES IN THE LOG FILE

The error messages entered in the portal logs must, as far as possible, be translated into "Business" messages and the error stack must be displayed only in extreme circumstances or in DEBUG mode. Let us take the example of a portlet displaying data from an external feed: if that feed is not available, instead of logging the exception, a message indicating, for example, "[portlet] feed XXX unavailable " must be logged. This approach makes it possible to identify the errors encountered more quickly and considerably lightens the log file. In DEBUG mode, we must find the business error message and the error stack.

Example of using a log object:

private static Log _log = LogFactoryUtil.getLog(ClassName.class); try { _log.debug("Message :" + message); _log.info("Information :" + infos); } catch (Exception e) { _log.fatal("Erreur " + e); }

The log level is defined in the Log4j.properties file, for example:

log4j.rootCategory=ERROR,stdout # sortie par défaut log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternL ayout log4j.appender.stdout.layout.ConversionPattern= %d{ABSOLUTE} %-5p [%c{1}:%L] %m%n

Simply replace the ERROR level with DEBUG to put the portlet into debug mode.

Log levels for the platform:  Integration: DEBUG

 Acceptance testing: ERROR  Pre-production: ERROR

2.22 MISCELLANEOUS POINTS

 One dedicated configuration file must be created per environment;  The user should be able to modify these settings, using portlet preferences or portal settings;

 For MMI development, it is preferable to use the tools provided by Liferay (Liferay IDE / Developer Studio); we advise against using TIBCO General Interface Builder or similar tools, as the feedback on this type of generator is not conclusive;  Never use System.out.println to write in log files;

 In principle, never use the ERROR or FATAL log level in a render method, which would excessively overload the production logs. Instead, use the WARN level, unless it is really a case of error;  For methods heavily impacting on performances, it is a good idea to replace concatenations with a call-up of the StringBundler class, on the following equivalence principle:

a+b  (new StringBundler(2)).append(a).append(b).toString()

2.23 JAVASCRIPT INTEGRATION WITHIN A PORTLET

2.23.1 LOADING THE CSSS SPECIFIC TO THE PORTLET

You should not integrate the formatting code in the portlets, but instead place them in the theme.

2.23.2 LOADING THE JAVASCRIPT FILES SPECIFIC TO THE PORTLET

Calls for Javascript business processes upon page loading must be systematically made in the JSPs of the portlets with:

jQuery.ready() ; (http://api.jquery.com/ready/ )

The javascript variables must be systematically prefixed with the name of the portlet, to avoid conflicts between variables.

2.23.3 RESOURCES LOADING LEVEL JS and CSS static resources may be loaded either in the page header or in the page footer. Depending on the needs, both loading methods may be used. It should be noted that these resources must be loaded only from the instructions of the liferay- portlet.xml file. In no circumstances must they be "hard-loaded" in the JSP views.

Example of a Liferay instruction:

/css/jquery-ui-1.8.6.custom.css /js/jquery-ui-1.8.6.custom.min.js

2.24 SOURCES CONTAINED IN THE SOURCES MANAGER

The sources deposited in the manager must: - not contain compiled sources - not contain any .bak file or similar history - not contain functionalities that are not to be delivered - not contain any writing on the standard output or the error output - be in UTF-8 without a BOM

2.25 SETTING UP A SPECIFIC COMPILATION

Some portlets will require specific configuration in the portlet.properties file, or other configuration files, depending on the environment.

This is the procedure for a specific compilation:

 At the root of the portlet (at the level of the build.xml file) create the ant/files tree structure  In ant/files add the properties file templates

The data that may change from one environment to another are replaced with tags, which will be updated during the build. These tags take the following form: @NAME_OF_THE_VARIABLE@

Example of template file content

portlet.webservice.url=@MYPROJECT_WEBSERVICE_URL@

Then, to replace the variables, you must update the build file (build.xml) as follows:

Overriding portlet.properties for my project

@MYPROJECT_WEBSERVICE_URL@

Finally, upon delivery, you must specify the keys to be added/modified in the build configuration file. In the above example, it is the myproject.webservice.url variable.

The names of the variable must be prefixed with the name of the portlet.

2.26 RESTRICTING THE VISIBILITY OF NEW PORTLETS

2.26.1 PORTLET VISIBLE ONLY IN BACKOFFICE In the liferay-portlet.xml file, simply add the following line in the portlet configuration

2.26.2 PORTLET VISIBLE AT THE LEVEL OF AN INSTANCE A specific test must be carried out in the class controlling the display of the portlet. This class must be added in the portlet configuration in liferay-portlet.xml .

com.coe.obs.portlet.simulatedpurchase.SimulatedPurchaseControlPanelE ntry

Example:

public class SimulatedPurchaseControlPanelEntry extends BaseControlPanelEntry {

public boolean isVisible(PermissionChecker permissionChecker, Portlet portlet) throws Exception { return "obs.coe.int".equals(CompanyLocalServiceUtil.getCompanyById(portlet.getCom panyId())); }

2.26.3 PORTLET VISIBLE AT THE LEVEL OF ONE OR MORE SITES A specific test must be carried out in the class controlling the display of the portlet. This class must be added in the portlet configuration in liferay-portlet.xml .

com.coe.portlet.job.management.JobManagementControlPanelEntry

Example:

public class JobManagementControlPanelEntry extends BaseControlPanelEntry {

/* * (non-Javadoc) * * @see * com.liferay.portlet.BaseControlPanelEntry#isVisible(com.liferay.portal * .model.Portlet, java.lang.String, com.liferay.portal.theme.ThemeDisplay) */ public boolean isVisible(Portlet portlet, String category, ThemeDisplay themeDisplay) throws Exception { boolean isVisible = super.isVisible(portlet, category, themeDisplay);

String webId = PortletProps.get("context.webid"); String siteName = PortletProps.get("context.site");

Company c = CompanyLocalServiceUtil.getCompanyByWebId(webId); Group g = GroupLocalServiceUtil.getGroup(c.getCompanyId(), siteName);

Group g2 = themeDisplay.getScopeGroup();

if (g.hasStagingGroup() && g2.getGroupId() != g.getStagingGroup().getGroupId()) { isVisible = false; }

return isVisible; }

public boolean isVisible(PermissionChecker permissionChecker, Portlet portlet) throws Exception {

boolean isVisible = false;

if (PortletPermissionUtil.contains(permissionChecker, portlet.getPortletId(), ActionKeys.ACCESS_IN_CONTROL_PANEL)) {

isVisible = true; }

return isVisible; }

DOCUMENT END

Version : 1.1 Page 29 / 29

Liferay Development Standards

$title.getData()