C’est une possibilité de plus qui confirme la stratégie multi front-end d’Eclipse Scout. En effet la même application peut-être rendue sous différente forme : application desktop, application web et maintenant application web mobile.

Depuis toujours, une idée principale d’Eclipse Scout consiste en une surcouche pour définir l’application qui soit indépendante de toute librairie graphique (SWT ou Swing). Les formulaires ainsi que les champs qu’ils contiennent sont définis dans un modèle d’application qui sera rendu sous forme d’interface graphique à l’exécution. Cette technique permet d’obtenir plusieurs déclinaisons de la même application :

Version SWT :

Version Swing :

Version web :

Le mobile étant une plateforme différente, il a fallu ajouter une étape supplémentaire lors du rendu. Les composants sont adaptés pour tenir compte des spécifiés de la plateforme. Voici quelques exemples :

Smartfield :

Le smartfield est un champ assez puissant : à la manière d’un combo-box, il permet de choisir parmi plusieurs choix. Il est également possible de saisir du texte dans le champ pour réduire les choix proposés. En version mobile, pour reproduire toutes ces possibilités, il a fallu ajouter une vue annexe sur la droite.

Absence de menu contextuel :

L’action proposée dans le menu contextuel apparait sous forme de bouton sous la table.

Représentation des tableaux :

La largeur offerte par le téléphone est limitée. La hauteur des lignes d’un tableau doit être suffisante pour permettre une sélection avec le doigt « sélection touch ». Du coup, les colonnes d’un tableau sont rassemblées sous forme de lignes dans une cellule plus haute. Les colonnes d’une ligne du tableau vont être représentées dans un formulaire annexe accessible en sélectionnant une cellule dans la liste mobile.

L’action principale du menu contextuel (celle qui aurait été proposée en double cliquant sur la ligne du tableau) et qui correspond souvent à l’opération d’édition se retrouve déportée en haut à droite. Les opérations restantes sont disponibles dans un menu supplémentaire.

Masquer certaines fonctionnalités :

Toutes les fonctionnalités ne font pas forcément sens sur mobile. Pour mon application, j’ai décidé de masquer la représentation sous forme graphique (déjà rudimentaire dans la version desktop) en supprimant l’onglet correspondant.

En conclusion

Cette transformation du modèle applicatif permet d’adapter le rendu web aux spécificités du mobile. Évidement l’application obtenue n’est pas aussi efficace qu’un développement dédié, mais le résultat est plus que convainquant par rapport au temps investi.

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.

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
Affiché lors du chargement de l’application, il permet à l’utilisateur de savoir qu’il doit patienter et qu’il se passe quelque chose.

Il suffit d’ajouter un fichier splash.xxx à la racine du plug-in de lancement (Swing ou SWT en fonction du moteur de rendu choisi. Pour SWT sans changer les réglages par défaut de l’application RPC, il faudra utiliser un fichier bmp). Ne pas oublier de l’inclure dans le ficher build.properties (dans la catégorie binary build).

Logo
Ce logo (grand) est notamment affiché dans la fenêtre «à propos de cette application».

Voir ce tutoriel.

Icône
L’icône est également un élément important.

Voir ce sujet de forum.

Page de téléchargement sur le serveur
Lorsque l’on se connecte en HTTP sur le serveur où est déployée l’application, on obtient une page de téléchargement. Il est important de personnaliser cette page.

La page en question se trouve dans le plug-in de l’application server sous /resources/html.

Je n’ai pas fait beaucoup de modifications sur cette page, mais mon idée est de toute façon de proposer un installateur (voir ci après). J’ai donc laissé le texte en anglais et la description correspondant à une application windows.

Installation
La prochaine étape va consister à se préoccuper de l’installation d’un produit fini. Il doit être possible:
* d’installer ou de choisir une base de données Derby.
* de configurer l’adresse à laquelle les clients devront se connecter.
…

Encore un peu de travail en perspective…

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

Fidèle à sa logique, Eclipse Scout propose d’étendre la classe AbstractSqlService pour définir la configuration d’accès à la base de données.

Il existe une propriété privée m_jdbcMappingName qui est accessible par des getters et des setters publics. Dans la classe fille, il est d’usage d’indiquer une constante dans la fonction getConfigured*() correspondante (getConfiguredJdbcMappingName() dans ce cas). C’est ce que la perspective Eclipse fait si l’on utilise la «Scout Properties View».

Le code correspondant:

À l’initialisation, cette valeur va être lue et devenir la valeur courante (accessible ensuite par le getter traditionnel).

Pourtant il existe une autre manière d’initialiser cette valeur. Il est possible d’utiliser dans le fichier config.ini une ligne respectant ce pattern:

