Mar 7, 2018 3:18:49 PM seb leridon avatar
Home History fr en

Version 4 evolutions

Version 4.0.0

CSS Bootstrap framework integration

All back office and forehead templates are modified to use the Bootstrap framework and its ability to do Responsive Design.

See the details of the implementation standards: Integration of the Bootstrap framework in Lutèce

Datastore

Creating a key / value storage system. This device makes it possible to store configuration values, states and execution logs.

The name of the keys must be prefixed by the name of the plugin.

Example of implementation: the SEO plugin

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))
{
      ...
}

Preferences

Two new services are available to store user preferences: one for those of the Back Office and the other for those of the Front.

Version 4.0.1

Many fixed bug.

Version 4.1.0

Change in the file management plugins.dat

In order to manage the state of plugins and pool configuration in cloud deployments (such as CloudBees), it is no longer possible to store these values ​​in the file system. They are now saved in the Datastore.

The plugins.dat file is now only used to initialize the Datastore at startup. If a key is already in the Datastore, the value in the file is ignored.

New management of the properties of the site and disappearing of the file webmaster.properties

The properties of the site (name, meta tags, ...) are now stored in the Datastore and no longer in the file webmaster.properties which disappears.

A new Datastore mechanism is used to locate labels and help texts associated with keys (i18n translations into resource based Datastore keys).

Plugins can now add their properties in the admin interface of the Admin Feature "Site Properties".

See the GTools plugin that implements these two latest features.

New keys added to the properties of the site:

  • Home URL: allows to define the URL of the redirection made by index.jsp (root of the webapp)
  • No Reply Email: The no-reply email is now configured in this interface instead of the config.properties

In case of problems resulting from the use of the old keys of the webmaster.properties by plugins (crashing Freemarker for example), a properties file containing the missing keys can be created in the directory WEB / conf / override / plugins for example.

Evolutions of the Datastore

The datastore has a cache system that can be managed in cache management.

New features allow:

  • retrieve a key / value group in a ReferenceList from a key name prefix
  • to locate key groups (LocalizedDataGroup)
  • to know if a key exists (existsKey)

Examples of implementation: SystemJspBean and GTools plugin

Replacement in key templates by their value in the Datastore

A new formalism makes it possible to realize at the time of the loading of the template a substitution of keys by their value in the Datastore.

The syntax is similar to that for the internationalization keys (i18n), the prefix here being #dskey. Example: 

<p> #dskey {myplugin.mafunction.maclete} </p>

New meta generator tag

This meta tag being in the <head> section of the pages, indicates that the page was produced by Lutece as follows: 

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

To add this tag in an old webapp, just add the following line in the <head> section of page_frameset.html. 

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

New ability to set the default back office and front page.

The URL of the home page of the Back Office and that of redirection of the root of the webapp can now be modified.

They can be defined through the "Site Properties" stored in the Datastore. If you do not want to display these values ​​in the property management interface of the site, simply delete the keys portal.site.site_property.admin_home_url and portal.site.site_property.home_url Datastore and the values ​​will be retrieved through the lutece.admin.menu.url and lutece.portal.redirect.url keys in the lutece.properties file or an overload of the WEB-INF / conf / override directory in case the default values ​​are changed .

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

Added a Front Office authentication filter

This authentication filter is intended to check in the case where the mandatory authentication is activated that the user is authenticated.

This filter takes into account a list of public URLs to allow unauthenticated access to certain pages of the site.

The list of public URLs is configurable in the page dedicated to the technical administration of the portal and plugins.

By default this list is empty and should be enriched including URLs necessary for the operation of the authentication module used.

Example of use with the mylutece database module

URLs to add to the list of public URLs are as follows

URL Value
Display URL of the login page jsp / site / Portal.jsp? Page = mylutece & action = login
Login processing URL jsp / site / plugins / mylutece / DoMyLuteceLogin.jsp
Logout processing URL jsp / site / plugins / mylutece / DoMyLuteceLogout.jsp
Account Creation page display URL jsp / site / Portal.jsp? Page = mylutecedatabase & action = createAccount
Password loss page display URL jsp / site / Portal.jsp? Page = mylutecedatabase & action = lostPassword
Login loss page display URL jsp / site / Portal.jsp? Page = mylutecedatabase & action = lostLogin
Password reset request display URL jsp / site / Portal.jsp? Page = mylutecedatabase & action = reinitPassword
All the action processing URLs above jsp / site / plugins / mylutece / modules / database / *

