Offre poste

Dans le cadre du développement de nos activités nous recherchons des ingénieurs pour oeuvrer au forfait sur des projets de portails d'entreprise. 
Les connaissances idéales pour ce poste sont : 
- Liferay
 - Java 
Accessoirement vous posséder des compétences sur les technologies suivantes : 
- Alfresco 
- Talend 
- Birt 
- GWT


Me contacter via mon profil ou directement à christophe.cariou@groupe-asten.fr

Navigateurs, compatibilité et respect des standards

Dernièrement, Mozilla (ou du moins un de ces gourous) et Microsoft se sont affrontés sur le thème du respect des standards par leurs navigateurs respectifs.

• FFox : http://people.mozilla.com/~prouget/ie9/
• IE : http://blogs.msdn.com/b/ie/archive/2011/02/10/acting-on-feedback-ie9-release-candidate-available-for-download.aspx

Le site http://www.caniuse.com/ présente quant à lui de façon impartiale le résultat des tests de "compliance" des différents navigateurs/versions du marché.

Liferay, GWT Portlets

Enfin un tuto complet sur la mise en oeuvre de portlet GWT dans Liferay, et pas seulement du widget de base... Non, là c'est bien avec branchement (RPC) sur les services de persistance généré par le Service Builder de Liferay.

A tester ...

WIP : Web Integration Portlet

Un projet OpenSource (initié par Ippon) qui semble aller plus loin que le projet PortletBridge, implémenté dans la portelt WebProxy de Liferay.

En gros il s'agit d'une portlet permettant de "proxyfier" (néologosime) une application web existante, même distante. A ne pas confondre avec le principe de l'IFrame qui n'est qu'un artifice de présentation au sein du navigateur.

Présentation

Le portlet d’intégration web, ou Web Integration Portlet (WIPortlet), est un portlet basé sur la spécification JSR 286 et réalisé sous la forme d’un projet Maven 2. Il a été développé pour répondre au besoin d’intégration d’une application web distante ou d’un contenu web quelconque dans un portail, quel que soit la technologie utilisée.

Le portlet se comporte comme un proxy web positionné entre le portail et l’application. La configuration minimale ne requiert que l’URL ciblée. Initialement, cette URL permet de requêter l’application distante depuis le portlet. La réponse est traitée, en particulier les liens dans le code retourné sont réécrits en URL de portlet, avant d’être redirigée vers le portail.

Un mécanisme de clipping permet de modifier le contenu récupéré pour l’adapter aux besoins du portail. Des mécanismes d’authentification, de gestion des cookies et de mise en cache sont également implémentées.

Intérêt de l’intégration dans un portlet et difficultés

Face à un portlet de ce type, une question revient régulièrement: quel est l’intérêt par rapport à un portlet de type iframe ?

La réponse est simple : l’intégration réalisée avec le WIPortlet consiste en une réelle intégration de l’application dans l’environnement du portail alors qu’un iframe se contente d’intégrer le document HTML dans son intégralité sans communication avec le portail.

En effet, dans le cadre du WIPortlet, les requêtes vers le serveur de l’application distante sont réalisées depuis le portail. Cela donne la possibilité de manipuler la réponse avant qu’elle soit retournée. En particulier, le contenu est extrait des balises body, et les scripts et feuilles de styles sont extraits des balises head. Ensuite, les liens sont réécrits pour que la navigation se fasse dans l’environnement du portail.

Un autre avantage de taille est le mécanisme de clipping qui offre davantage de liberté vis à vis de l’application à intégrer. Par exemple, on peut choisir de n’intégrer que certaines parties du contenu distant.

L’inconvénient de ce type de portlet est l’augmentation du temps de réponse dû aux traitements effectués par le portlet, même s’il peut être améliorer à l’aide du mécanisme de cache implémenté.

D’autre part, l’intégration de l’application distante peut s’avérer compliquée, notamment à cause de conflits pouvant exister avec les scripts et les feuilles de style déjà présent dans le portail. La configuration du portlet apporte des solutions pour remédier à ses difficultés. Enfin la gestion des requêtes AJAX nécessite une configuration précise et parfois une personnalisation du code du portlet pour l’adapter à l’application.

Utilisation

Le portlet a été développé sous la forme d’un projet Maven. Dans les sources, le fichier pom.xml de Maven définit plusieurs profils permettant de s’adapter aux différents portails et/ou serveurs. Par exemple pour compiler le portlet pour un portail Liferay fonctionnant avec Tomcat, la commande Maven sera:

1	mvn -P liferay-tomcat package

Une fois le WAR déployé, une ou plusieurs instances du portlet peuvent être ajoutées au portail.

L’onglet « Préférences » permet de configurer le portlet en précisant notamment l’URL de l’application distante. La configuration est séparé en plusieurs catégories: configuration générale, cache, réécriture HTML, réécriture CSS, réécriture Javascript et clipping. L’utilisateur à également la possibilité de sauvegarder ses configurations puis de les réutiliser.

Le projet Web Integration Portlet (WIP) est aujourd’hui donné à la communauté Open Source sous licence LGPL et est accessible sur la plateforme github à l’adresse suivante : https://github.com/ippontech/wip

TRON .... et TROFF

TRON, c'est un film et sa suite qui sort cette semaibe sur les écrans.

Mais TRON (Trace On), c'est à l'origine une commande en Basic destinée à activer le mode debug d'un programme.

Ce mode debug faisait apparaître le n° de ligne exécuté sur la console. Pratique pour analyser les boucles et sauts (GOTO,GOSUB).

La commande TROFF (Trace Off) suspendait le debug.


Tout ça me rappelle mes cours sur TRS80 au collège...

Premier déploiement Liferay cluster...

Ca y est, j'ai déployé mon premier Cluster Liferay.

Alors, qu'avons nous dans cette architecture :
- 1 BDD basée Oracle ARF (ça aurait pu être RAC)
- 2 vm Linux hébergeant 2 instances Liferay.
- 1 Load Balancer (en Round Robin)
- 1 ReverseProxy Apache/Vulture

Quelques particularités :
- Tout le Content Store est en base (Doc, Image...)
- Index Lucene en base
- EHCache synchronisé dans le Cluster

Ce qui est intéressant dans cette architecture, c'est que chaque instance Liferay peut être "masterisée" et dupliquée telle quelle, sans paramétrage spécifique, sur de nouvelles vm.
Le seul paramétrage est l'ouverture d'une nouvelle IP/port sur le load Balancer.

Dan la théorie (et même en pratique), on peu augmenter ainsi la taille du cluster indéfiniment...

Liferay, Alfresco : conjonctions de coordination

Alfresco s'était rapproché de Liferay via une meilleur Portletisation de ses applications (share webscripts...)

C'est au tour de Liferay de faire un pas vers Alfresco avec la possibilité de s'appuyer sur celui-ci comme Content Store pour les documents, via CMIS. 

Autrement dit, un document dans Liferay est directement présent dans Alfresco. Je ne parle ici que des fichiers, chaque système gérant ses propres metadatas.

Dans le même temps Liferay devient producteur et consommateur CMIS.

Tout ça c'est pour la 6.1.