Question

Je suis sur un projet où nous essayons de construire pour remplacer une ancienne application GUI. Avant vraiment mettre en œuvre les fonctionnalités que nous avons commencé le prototypage avec Eclipse RCP (Rich Client Platform) et GWT (boîte à outils Google widget, une Rich Internet Application). Quelle est votre expérience avec RIA et RCP GUIs? Quand est-il judicieux d'utiliser RIA et dans quelles situations un client riche est plus approprié? Avec les possibilités actuelles de RIA, il devient de plus en plus difficile de tracer la ligne .. Avez-vous des expériences?

EDIT: Toutes vos réponses sont vraiment intéressantes. Je voudrais accepter tous car ils contribuent à la réponse de mon, je l'avoue une question tout à fait ouverte. Donc, mon vote pour chacun d'entre eux. Espérons que la prime sera partagé entre vous.

Était-ce utile?

La solution

Il n'y a pas aucun détail sur les exigences de votre application qui est vraiment clé pour répondre à la question.

La grande victoire pour l'utilisation de GWT est la facilité de déploiement par rapport à quelque chose comme RCP. Il n'y a rien de plus facile pour l'utilisateur que de pointer leur navigateur Web à une URL et rien de plus facile pour l'équipe des opérations que le code poussant sur le serveur, en faisant rebondir et l'appeler un jour.

En ce qui concerne la fonctionnalité, la grande région où GWT en paient le prix serait visualisations de données riches: Représentation graphique, arbre / nœud, diagrammes de réseau, etc. Ce genre de choses est possible avec GWT et un peu d'aide sur le serveur, mais les limites de DHTML commencent à montrer à travers, même avec une boîte à outils puissante comme GWT. D'autre part, RCP vous donne toute la puissance de Java 2D pour visualiser tout ce que vous voulez. Ces types de fonctions peuvent ne pas être nécessaire pour vous, mais ils sont aussi ceux qui rendent les applications vraiment intéressant, plus qu'un simple gâchis de tabulation, des arbres et des contrôles grille de données.

J'ai développé avec Adobe Flex depuis plusieurs années maintenant et je trouve qu'il est vraiment puissant, ayant plus ou moins les mêmes avantages de déploiement que quelque chose comme GWT, mais offrant le même genre de puissance RCP. Vous pouvez vérifier que trop.

Autres conseils

Même si GWT va un long chemin, il ne donne la même souplesse et de l'accessibilité comme une bonne application.

Même thouhg une application GWT peut presque tout faire une application réelle peut, un certain nombre de facteurs indique que RCP serait le meilleur outil.

  • travail répété
  • Beaucoup d'entrée
  • sessions longues
  • tâches répétées
  • widgets personnalisés pour l'édition ou de la présentation.
  • Plusieurs fenêtres avec des données différentes.
  • Touches d'accès rapide pour les opérations souvent utilisées
  • Réponses rapides.
  • Une barre de menu réel, coolbars.
  • Une fenêtre appropriée qui il est facile de trouver dans la barre des tâches.
  • Les menus contextuels pour les opérations rarement utilisées
  • Limited (ou une base connue de) nombre d'utilisateurs.
  • animations longues ou complexes ou des mises à jour en temps réel.

Si vous pensez que votre application a besoin d'un plan de travail, avec plusieurs vues et les éditeurs, le choix est donné.

RCP et le plan de travail ne sont pas faciles à travailler avec, mais vous obtenez beaucoup gratuitement si l'application bénéficierait de plus « libre » et le modèle de travail ouvert avec plusieurs vues ouvertes / éditeurs, etc.

Si l'application est pour des tâches plus ponctuelles, alors GWT est vraiment bon.

GWT est vraiment sympa, , mais il est encore une application web, et qui aspire parfois. Je ne voudrais pas faire tout mon travail dans une application Web où je peux appuyer accidentellement sur une touche et perdre tout mon travail et la session. (Mon clavier a même une touche à côté des touches fléchées qui semble être impossible de désactiver). Son assez puissant ne le font presque tout ce que vous pouvez faire en RCP, mais son fonctionnement reste dans le navigateur web, et qui peut être irritant.

Rappelez-vous que vous pouvez utiliser java Webstart pour déployer des applications RCP.

Nous avons développé un (projet pilote) plug-in pour Eclipse qui a ensuite été converti à la fois une application autonome RCP (nous ne voulions pas l'expédier en tant que plug-in car nous ne voulions pas Eclipse en tant que pré req, donc nous avons dû ajouter un code soutenant le rendant un peu plus compliqué qu'un simple mouvement simple dans RCP) et dans une application AIR en utilisant jQuery.

Malgré les efforts du camp de RCP, la version RIA a pris environ en même temps de développer (même si elle était de zéro) et il avait l'air plus fluide dans l'exécution.