Evolutions of the editor BBCode

New BBCode tags have been added. These tags have been declared in the editors.properties file.

Adding Freemarker macros for front office

Freemarker macros, similar to the macros used in Back Office, have been added for use in Front Office. It is now possible to override the Front Office macros without overloading the Back Office Macros.

These new macros are declared in the Webapp / WEB-INF / templates / commons_site.html file

What's new about bean population and validation (JSR 303) for back office JspBean

Improved support for the JSR 303 described on the following page: Validating Beans

The code for creating an object in the presentation layer can now be written as follows: 

// 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: the populate method can load the parameters whose name conforms to the LUTECE norms ie tiny + underscores
NB: The stand and validation methods are available for the other components (XPages through a new class AbstractXPageApplication, JspBean Front, ...) and can be found in lutece.util.bean.BeanUtil and lutece.util. beanvalidation.BeanValidationUtil.

Instantiation of XPage

XPage objects are now instantiated for each HTTP session instead of being shared.

Updating DataTableManager

Multiple tables of data can now be used on a single page without causing sort, pagination, or filter mixing. To be able to use several DataTableManager on the same page, it is obligatory that they be registered in session, and not created with each request of the user.

Managing user preferences

For the management of the preferences of the users of the Front Office the service UserPreferencesService now offers the recovery of the pseudo chosen by the user and its update. 

String strPseudo = UserPreferencesService.instance (). GetNickname (user);
String strPseudo = UserPreferencesService.instance (). GetNickname (strUserId);
UserPreferenceService.instance (). SetNickname (strUserId, strNewNickname);

Generating portlet content without using an XSL style sheet

Portlets can now generate their content in two different ways:

  • using the historical method: using XSL stylesheets
  • by directly generating the HTML content to be displayed.

Existing portlets (thus using XSLs) have unchanged operation. Portlets wishing to generate their HTML content without using XSL (for example with Freemarker templates) must extend the class fr.paris.lutece.core.business.portlet.PortletWithoutXsl and implement the method public String getHtmlContent (HttpServletRequest request)

New MVC framework for front and back office

The MVC library has been kernel-dependent to develop XPages and Admin Features using the MVC paradigm.

This library offers:

  • Dispatching queries by the controller for processing actions and displaying views
  • The identification of actions and views by annotations,
  • Population and validation of beans (JSR 303)
  • Management of validation errors directly included in the template of the template (marker "errors")
  • The management of the notifications or informative messages included in the model of the template (marker "infos")
  • HTTP redirection of requests to views avoiding the use of JSPs
The PluginWizard plugin generator generates (from version 3.2) Admin Features using this MVC framework. In addition, the source code of this plugin is a good example of using the MVC framework to perform XPages.

Version 4.1.1

Added the possibility of not caching the contents of some portlets

The contents of portlets on a page can be cached in two ways:

thanks to the page cache, which records in cache for a user the different pages that are generated. thanks to the portlet cache, which stores the generated content for each portlet in cache.

To allow some portlets to not display stale data without disabling these two caches, a mechanism has been put in place so that each portlet can specify whether it allows the content it generates to be cached or not.

This permission goes through two methods of the class fr.paris.lutece.portal.business.portlet.Portlet:

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

public boolean canBeCachedForConnectedUsers ()
{
    return true;
}

The canBeCachedForAnonymousUsers () method is used to specify whether portlet content can be cached for non-connected users. The canBeCachedForConnectedUsers () method is used to specify whether portlet content can be cached for logged in users.

When a page is generated (and thus if it is not already cached), the page checks if all its portlet allows or not the caching of the content for the current user (anonymous or connected). If all portlets allow it, then the generated HTML is saved to the page cache (if enabled). If at least one portlet does not allow it, then the generated page is not saved to the page cache.

The operation of the portlet cache remains relatively the same as the old operation, except that the generated content is cached only if the portlet allows it for the current user (anonymous or connected).

The default implementation of this mechanism allows caching for all portlets. To modify this behavior for a portlet, just overload the two methods described above.

Be careful, disabling the cache for unauthenticated users can cause a significant decrease in performance!

Version 4.2

The mother implementation of XPages is Serializable which allows specific implementations that are not explicitly defined Serializable to work in a context where session variables can be serialized.

