Archives pour la catégorie Eclipse

Fichiers *.product et Eclipse Scout

En lisant un bon article sur les fichiers *.product (Create a product configuration), je me suis dit que je n’avais jamais écrit sur la manière dont Eclipse Scout les utilisait.

Une application Eclipse Scout propose par défaut deux manières de lancer chaque application (le serveur, et chaque client). S’il n’existe côté client, qu’une seule application (reposant sur SWT par exemple), cela fait tout de même 4 lanceurs différents:

Eclipse Scout - product launchers

Ce mécanisme repose sur les fichiers *.product et n’est pas si difficile à comprendre.

Lire la suite

Eclipse Scout, fait pour les applications d’entreprises ?

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.

Mcqs - une application Eclipse Scout

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.

Lire la suite

Un fragment NoDB pour le serveur de mon application Eclipse Scout

Les applications Eclipse Scout reposent sur un registre de service. Ces services sont définis par une interface, placé dans le plug-in shared accessible côté client comme côté serveur. L’appel à l’un de ces services s’effectue toujours de la même manière:

IQuestionsListProcessService service = SERVICES.getService(IQuestionsListProcessService.class);

Côté client, deux cas se présentent:
* une implémentation est disponible côté client. Dans ce cas elle est retournée par cet appel.
* l’implémentation se trouve côté serveur. Dans ce cas, un proxy est retourné, et l’appel à la fonction est transmis au serveur par Eclipse Scout.

Ce registre de services gère plusieurs implémentations pour une même interface. Il est possible de définir une priorité pour donner un ordre entre les implémentations.

D’où mon idée de septembre dernier de proposer pour chaque service une implémentation se passant de la base de données. Dans ce cas il n’y a plus de persistance des informations, mais dans le cas de démonstration ou de tests cela peut être suffisant.

Je l’ai mis en oeuvre pour mon application MCQS.

Depuis ce commit, je dispose maintenant d’un fragment org.eclipselabs.mcqs.server.nodb.frament qui propose une implémentation des services avec une priorité plus haute. Lorsque le fragment est chargé avec le serveur (ce qui est le cas avec le produit server/products/nodb), ce sont ses implémentations qui ont la priorité.

Ce n’est pas encore tout à fait parfait, car pour faire les choses proprement il ne faudrait pas avoir de dépendance à la base de données dans le plug-in serveur principal, mais dans un deuxième fragment (et utiliser l’un ou l’autre).

Mon fragment NoDB est rudimentaire. Il ne garde rien en mémoire, ce qui devrait être possible.

Dans tous les cas, c’est un bon cas d’exemple de l’annotation @Priority que l’on peut ajouter sur chacun des services.

Personnaliser son application Eclipse Scout

Donner une apparence finie à son application est une étape importante. Certains petits détails témoignent du soin apporté à l’application (ou de son bâclage dans le cas contraire).

Splash screen - Eclipse Scout

Par défaut, une application Eclipse Scout contient un certain nombre d’images qui sont des «place-holders» pour l’application finale. Il s’agit de tous les remplacer pour avoir une application à l’apparence correcte.

Splash screen - Mcqs

Lire la suite

Apprendre Eclipse EMF

Une nouvelle année, c’est l’occasion de prendre des résolutions… Mon objectif «développeur» pour cette année: apprendre à me servir d’Eclipse EMF.

EMF signifie Eclipse Modeling Framework. Ce n’est pas vraiment une nouvelle technologie, car le concept existe depuis de nombreuses années. Il s’agit d’un ensemble de projets autour du MDA (Model driven architecture), soit en français « architecture pilotée par la modélisation ».

Logo Eclipse EMF

Il me semble que la difficulté vient du fait qu’il existe de très nombreux projets différents. Cela a été synthétisé en distinguant un certain nombre de catégories (modélisation, gestion de modèles, génération de code, …), dans lequel on trouve un certain nombre de projets. Certains proposent une approche différente aux mêmes problèmes, ce qui ne facilite pas la compréhension. Heureusement tout semble compatible, il suffit de trouver la bonne porte d’entrée pour réaliser ce que l’on veut faire.

Lire la suite

config.ini et setter dans Eclipse Scout

Les applications Eclipse Scout sont opérationnelles dès leur création à l’aide du template initial, mais pour bien comprendre leur fonctionnement, il y a pas mal de petits détails.

Je voulais obtenir un code indépendant de la configuration de la base de données, c’est-à-dire utiliser le fichier config.ini (qui doit de toute façon être mis à jour leur d’un changement d’environnement).
Lire la suite

Quelques points pour mieux comprendre Eclipse Scout

Plusieurs signes me font penser qu’il n’est pas simple de définir ce qu’est Eclipse Scout. Lors du premier Stammtisch Eclipse à Zurich (qui était plutôt un DemoCamp, mais passons), la présentation donnée n’a pas forcément réussi à expliquer ce qu’était Eclipse Scout… Le forum d’Eclipse Scout commence à être animé avec des questions de personnes qui souhaitent en savoir plus.

La définition que l’on trouve est la suivante:
« Eclipse Scout est un framework moderne et ouvert qui permet de réaliser facilement des applications métiers orientés services« . Mais qu’y a t’il dernière cette définition?

Logo Eclipse Scout
Lire la suite