Mercredi 23 mai avait lieu le 2ème Liferay Symposium France à Paris. Cette conférence des utilisaterus de Liferay disposait de 2 types de sessions : des sessions techniques et des sessions “commerciales” (http://www.liferay.com/events/liferay-symposiums/france-2012/program).

La journée a commencé par un talk du CEO de liferay (Bryan Cheung) puis par celui du COO (Brian Kim).

Le Marketplace

Le Marketplace est la fonctionnalité majeure mise en avant car elle va définir un nouveau business model pour les développeurs d’application et un nouveau moyen pour une entreprise de diffuser des fonctionnalités en interne.

Comme tout AppStore(c) le Marketplace de Liferay dispose d’une vitrine sur laquelle les applications peuvent être notées, une fonctionnalité de paiement (Liferay prend 20%) et l’installation en un clic.

Le Marketplace devrait voir le jour cet été et le business model pour les entreprises est à inventer. Pour un marketplace interne à une entreprise, cela dépendra de l’organisation de celle ci. En effet le choix des applications déployées dans un site sont à l’initiative de la MOA, alors que le modèle derrière un Marketplace est plutôt la mise à disposition d’une application qui sera ou non installée. Pour un marketplace public, Liferay hébergera les applications et permettra aux éditeurs de logiciel comme aux développeurs indépendants de proposer leurs applications à la vente ou bien gratuitement.

Session Tips & Tricks

Olaf Kock, consultant senior chez Liferay nous a ensuite fait une démonstration des Dynamic Data List via la création d’un formulaire de création de contact. Puis, avec l’utilisation du plugin Kaleo (disponible en version EE seulement), Olaf a ajouté un workflow de validation.
Ce plugin permet de faire des workflow assez complexes et dispose d’une interface plutôt sympathique.


Pour terminer le speaker nous a montré quelques tips qu’il a utilisé sur http://www.liferay.com/radio

Etat de l’art de l’ergonomie et du design

Le slot suivant était centré sur le design des sites et donc non spécifiques à Liferay. Il était présenté par Rachel Fremau de SQLi. Si vous avez déjà travaillé sur des sites web de type portail, les recommandations de Rachel ne vous aurons pas appris énormément. Ce qui était intéressant de montrer c’est comment, à partir du même site et en conservant au maximum l’ergonomie par défaut de Liferay, un simple changement d’image en arrière plan pouvait rendre un site différent. Plusieurs exemples de sites nous ont été exposés.

Réaliser des montées de version sur Liferay

Sébastien Le Marchand d’SQLi a pris la suite pour nous parler des montées de version de Liferay.

Ses conseils sont les suivants :

  • mettre à jour la configuration,
  • puis le portail,
  • ensuite les données
  • et enfin les développements spécifiques.

Le gros du travail sera à mener sur ces développements spécifiques, pour le reste Liferay s’occupe de la migration.

Depuis la version 6.0-SP2, Liferay dispose d’un système de hotfix qui permet de patcher le portail sans avoir à réaliser une montée de version totale qui engendrerait un coût important.
Pour réaliser la montée de version sur les développements spécifiques sur les thèmes, les template et le web, la mise à jour se fait en 3 étapes : builder, déployer, tester. On itère jusqu’à obtenir une version stable.

Pour les hook et les ext, ils contiennent souvent du copier coller de code Liferay, la montée de version doit donc être adaptée.

Quelques bonnes pratiques concernant les développements spécifiques des hook et des ext :

  • préférer l’include de jsp plutôt que le copier coller
  • préférer l’héritage de classe plutôt que le copier-coller (!?)
  • utiliser le PortalClassInvoker qui permet d’accéder à une classe du portail via un plugin

Ces recommandations semblent être du bon sens, ce n’est à priori pas le cas pour tous les développeurs.

Sébastien évoque ensuite la possibilité via l’api reflect de java d’accéder à des méthodes privées. Aprés les bonnes pratiques évoquées ci dessus cette suggestion est pour le moins surprenante car si des méthodes de l’api sont privées, c’est certainement pour une bonne raison.

Si le copier coller de code Liferay est inévitable il recommande de ne pas reformater ni refactorer afin de pouvoir faire un merge avec la futur version, et de mettre notre code spécifique entouré de commentaire pour identifier rapidement les modifications apportées.

Concernant la migration de données, la bonne pratique est d’implémenter le process d’upgrade au sein des plugins. Ce mécanisme est utilisé pour les import/export et sera utilisé dans le cas d’une montée de version.

Pour les migrations multisource il faut monter de version chaque instance source, exporter les données au format LAR (Liferay ARchive) puis les importer dans l’instance cible. Le problème en effectuant cette manipulation est entre autre que les dates de publication dans les forums vont être celles de l’import et non les dates d’origine. De même les références à un user id vont être perdues puisque le système cible n’aura plus les même ids.
Pour palier à cela il faut soit modifier l’import/export de données, soit effectuer le rattrapage directement en SQL.

Pour terminer, comme pour tout produit il faut trouver le bon rythme de migration :

  • évaluer les avantages
  • considérer les hotfixes
  • ne pas attendre de faire un saut de géant

Gestion plus avancée des contenus Web

Juan Fernandez a ensuite échangé sur la gestion des contenus webs.
Dans le cas d’une gestion multisite, les uses cases peuvent être catégorisés en 2 parties :

  1. toutes les sites sont différents avec seulement quelques pages en commun,
  2. tous les sites sont identiques mis à part quelques pages.

Dans le premier cas on appliquera un template de page, dans le second un template de site.
S’en suit une démo illustrant ces fonctionnalités.

Juan présente ensuite la fonctionnalité de staging qui permet à l’administrateur de travailler sur une version du site dans un espace cloisonné et de programmer la mise en ligne. L’exemple pris est celui d’un journal où la homepage serait différente le dimanche. La semaine, l’administrateur peut travailler sa page (on parlera de “page variation”) et programmer sa publication pour le dimanche matin.

Un autre exemple est le site version noêl (on parlera de “site variation”). Le principe reste le même. Les page variations et site variations peuvent être couplées à un workflow de validation.
Pour le moment seul une mise en ligne par planning est possible. Néanmois Liferay expose sont API ce qui peut permettre de coder la mise en ligne sur réception d’un autre évènement.

Liferay Social Office 2.0

Joseph Shun nous a présenté le produit Social Office qui permet de réaliser un RSE. Il fournit une gestion des activités, des contacts, du dockbar, invitations, notifications, projets et sites.
C’est un produit qui se mettra en place via le futur Marketplace. Le lancement de Social Office est dépendant de ce dernier.

Le Business Model de Liferay

La session de Ruud Kluivers sortait du cadre technique puisqu’il a retracé son expèrience sur la mise en place chez son ancien employeur d’un portail et son cheminement pour convaincre sa hiérarchie de baser leurs développements sur un produit open source. Le changement de business model de Liferay en 2008 a aidé avec la création de la version Entreprise.
Le business model de Liferay a ensuite été expliqué par Joseph Chun. Il est commun a plusieurs acteurs du monde opensource.
La version community sert de base à la construction de la version EE. Elle dispose des hotfix et des Services Pack et ces derniers sont reversés dans la version community.
L’avantage de la version Entreprise est que si un bug est détecté dans une version du produit, le patch est appliqué sur les versions antérieures pendant 4 ans.

Le futur de Liferay

Pour terminer Bryan Cheung nous a fait un talk de clôture “à l’américaine”. Les slides

En partant du business model opensource et du paradigmne “je donne à la communauté et je profite de son retour”, Bryan nous a entraîné vers sa participation à des actions humanitaires en faveur des rescapés de Fukushima ou de l’ouragan Kathrina.

Sa croyance dans les institutions à but non lucratif avait comme objectif de rassurer les clients et partenaires sur l’ambition de Liferay au sujet d’un éventuel rachat et de nous faire partager ses convictions.
Cette session de clôture n’avait pas pour objectif de nous faire croire que Liferay aller changer le monde, mais il nous a permis d’entendre les raisons “philosophiques” qui font que Liferay est opensource.

Bilan

De nombreux partenaires et clients étaient présent à ce symposium et la présentation autour du marketplace et de Social Office nous a permis de partager la vision stratégique de Liferay sur le futur. Il n’a pas été question de Cloud ou de mobilité même si cela reste en filigrane. Il y eu peu de présentation technique, le sentiment était plus de se montrer rassurant face au marché français, marché sur lequel Liferay investit avec l’arrivée de Marc Brassier.