Il m’arrive souvent de m’interroger ou d’être interrogé sur la pertinence et la nécessité d’Eclipse Scout. Là où je travaille (l’entreprise derrière Eclipse Scout), son emploi pose certainement moins de questions que pour ceux qui découvriraient ce framework pour la première fois.

Lorsque je suis amené à parler d’Eclipse Scout, je commence toujours par dire qu’Eclipse Scout ne répond pas à tous les besoins. C’est un point crucial, car selon moi, il faut bien avoir compris ce que le projet propose pour pouvoir en évaluer la pertinence pour soi-même.

Il ne faut pas survendre le framework, mais parler de ses qualités en expliquant ses limites. Dans ce billet, j’ai essayé de m’intéresser à différents points en pensant aux entreprises.

Uniformité du fonctionnement de l’application.

Eclipse Scout se concentre sur les applications métiers. Les besoins de ce type d’application sont limités. On se trouve face à des listes de données représentant des entités avec une certaine dépendance entre elles. La plupart du temps, ces données doivent pouvoir être éditées. Enfin on souhaite pouvoir compléter ces données avec des éléments graphiques (diagramme…).

De ce point de vue, la liberté offerte par la plateforme Eclipse (RCP ou maintenant e4) est trop grande :
l’expérience utilisateur va dépendre de ce que les développeurs auront défini. Sur un gros projet, cette liberté aura pour effet de ne pas proposer d’expérience uniforme sur l’ensemble de l’application.

En se focalisant sur les besoins des applications métier, des choix ont été faits dans Eclipse Scout. Ils limitent les possibilités pour le développeur, mais garantissent l’uniformité de l’application.

Avec un framework, tout le monde travaille de la même manière.

Un framework comme Eclipse Scout force les développeurs à coder de la même manière. L’architecture est prédéfinie par les outils du SDK. Il n’y a pas de questions à se poser : les règles de validation métier vont à un endroit, le code de persistance des données se retrouve à un autre endroit et ainsi de suite.

Avantage certain pour une entreprise avec plusieurs projets fondés sur le même framework : un développeur s’y retrouve très vite. S’il débute sur le projet, il va être très vite opérationnel. S’il intervient en tant qu’expert, il saura où chercher et comment s’y retrouver.

Dans une application RCP plus classique, l’organisation cohérente du code n’est pas impossible, mais elle dépend de la volonté de l’équipe (et du temps qui y est consacré).

Le modèle d’application : une garantie de pérennité.

Avoir un modèle d’application (indépendant de la bibliothèque de rendu) permet de garder une certaine flexibilité et évolutivité. Les besoins et les technologies changent. Travailler au niveau d’un modèle d’application permet de séparer la logique métier de la manière dont l’application fonctionne en interne.

Eclipse change sa plateforme applicative ? Par une adaptation de la couche «runtime» d’Eclipse Scout, la nouvelle version est supportée. À long terme Swing n’est plus maintenu par Oracle ? Ce jour-là, le runtime aura été adapté pour utiliser la technologie qui remplace Swing (JavaFx ou autre chose).

Dans le même ordre d’idée : le besoin d’avoir une instance web de nos applications s’est fait sentir. Nous avons étendu le runtime pour pouvoir en disposer pour toutes nos applications de cette possibilité (c’est une nouveauté de la version 2012. Cette extension est fondée sur Eclipse RAP).

Tout n’est pas parfait pour autant : les applications créées sont dépendantes de la couche «runtime». Par exemple avec Eclipse Juno, le mécanisme d’internationalisation a changé : de l’utilisation d’un Singleton, on est passé à un Service OSGi (comme partout ailleurs dans Eclipse Scout). Lors de la migration d’une application utilisant la version 2011 à la version 2012, cette partie-là est à remanier (à grands coups de rechercher remplacer – mais tout de même).

Autre limite, celle des éléments disponibles dans le modèle d’application : il n’existe pour le moment pas de composant «Table Tree». Cela ne veut pas dire que le modèle ne peut pas être étendu pour en disposer (c’est possible), mais aujourd’hui, cela ne fait pas partie du standard. Autre exemple de limite : il n’est pas prévu de pouvoir modifier le fonctionnement de la tabulation dans une fenêtre. Il faut se contenter de ce qui est proposé par défaut. Ce sera bien suffisant dans l’immensité des cas, mais pour des besoins spécifiques, pour le moment, cela ne fait pas partie du périmètre d’Eclipse Scout.

Ce qu’il manque à Eclipse Scout

Si le framework Scout existe en interne depuis longtemps, il est encore jeune en tant que projet open source. Eclipse Scout doit passer du statut de framework interne d’une entreprise, à un outil que chacun puisse utiliser. Les efforts accomplis dans ce domaine sont très importants, mais le résultat n’est pas encore à la hauteur des attentes des standards du domaine.

Il ne s’agit pas d’ajouter des couches ou des fonctionnalités dans le framework, mais plutôt de mieux expliquer et documenter ce qu’il est possible de faire. Évidemment c’est un processus qui demande du temps et pour lequel une certaine demande doit exister. Pour le moment, cette demande s’exprime à travers le forum du projet. Toutes les questions posées sont traitées avec une grande attention.

J’imagine qu’en cela Eclipse Scout n’est pas différent de n’importe quel autre projet open source.

En savoir plus ?
* Lisez mon article : premiers pas avec Eclipse Scout.
* Retrouvez ma page Eclipse Scout rassemblant une collection de ressources.
* La page officielle (en anglais) constitue également un bon point d’entrée.