[Article] Premiers pas avec Eclipse Scout

[jmini]

Je vous propose une présentation détaillée du framework Eclipse Scout : Premiers pas avec Eclipse Scout

Le chapitre II illustre la réalisation complète d'une application à travers un exemple.

Le code source de l'exemple est disponible en téléchargement (sur Eclipse-Labs)

Je vous invite à profiter de cette discussion pour des commentaires éventuels.

[azerr]

Bonjour jmini,

Merci beaucoup pour cet article qui m'a donné une idée de Eclipse Scout que je voulais étudier aussi!

Je vois mieux maintenant ce que propose Eclipse Scout, mais je me pose encore plusieurs questions sur le fait de l'adopter. En effet nous avons une application Eclipse RCP/RAP http://xdocreport-rap.opensagres.clo...ui.application basée sur Eclipse Gemini Blueprint (Spring DM), Spring Data-JPA et bientôt avec DOSGi (CXF pour gérer le remoting) et je me pose la question si Eclipse Scout pourrait nous intéresser.

Voici mes questions :

• Quelle est la différence entre Eclipse Scout et Eclipse Riena? Aujourd'hui il y a ces 2 frameworks et du coup je suis un peu perdu.
• Pour la partie remoting, qu'est-ce qu'utilise Eclipse Scout comme mode de remoting (RMI, HTTP, REST, WebService etc) ?
• Peut-on utiliser Spring DM avec Eclipse Scout ? Je suis fan de Spring et Spring DM et je préfère exposer mes services via des beans Spring. Est-ce possible avec Eclipse Scout ?
• Dans la même lignée je suis fan de Spring Data JPA (pas besoin de coder une ligne de code pour sa requête JPA pour du CRUD!). Dans l'exemple donné c'est du SQL, peut-on simplement intégrer Spring Data JPA?
• Compatibilité avec Eclipse E4 ? Nous souhaiterons (dès que RAP supportera Eclipse E4) migrer notre application vers Eclipse E4. Eclipse Scout supporte-t-il Eclipse E4?

Merci de tes réponses.

Bonne journée

Angelo

[jmini]

Bonjour,

Merci pour tes questions. Je ne suis pas forcément le mieux placé pour te répondre, car je ne connais pas bien les frameworks mentionnés. Il m’arrive de travailler avec Eclipse Scout, d’où mon article.

Tu trouveras de meilleures réponses sur le forum officiel (en anglais), où les commiteurs du projet répondent.

Néamoins quelques éléments:

* Eclipse Scout vs Eclipse Riena:

Les deux frameworks visent la même chose, mais ont une approche très différente. À tel point qu’il n’y a pas eu de mutualisation possible avec Riena quand Eclipse Scout a été lancé.

Voir aussi: Scout vs Riena platform


* Eclipse Scout et E4:

C’est sur la roadmap de Eclipse Scout... Cependant ce n’est pas simple de le faire de la bonne manière: Eclipse Scout dispose de sa propre modélisation des composants de l’interface utilisateur (formulaire, champs, ...) et de son mécanisme pour proposer une interface utilisateur rendue avec différente bibliothèque (Swing, SWT, Rap...)

Mon avis sur cette question: il faudrait réécrire cette partie d’Eclipse Scout avec les mécanismes de E4.

Voir le travail de Kai toedter: JavaFX 2.0, Swing & SWT Renderers for the Eclipse 4.x Application Platform


* Remoting:

La communication Client/Serveur est gérée par Eclipse Scout, mais à travers un service Tunneling qu’il est possible de modifier (repose sur java dynamic proxy et la sérialisation java).

Le service de Tunneling par défaut repose sur HTTP et SOAP (mais les objets java sont sérialisé dans un champ du message. Ce service n’est pas fait pour être consommé par d’autres applications. Pour exposer des services vers d’autres applications, il est recommandé d’utiliser autre chose au niveau du serveur comme Jax-Ws pour lequel un support est offert).

Une description détaillée: Remote Service Call / ServiceTunnel
Des questions sur ce sujet: Why is there a Web Server / Web Container?


* Couplage avec Spring:

C’est envisageable (je sais qu’un client vient de se poser la question). Il faut cependant bien réfléchir à ce qui a du sens et qui fait doublon.

Par rapport à cette approche, c’est à mon avis une faiblesse actuelle d’Eclipse Scout: c’est plutôt pensé pensé pour être utilisé en un bloc, ce qui ne s’applique pas à tous les cas. Il y a surement des synergies à trouver.

Eclipse Scout a des forces, mais aussi des faiblesses (dont certaines peuvent être améliorées et d’autres ne font pas partie du focus).


N’hésite pas si tu souhaites que j’approfondisse sur un des points (je peux transmettre ta question en interne aux équipes pour publier les réponses ici).

.

[azerr]

Bonjour jmini,

Merci d'avoir pris le temps de répondre à mes questions. Je t'avoues que de partir sur Eclipse Scout me fait un peu peur car j'aimerais conserver notre architecture Spring DM/Spring JPA Data/DOSGi et des que RAP le supportera Eclipse E4.

Ce qui me chagrine un peu c'est que Eclipse Scout (comme Riena) a son propre toolkit de UI et même si il y a un SDK, j'aime les choses standards SWT ou on peut utiliser le designer SWT WindowsBuilder de Google.

Il faudra que j'étudie Eclipse Scout quand même pour voir si cela nous apportera quelque chose.

Merci!

Angelo

[jmini]

Envoyé par azerr

Ce qui me chagrine un peu c'est que Eclipse Scout (comme Riena) a son propre toolkit de UI et même si il y a un SDK, j'aime les choses standards SWT ou on peut utiliser le designer SWT WindowsBuilder de Google.

C'est exactement un des choix qui fait que Eclipse Scout ne correspond pas à tous les projets... Dans ma boite certains projets sont fait avec Eclipse Scout et d'autres non.

Evidemment il est possible d'étendre la toolkit Eclipse Scout pour des besoins spécifiques, mais cela ne remplace pas le fait de coder direct en SWT.

Concernant WindowsBuilder, c'est un bon outil. Nous avons réalisé un prototype pour voir comment cela pourrait être utiliser avec Eclipse Scout.

Là où je m'interroge avec E4, c'est qu'il est aussi recommander de séparer sa logique (Modèle et Interface Graphique). C'est de cette manière que e(fx)clipse est réalisé (Le code utilisé est celui de Eclipse 4 Application, y compris Application.e4xmi, avec un JavaFX-Renderer au lieu de SWT).
Du coup je ne sais pas comment WindowsBuilder est compatible avec ce genre d'approche.

De mon point de vue, Eclipse Scout doit aller dans cette direction et être 100% compatible avec cette approche (une sorte d'extension, en ajoutant ce qu'il manque), plutôt que de faire les choses à sa manière (ce qui n'est jamais une bonne idée)...