This version does not bring very few new features. This is a version that fixes a number of issues in 4.1.x.

Version 4.3

The choice of incrementing the intermediate version number (and not the minor one) is justified by the following two important changes:

New Freemarker macros

4 Freemarker macros to simplify the creation of forms have been created:

  • fieldInputText: to display a text field. This macro has the following parameters:
    • i18nLabelKey (text type): The label's i18n key to display (required).
    • inputName (text type): Name of the generated input (required).
    • mandatory (Boolean type): Indicates whether the field is a required field or not (optional).
    • value (text type): default value (optional).
    • maxlength (integer type): The maximum number of characters in the field (optional).
    • i18nHelpBlockKey (text type): i18n key of the help text (optional).
    • cssClass (text type): CSS class of the generated input (optional).
  • fieldInputCalendar: to display a text field with a calendar. This macro has the following parameters:
    • i18nLabelKey (text type): The label's i18n key to display (required).
    • inputName (text type): Name of the generated input (required).
    • mandatory (Boolean type): Indicates whether the field is a required field or not (optional).
    • value (text type): default value (optional).
    • i18nHelpBlockKey (text type): i18n key of the help text (optional).
    • cssClass (text type): CSS class of the generated input (optional).
    • language (text type): language of the datepicker (optional, default value: 'fr')
  • fieldInputCheckBox: Displays a checkbox. This macro has the following parameters:
    • i18nLabelKey (text type): The label's i18n key to display (required).
    • inputName (text type): Name of the generated input (required).
    • checked (Boolean type): Default value of the check box (required).
    • mandatory (Boolean type): Indicates whether the field is a required field or not (optional).
    • value (text type): default value (optional).
    • i18nHelpBlockKey (text type): i18n key of the help text (optional).
    • cssClass (text type): CSS class of the generated input (optional).
  • fieldInputText: to display a long text field. This macro has the following parameters:
    • i18nLabelKey (text type): The label's i18n key to display (required).
    • inputName (text type): Name of the generated input (required).
    • mandatory (Boolean type): Indicates whether the field is a required field or not (optional).
    • value (text type): default value (optional).
    • maxlength (integer type): The maximum number of characters in the field (optional).
    • i18nHelpBlockKey (text type): i18n key of the help text (optional).
    • cssClass (text type): CSS class of the generated input (optional).

Example:

The following code allows to have a form with three fields names, first names and date of birth: 

< form action = " " class = " form-horizontal " >
    < @fieldInputText i18nLabelKey = 'myplugin.user.labelFirstName' inputName = 'firstname' value = firstname! '' mandatory = true maxlength = " 255 " / [Gt;
    < @fieldInputText i18nLabelKey = 'myplugin.user.labelLastName' inputName = 'lastname' value = lastname! '' mandatory = true maxlength = " 255 " / [Gt;
    < @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 " > [Lt; / i > Confirm
        [Lt; / button >
    [Lt; / div >
[Lt; / form >

Added email information to the object LuteceUser

The LuteceUser object now has a read-only Email attribute. The default implementation of the new getEmail () method returns null. It is up to each authentication module to provide its own implementation.

This solution was preferred over an abstract method that would have made the current versions of the modules incompatible.

To benefit from the email, the authentication modules must rely on the version 3.1 of MyLutece (which requires at least the version of core 4.3).

So the version of MyLuteceDatabase 3.1 that uses email requires at least Lutece v4.3.

For example, a configuration to use the Avatar and AvatarServer plugins with MyLuteceDatabase requires the tagged versions:

  • MyLuteceDatabase 3.1
  • MyLutece 3.1
  • Lutece 4.3

Version 4.4

New Freemarker macro for forms

  • fieldInputCombo: Displays a drop-down list. This macro has the following parameters:
    • i18nLabelKey (text type): The label's i18n key to display (required).
    • inputName (text type): Name of the generated input (required).
    • items (ReferenceList type): Lists of objects to add in the drop-down list (required).
    • mandatory (Boolean type): Indicates whether the field is a required field or not (optional).
    • value (text type): default value (optional).
    • i18nHelpBlockKey (text type): i18n key of the help text (optional).
    • cssClass (text type): CSS class of the generated input (optional).

Blobstore component export

Blobstore classes in the core up to 4.3.0 have been moved to the library-blobstore library.

This solution makes it possible to improve the modularity of the core and to access the files of the blobstore in batches.