Le pneu était qu'il n'y avait pas besoin de la installation a la version RIA puisque tous nos clients ont déjà des serveurs d'applications et des mises à jour sont centralisées sur un serveur, et non chaque client.

La version RCP a depuis longtemps été laissé dans la fonctionnalité. En ce qui nous concerne, Eclipse est bien comme environnement de développement (pour Java, nous avons aucune expérience avec les autres langues), mais l'effort qu'ils ont mis dans Éclatement l'IDE de l'interface graphique (pour rendre RCP possible) n'est pas < em> tout à fait fini.

D'autre part, jQuery semble construit sur mesure pour ce genre de choses (probablement parce qu'il a été construit sur mesure pour ce genre de choses). Les deux développement et le fonctionnement des applications sont très gentils.

applications Internet riches est une bonne façon de faire des logiciels robustes qui agissent comme un logiciel de bureau traditionnel. Un problème commun avec RIA est que de nombreux développeurs ont tendance à placer la logique métier dans le code côté client. La logique métier et les états dans le code côté client est très précaire que l'on peut manipuler le code côté client en temps d'exécution. De plus, il est un système whitebox, ce qui permet aux pirates d'examiner le code et trouver des faiblesses, telles que la validation d'entrée effectuée uniquement dans le code côté client ou de manipuler les états. Ne vous laissez pas berner par l'obscurcissement, car il ne fait que ralentir un hacker, mais ne l'arrête pas. Billy Hoffman a écrit un bon livre sur la sécurité AJAX (appelé, ta-DAA , "Ajax sécurité") et je le recommande pour tous les développeurs RIA.

Cela ne signifie pas que l'AIR est par définition mauvais, vous pouvez écrire RIA sécurisé si vous savez ce que vous faites (pas la logique métier dans le code côté client, pas d'états, validation d'entrée [également] fait sur le côté serveur, etc.) . Il y a quelques cadres qui mettent en œuvre ce serveur securer conduit RIA, l'un est boîte à outils moulin (basé sur GWT) et ICEFaces devrait également être à ma connaissance.

Dans mon expérience, RIA GUIs ont tendance à être assez robuste pour communiquer plus d'informations aux utilisateurs. Il y a quelques probablement quelques exceptions à cela, mais je ne peux pas penser à un bon moment. RIA a l'avantage d'être accessible à tous par le biais d'un navigateur Web sans avoir à installer un client lourd (RCP). Sauf si vous avez un affichage complexe spécial qui ne peut se faire grâce à des technologies web que je vous recommande d'aller la route RIA.

Une organisation j'ai travaillé pour choisir RCP parce que leurs utilisateurs avaient besoin de travailler avec l'application à la fois en ligne et hors ligne (quand ils sont sur la route, etc.). Je sais que cela est possible avec Google grears maintenant, mais les engrenages ne sont pas vraiment assez grand public pour le grand organiazation à ce produit de base phare. Mais si vos utilisateurs n'avez pas le besoin d'aller en ligne vous vraiment sauver les tracas de la synchronisation des données de l'utilisateur / produit mises à jour ect entre votre application et le serveur rcp, RIA serait la voie à suivre dans ce cas.

Il y a aussi la possibilité de déployer un RCP avec quelques-uns des avantages d'un RIA. Une solution à l'étude pour notre client (exclusivement par le personnel au sein de leur entreprise) est l'utilisation d'une application Java lancée via une servlet Java.

Certains avantages identifiés comprennent:

  • Il est facilement mis à niveau, un peu comme un RIA (juste redéployer son fichier JAR, il sera choisi le moment la prochaine fois à la page broute avec l'applet)
  • Il semble, se sent, se comporte et fonctionne comme une application native, un peu comme un RCP (grâce à SWT)

Quelques inconvénients identifiés comprennent:

  • Les ordinateurs de l'utilisateur doit utiliser un plugin Java installé.
  • L'application doit être développée dans une version de Java compatible avec les plug-ins des utilisateurs (bien que le client peut avoir besoin d'une version minimale à installer sur les ordinateurs du personnel). L'outil RetroWeaver peut aider, même si je n'ai pas beaucoup d'expérience avec elle.
  • L'utilisateur doit garder le navigateur Web ouvert, sinon l'application sera terminée.

Quelle est la nature de cette application. Faut-il en cours d'exécution complètement sur un ordinateur client? Est-il besoin d'accéder aux données stockées localement? Est-ce que vous venez de replcaning l'interface graphique pour une application existante avec le moteur était toujours le code existant?

Mon autre significatif travaille sur un appareil de logiciel où elle a tiré profit de AJAX comme un moyen permettant de configurer l'appareil. Les fonctionnalités offertes pour la configuration est riche et aligne très bien avec RIA. De même, installer de logiciel localement sur le navigateur Web est extrêmement découragée.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top