Discussion :

[doons]

Bonjour,

Je vois souvent les mentions suivantes : RCP, RAP

Si j'ai bien compris, RCP est utilisé lorsque l'on veut développer une application de bureau et RAP pour une application web.
Mais du coup, quelle est la différence entre une application RCP et une application Desktop comme n'importe quelle applic que l'ont peut installer sur son poste.

Je suis un peu perdu avec ces notions-là.

Merci d'avance pour vos explications

[joel.drigo]

Salut,

Eclipse RCP (Rich Client Platform) est un framework (un ensemble modulaire d'API de développement d'applications) qui permet de créer des applications Desktop dites "riche", c'est-à-dire avec une interface utilisateur sophistiquée en quelque sorte, qu'on peut mettre en parallèle à une application Web moderne, dite RIA (Rich Internet Application), aussi appelée "client léger", ou encore à une application RDA (Rich Desktop Application), qui est une application développée avec des technologies Web, mais qui s'exécute dans un container (une application s'exécutant localement) autre qu'un navigateur web classique (on peut d'ailleurs faire une application RCP qui sert de conteneur à une application RDA.

On oppose une application dite Desktop (qui nécessite une installation locale, et dont l'exécution du code se fait localement) à une application Web, ou la majeur partie du code est exécutée côté serveur, et le code s'exécutant côté client est surtout du code d'UI, de vérification de saisie... qui s'exécutera dans un navigateur Web.

La technologie RAP (Remote Application Platform) permet d'éxécuter une application RCP dans un navigateur Web : c'est en quelque sorte l'inverse d'une RDA.

NB: une application Desktop ne signifie pas forcément que tout le code s'exécute localement, côté client, puisqu'une application Desktop, comme une application RCP en particulier, peut se connecter à un serveur d'application, un CMS, des services web, une base de données avec procédures stockées, etc...
D'ailleurs, on peut mélanger un peu tout ça : l'application sur laquelle je travaille actuellement repose sur Eclipse RCP, se connecte à un CMS qui fournit des services, et dont certaines vues sont des vues Web (avec encapsulation d'un navigateur web, se connectant à une URL servie par le CMS).

[doons]

Hello,

Merci beaucoup pour ces explications.

Donc si par exemple, je veux créer une application en me basant sur Eclipse RAP (la demo sur le site me plait beaucoup), je devrais dans un premier temps développer une application basée sur RCP puis utiliser la technologie RAP pour rendre mon application exécutable via un navigateur web ?

Et pour faire mon appli RCP, je dois développer comme je le ferais pour une application de bureau standard (en tenant compte des contraintes et autres liées à la techno RCP) ?

Encore merci

[joel.drigo]

En fait, c'est le même lien de téléchargement : Eclipse for RCP and RAP Developers.

Ensuite, en théorie, c'est le même code, que tu peux exécuter soit en RCP, soit en RAP (en fait, il faut créer un Product, que tu peux lancer soit en RCP, soit en RAP). Je dis en théorie, parce que déjà tout n'est pas exactement identique : je ne sais pas trop où ça en est aujourd'hui et ça probablement beaucoup évolué depuis que j'ai testé personnellement, mais il y avait quelques petites différences de rendu entre le RCP et le WEB. Il y a également quelques lacunes dans l'API, qui peuvent être gênantes si on sort un peu des GUI standard (genre liste + formulaire) et qu'il faudra contourner par des méthodes plus ou moins fastidieuse (je pense par exemple au fait qu'on ne puisse pas définir de clipping sur un contexte graphique, ou qu'on ne puisse pas dessiner ses propres images. On voit bien ces problèmes quand on compare les API SWT et RWT : SWT c'est la base de tout ce qui est graphique (un peu l'équivalent de SWT plus une partie de SWING, qui est complété par JFace). RWT c'est exactement la même API (les mêmes packages, les même noms de classes, pour l'exécution en mode WEB). Si tu compares les JavaDoc, tu verras les méthodes qui existent en SWT, mais qui n'existe pas encore en RWT.

Bon, ensuite, il y a forcément une différence au niveau déploiement, puisque l'application RAP est exécuté en web, donc derrière un serveur : à ce sujet, je n'ai jamais trop regardé comment cela fonctionnait.

[doons]

D'accord, c'est plus clair pour moi maintenant.

Et dernière petite question, plutôt sur ton opinion et expérience.

Si tu devais faire une sorte de mini-erp pour une entreprise, tu t'y prendrais comment ?
Plutôt appli web standard, rap, rcp, ... t'as une idée de quel système de bdd pourrait bien aller ?

C'est ce que je dois faire et je voudrais pas trop me planter dans mes choix ....

Merci & bon weekend

[joel.drigo]

C'est une question plutôt vaste pour laquelle je pourrais remplir des pages et des pages du forum Ça dépend de beaucoup de choses (temps disponible, budget, environnement (réseau, multi-site ou pas, compétence et disponibilité du service d'exploitation, etc...) et caractéristiques (comme la fréquence de livraison, la facilité d'accès aux postes, ou à un serveur d'update, le nombre de postes, etc...) de déploiement , les volumes de données, scalabilité nécessaire, dynamique de l'ergonomie de l'application, désirs des utilisateurs et des demandeurs (il y a certains DSI clients qui exigent du RCP, d'autres qui ne veulent pas en entendre parler et veulent que tout s'exécute dans ie6, d'autres qui s'en moquent), etc...). L'avantage de RCP/RAP est qu'on peut passer d'un monde à l'autre assez facilement (excepté les limitations dont je parlais, que tu peux consulter en détail ici). Pour l'environnement de développement, justement mon expérience se limitant à développer des clients RCP, je me contente de faire avec ce qu'on me donne comme SGBD/CMS/Serveur d'application/Environnement technique réseau/serveur : mon application étant multi-environnement enfin de compte. Je n'ai donc que peu de conseils à te donner sur le choix d'un SGBD ou d'un autre.

[doons]

ok, je comprends bien que le question n'est pas évidente.

En tout les cas, merci beaucoup pour tes réponses.
Bonne journée