<Qualified Name>#<Setter name without set prefix>=<value>

Ainsi dans notre cas:
org.eclipselabs.mcqs.server.services.common.sql.McqDerbySqlService#JdbcMappingName=jdbc:derby:/Users/jebr/code/mcq/mcq_db.derby

C’est magique…

Malheureusement sur mon Mac, il me manquait je ne sais trop quoi (visiblement une bibliothèque Perl qui n’est pas installée, ou pas au bon endroit). Je ne suis pas un grand fan de toutes ces installations, j’aime les choses qui marchent en un clic (je crois que c’est pour cela que j’ai un Mac). Je me demandais ce que j’allais faire, et j’ai eu l’idée de ressortir un ordi sous Ubuntu…

J’ai alors ressorti un petit Notebook (un Eee Pc) sur lequel tourne un Ubuntu 10.04 (Netbook Edition).

Je ne l’avais plus utilisé depuis plusieurs mois, mais tout fonctionne toujours aussi bien. Git était déjà installé, mais il manquait git-svn… Un petit tour du côté du Gestionnaire de paquets Synaptic, un clic dans la case git-svn et c’est tout…

Pour moi qui ne suis pas un expert, c’est vraiment d’une simplicité bluffante. J’imagine que tout se télécharge, s’installe et se met à jour au bon endroit.

Il me semble que c’est vraiment un avantage des distributions Linux sur les autres systèmes d’exploitation.

C’est un cas un petit peu particulier: je voulais pouvoir utiliser (pour des tests, pour des démonstrations) mon application sans sa base de données. Il ne s’agit pas d’une version hors ligne, car il n’y a pas de sauvegarde des modifications, ni de synchronisation par la suite.

Comment cela marche ?

C’est assez simple: j’ai implémenté une deuxième version de mon OutlineService pour le catalogue (DBMockOutlineService classe qui implémente ICatalogOutlineService). Le service est déclaré dans mon fichier plugin.xml

Pour donner la priorité à mon service (version DBMock) il suffit d’ajouter l’annotation @Priority avec une valeur supérieure aux autres implémentations du service.

Il s’agit enfin d’ajouter quelques valeurs fixes dans les fonctions qui alimentent les tables pages de l’outline catalogue.

Il me reste encore un petit peu de travail: ajouter ces services dans un plug-in séparé. De cette manière, je pourrais me créer un lanceur avec ces services. Cela me permettra de fonctionner sans la base de données.

PS: J’ai passé une partie de l’été à rédiger un article de référence sur Eclipse Scout en Français… Plus de nouvelles très bientôt.

MySQL fournit un fichier sakila.mwb qui permet grâce à MySQL Workbench, de visualiser la base de données. Pour le moment les tables de movie database sont couvertes (il manque les tables `inventory` et `film_text`, et il n’est pas possible de modifier la table `language`)

Cette partie de la base représente trois entités : les films, les catégories et les acteurs. Les films sont les plus importants et les plus nombreux. Ils une relation N:M avec les catégories (via la table `film_category`) et avec les acteurs (via la table `film_actor`). D’ou l’idée de proposer un accès aux films de différentes manière : soit directement à l’aide d’une recherche, soit en commençant par sélectionner une catégorie ou un acteur.

Dans la fenêtre principale (proposée en standard par Eclipse Scout) on trouve :

• Sur la gauche se trouve une arborescence de dossiers permettant plusieurs type d’accès (directe, par catégorie, par acteur).
• Le contenu des dossiers au centre (films, catégories ou acteurs). Lorsque le contenu est important une recherche doit être effectuée.
• En bas, un formulaire pour effectuer ces recherches.

Techniquement, cette fenêtre principale utilise les concepts de d’Eclipse Scout. Cette vue est définie dans un Outline (CatalogOutline). L’arborescence de dossiers est constituée de pages (on trouve une TablePage par entités : FilmsTablePage, CategoriesTablePage, ActorsTablePage). Les données sont chargées via un OutlineService (CatalogOutlineService)

Pour chaque dossier des fonctions d’ajout, d’édition et de suppression du contenu sont proposées à travers des menus. L’édition et l’ajout des différentes entités est réalisée à travers différents formulaires qui sont ouvert dans des fenêtres modales. La base de données impose que certaines valeurs ne reste pas nulle (propriété NOT NULL). Dans Eclipse Scout, les champs correspondant apparaissent en gras et le formulaire ne peut être être fermé tant que les champs sont vides.

Techniquement les menus (Classe filles de AbstractMenu) sont défini dans les différentes tables concernées. Pour chaque entités un Form est défini (FilmForm, CategoryForm, ActorForm).

