Scout
Présentation générale
La partie SDK
Une partie SDK est livrée lorsqu'on installe Scout. C'est une source de code claire et lisible. Du fait que la licence soit EPL, on peut modifier ce SDK suivant nos envies.
Le principal atout d'utiliser un SDK, quel qu'il soit, est que le développeur n'a plus besoins de se demander comment il fonctionne et ce qu'il utiliser pour fonctionner. Le développeur peut alors entièrement se concentrer sur les données qu'il doit gérer. Cette partie SDK est vraiment visible et appréciable grâce à eclipse qui met à disposition des vues et des assistants :
On constate bien la séparation en 3 parties. A gauche, on retrouve l'arborescence de notre projet, au centre, la zone nous permettant de définir les propriétés à appliquer et à droite, l'ensemble du code généré par nos action ou que l'on à écrit.
Les applications Eclipse Scout sont pensées pour être fonctionnelles dès leur création à partir d'un template. Lors des phases de prototypage ou de création d'application, cela permet d'accélérer le développement et de pouvoir présenter les modifications rapidement.
La partie Runtime
Le runtime est intégré à chaque application réalisée (partie client ou partie serveur). Il utilise les technologies de la plateforme Eclipse pour créer des applications finies et faire communiquer entre elles de manière transparente la partie client et la partie serveur. Ainsi le développeur se concentre sur l'essentiel : côté client la définition des éléments de l'application vue par l'utilisateur (fenêtres, menus, formulaires…), et côté serveur la gestion des données (celles à saisir ou à afficher).
Eclipse Scout propose une stratégie multifront-end. Plusieurs bibliothèques graphiques sont supportées (Swing, SWT, Web avec RAP…). Pour arriver à ce but, seul un modèle du client doit être défini (en Java). Le framework se charge de créer et gérer le rendu de l'interface utilisateur. Ainsi le développeur ne programme pas le détail du rendu, mais se concentre sur la manière dont les données vont être affichées (les interactions et la logique métier), évitant le travail de gestion fine de la bibliothèque graphique.
Pour résumer, la partie runtime s'appuie sur la plateforme Eclipse et simplifie sa mise en œuvre. Cette simplification passe par un certain nombre de choix qui pourraient être limitant pour des besoins spécifiques, mais le framework est suffisamment ouvert pour ajouter les éléments manquants.
Architecture client / Serveur
La partie serveur est hébergée sur un serveur d'application Java (Tomcat, Jboss). Elle met à disposition du client un certain nombre de services pour afficher et manipuler les données. L'idée est de s'interconnecter à d'autres services JEE et/ou à une base de données (JDBC). Les services sont définis par des interfaces Java et exposés via OSGi. C'est un système de Service Registery disposant d'un mécanisme de priorité. Les Services peuvent être appelés depuis le client ou le serveur, Eclipse Scout se chargeant de transmettre les données de l'un à l'autre si nécessaire.
La partie client est celle que l'utilisateur final voit. Comme dans toute application, on retrouve les éléments traditionnels : fenêtres, menus, formulaires… Pour la navigation dans les données, Eclipse Scout propose un principe d'arborescence de pages couplé à des formulaires de recherche. D'autres formulaires offrent la possibilité d'éditer les données. En fonction du type d'application, on pourra ouvrir ces formulaires dans des fenêtres modales, ou les présenter successivement (à la manière d'un assistant) pour travailler par processus.
Application réalisé avec Scout
Aujourd'hui plusieurs projets sont développés avec Scout. Ce n'est pas le plugin eclipse le plus rependu cependant on peut constater que l'interface de ces applications peuvent être simple, comme élaboré.
Exemple d'une application simple en vue desktop :
Exemple d'une application plus complexe en vue navigateur :
Nous allons pouvoir continuer sur la méthode utiliser pour construire une application.