La base de donnée (surtout sa structure) définie précisément les caractéristiques de certains champs. On trouve certains type particuliers (texte, nombre, date). On trouve aussi des choix limités: définit par les sets (par exemple `film`.`special_features`) ou par les enums (par exemple `film`.`rating`). Et aussi des références vers d’autres table (comme la langue du film qui référence la table `language`). Eclipse Scout propose différents type de champs pour permettre une saisie simple et efficace (DateField, SmartField…). Les options pour les champs `rating` et `special_features` sont défini dans des CodeType (RatingCodeType, SpecialFeatureCodeType). Pour le choix de la langue, la table language est disponible à travers un LookupCall et un LookupService (LanguageLookupCall and LanguageLookupService).

La suite au prochain épisode…

Disclaimer :
Je travaille pour BSI Business System Integration AG, la société créatrice du framework Eclipse Scout. Les propos tenus ici n’engagent que moi. Cet article a été écrit en dehors de mon temps de travail et n’a pas été relu par mon employeur.

J’ai retenu la base de données Sakila, proposé par MySql en démonstration des fonctionnalités de MySQL 5. A vrai dire je n’ai pas fait de grosse étude de marché pour faire mon choix. J’ai découvert cette base en m’intéressant à MySQL. Elle est suffisamment complète pour qu’il y ait un intérêt (22 tables, clé primaire et clé externes, vues, trigger, procédures…). La lecture de cette analyse des manques de MySQL, me fait penser que MySQL n’est pas forcément un bon choix pour ce genre d’application, mais cette base existe aussi pour PosgreSQL (pagila) et je privilégie la simplicité d’utiliser un outil que je connais.

Cette base de données sert à gérer l’activité d’un loueur de DVD (gestion d’un catalogue de films, de différents magasins avec leurs équipes et leur clients, ainsi que l’activité au quotidien).

Ce sera donc le projet et l’application SakilApp. L’idée est de pouvoir visualiser et éditer toutes les informations contenues dans la base de données, en suivant la manière du framework. Je souhaiterais illustrer et commenter mes choix, tout en aboutissant à un produit fini.

Mon premier objectif est que toutes les informations de la base de données soient accessibles et éditables dans l’application. Il y a cependant du potentiel pour des développements après cette première version. Par exemple optimiser l’interface graphique pour une utilisation dans une boutique de location de film, ou encore intégrer dans l’application des fonctionnalités de reporting.

Je souhaite également proposer un accès au code source. J’ai donc ouvert un projet sur google code contenant les projets de mon workspace Eclipse. Lorsque le projet sera plus avancé, j’espère également pouvoir mettre à disposition l’application sous sa forme compilée.

Le code est sous licence Apache 2, pour que chacun puisse y avoir accès. Je n’en suis vraiment qu’au début du développement, et ne conserve pas forcément le code correspondant aux articles. Il s’agit surtout pour moi de faire des expériences et des essais, tout en illustrant les articles que je publie.

Disclaimer :
Je travaille pour BSI Business System Integration AG, la société créatrice du framework Eclipse Scout. Les propos tenus ici n’engagent que moi. Cet article a été écris en dehors de mon temps de travail et n’a pas été relu par mon employeur.

Eclipse Scout est un framework qui permet de créer rapidement des applications (plutôt de type client / serveur). L’idée est de simplifier au maximum la barrière d’entrée pour créer des applications sur la plateforme Eclipse.

Un tel objectif ne va pas sans faire des choix et introduire de nombreux concepts. Certains peuvent parfois sembler limitant (mais devraient couvrir la majorité des besoins), d’autres sont assez puissants (comme le choix de la librairie de rendu : SWT, Swing, web…). Quoi qu’il en soit, il manque pour le moment un certain nombre de publications et d’exemples pour mettre Eclipse Scout à la porté de tous ceux qui veulent s’y intéresser.

Je pense que ce framework peut correspondre à certains besoins… Mon idée est de partager sur ce blog ma découverte et d’en présenter suffisamment pour donner à d’autre l’envie de partir à la découverte. Mon intuition est qu’il faut donner des exemples et les expliquer. J’ai envie de repartir de zero et de voir comment le framework permet de construire une application qui exploiterait une base de données existante.

Au delà du code et des exemples, Eclipse Scout c’est aussi beaucoup d’autre chose : rendre open-source un projet pré-existant dans une entreprise, travailler avec la fondation Eclipse, esssayer de bâtir une communauté. J’espère avoir aussi le temps de parler de tout cela sur ce blog.

Disclaimer :
Je travaille pour BSI Business System Integration AG, la société créatrice du framework Eclipse Scout. Les propos tenus ici n’engagent que moi. Cet article a été écrit en dehors de mon temps de travail et n’a pas été relu par mon employeur.