IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

GWT et Vaadin Java Discussion :

Faiblesses de GWT [Débat]


Sujet :

GWT et Vaadin Java

  1. #1
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut Faiblesses de GWT
    Bonjour,

    Cette discussion fait suite à la réaction de Mamelouk sur un article de mon blog (http://blog.developpez.com/benwit?ti...blesses_de_gwt)

    Je n'y faisais qu'exprimer mon opinion mais vu qu'il semble vouloir en débattre, je vous propose d'en discuter ici.

    Pour commencer, je tiens à préciser que j'aime beaucoup cette techno. Et même s'il m'arrive de parler d'inconvénients, le terme de faiblesses est plus en adéquation avec le fond de ma pensée.
    Je crois que c'est aux gens qui aiment une techno, qui veulent la défendre d'essayer d'être le plus objectif en pointant sur ces "faiblesses" qu'un évangéliste passerait sous silence.
    C'est en soulignant ses limites qu'on peut l'utiliser à bon escient, faire de ces faiblesses des forces, voire trouver des "parades" pour les contourner.


    #1 - Le fait de coder en JAVA son IHM
    Je conçois que c'est une "faiblesse" pour ceux qui veulent faire un site web (au sens original du terme : un graphe de documents) que de le coder en Java (Swing like). Et ne me dites pas que personne ne le dit car j'ai pu le lire sur ce forum.
    Je leur répond que GWT n'est pas fait pour cela. GWT est fait pour écrire des applications web riches (Ajaxifiés) et pour éviter ce que l'on nomme le "XML Hell". Si on garde à l'esprit ceci, ce n'est pas une faiblesse si on reste dans son champ d'application. En revanche, si on le compare à d'autres frameworks qui permettent de faire indifféremment "application" ou "site", c'en est une.

    #2 - La gestion de l'historique
    Ce problème inhérent aux applications AJAX qui ne rechargent qu'une partie de leur page pourrait être un problème de GWT. Les concepteurs ayant imaginé un mécanisme de gestion de l'historique, il tend à disparaître. Cependant, je pense que ça reste une petite "faiblesse" dans la mesure où il faut le gérer soit même si on fait un site classique.
    Dans le domaine de prédilection de GWT (le développement d'application), c'est une force ! En ne faisant rien, ça évite que l'utilisateur passe l'application dans un état non souhaité. Et au besoin, on peut le gérer comme on veux.

    #3 - L'indexation par les moteurs de recherche
    Là encore, l'approche GWT (tout en javascript) est une faiblesse pour la réalisation de "sites classiques". En revanche, pour les applications, je ne crois pas que ça ait un sens qu'un moteur indexe une vue de l'application.

    #4 - L'internationalisation
    GWT offre plusieurs mécanismes pour "internationaliser" son application. L'approche statique qui consiste à embarquer les chaînes de caractères dans le code généré et à générer une version par locale se défend. Les faiblesses que j'y trouve : écrire une méthode d'interface pour chaque libellé à traduire, recompiler le code aux changements de texte.
    Quand à leur approche dynamique, si j'ai bien compris, je la trouve assez pauvre : un "dictionnaire" embarqué dans la page que l'on peut modifier en éditant le fichier html (http://google-web-toolkit.googlecode...1.4/index.html).
    Si cela évite la recompilation des modifications et l'écriture de méthode par libellé à traduire, cela apporte les autres inconvénients qu'ils citent.
    Ces faiblesses là sont plus personnelles car je préfère un vrai service d'internationalisation, gérer par le serveur, qui permet de modifier à chaud les libellés, qui permet d'avoir plusieurs implémentations possibles (ficher de config, base de données, ...). C'est possible mais il faut le faire soi même.

    #5 - Les modules
    Avec GWT, la philosophie est de ne plus penser en terme de pages. L'idée de regrouper tout le code Javascript dans un unique fichier se défend également pour les avantages évoqués par les concepteurs. Personnellement, je ne suis pas séduit par cette approche dans le cas d'une application très riches en "écrans".
    Si on choisit de tout mettre dans un module, celui-ci tend à devenir obèse. Si c'est une légère faiblesse de taille de transfert sur le réseau (téléchargé la 1° fois, débits augmentant avec le temps ...) ou à l'éxecution (on peut différer le chargement de certaines parties), à la compilation, ça devient de plus en plus long.
    Si on choisit de faire plusieurs modules et de la navigation par hyperliens, cela se défend pour des "sous ensembles fonctionnels".
    On navigue de l'un à l'autre en retombant dans un mode page à page alors ? Entre cette gestion d'historique entre modules et à l'intérieur d'un module, même si ça semble possible, ça doit être pas si simple à mettre en œuvre.
    Et comment faire si vous avez une partie fixe ? réaliser les parties variables avec des modules et les charger dans des iframes ??? J'ai essayé et je n'ai pas été convaincu. Je veux bien reconnaître cependant qu'en dehors de mon application particulière, ce n'est pas vraiment une faiblesse.
    J'ai trouvé une façon de contourner cette faiblesse en ayant un module javascript de taille fixe quelque soit la "grandeur" de mon application.


    #6 - L'intégration des données des POJO

    Citation Envoyé par djo.mos
    Toutefois, d'après mes lectures, le point noir de GWT est le fait que les DTOs doivent implémenter une interface particulière (de GWT) ... ça, c'est vraiment "chiant" (excusez l'expression) et inadmissible à mon avis car il impose soit de:
    - faire que les objets métiers/dtos dépendent du fwk d'affichage ... plutôt mourir
    - garder deux hiérachies d'objets (objets métier et DTOs) tout en gérant les conversions ... plutôt mourir !
    La solution que j'utilise pour résoudre les faiblesses du point 5 m'ont masqué ce point. Mais je n'ai pas suffisamment essayé cette partie pour savoir s'il s'agit vraiment d'une faiblesse ou non ? Avant gwt 1.5, les annotations des POJO étaient bloquantes. Mais je ne suis pas sûr que le problème des "proxy" des ORM soit résolu avec l'arrivée de gwt 1.5 ?
    En revanche, je crois que les objets "métiers" ne pourront pas être traduit en javascript dans tous les cas et ça peut être une difficulté pour certains.

    A vous ...

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  2. #2
    Membre du Club
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    54
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2008
    Messages : 54
    Points : 59
    Points
    59
    Par défaut
    J'ai pas énormément utilisé cette techno, mais d'après ce que j'ai pu voir, GWT souffre de deux gros défauts :

    • L'obligation d'utiliser le JDK 1.4 ou inférieur. Vu les améliorations apportées pas la version 5 de Java (annotations, énumérations, generics), c'est, à mon avis, pas normal qu'une telle techno ne les supporte pas. Ceci dit, j'ai vu qu'il y a une nouvelle version de GWT en préparation qui devrait supporter la version 5.
    • Je rejoins la personne que tu as citée, je pense que c'est le principal défaut de GWT.

  3. #3
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    merci

    l'historique est géré dans GWT : il suffit de rajouter la balise
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <iframe id="__gwt_historyFrame" style="width:0;height:0;border:0"></iframe>
    pour moi le fait que GWT force à coder un site en java est son PLUS GROS avantage. je n'ai jamais touché une ligne de javascript et je suis capable de faire des sites web de dernières génération.

    par contre, bien vu pour l'indexation je n'y avais pas pensé (mais vu que mon appli tourne avec google maps il y a des trucs qui sont prevus pour les crawler). je vais me renseigner, je suis sur qu'ils y ont pensé chez google quand meme..

    si tu as une page qui as une partie fixe et une partie dynamique, tu marque l'endroit ou tu veut que ta partie dynamique soit avec un ID et dans ton code java tu fait Root.get(ID).add(tes_widgets)

    pour ceux qui utilisent hibernate, il existe hibernate4gwt pour les problèmes de proxy. je n'avais pas pensé à ce problème tellement il est léger (un application bien faite utiliser des pattern pour passer ses POJO d'une couche de l'application à une autre). et puis, comment fait-on dans les autres frameworks AJAX?

    glebreton, la dernière version de GWT vient de sortir, elle supporte Java 1.5, les annotations etc.

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  4. #4
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par glebreton Voir le message
    L'obligation d'utiliser le JDK 1.4 ou inférieur. Vu les améliorations apportées pas la version 5 de Java (annotations, énumérations, generics), c'est, à mon avis, pas normal qu'une telle techno ne les supporte pas. Ceci dit, j'ai vu qu'il y a une nouvelle version de GWT en préparation qui devrait supporter la version 5.
    La version 1.5 est sortie et ce n'est donc plus vraiment un défaut. Cependant, garder à l'esprit que si la syntaxe du 1.5 est prise en compte (annotation, generics, ellipse, boucle simplifiée, ...), l'émulation du JRE par GWT (pour la conversion en JS) bien que transparente et bien qu'augmentant le nombre de classes au fil des versions reste à l'origine d'erreurs chez les débutants.
    http://code.google.com/webtoolkit/do...ation/jre.html

    Citation Envoyé par mamelouk
    l'historique est géré dans GWT : il suffit de rajouter la balise
    Effectivement, comme je le disais, les concepteurs ont prévu un mécanisme.
    Cependant, de là à dire que ça suffit de rajouter cette balise, je trouve que tu y vas un peu fort ! Elle est certes nécessaire mais pas suffisante.
    Il faut en plus implémenter l'interface appropriée HistoryListener et sa méthode onHistoryChanged. Rien de très très compliqué mais je voulais juste souligné qu'il y a quelque chose à faire.

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  5. #5
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par mamelouk Voir le message
    pour moi le fait que GWT force à coder un site en java est son PLUS GROS avantage. je n'ai jamais touché une ligne de javascript et je suis capable de faire des sites web de dernières génération.
    Pour les application web, je suis bien d'accord. Vouloir écrire des interfaces graphiques seulement en XML est une gageure dans la mesure où il faudra à un moment ou à un autre du code de script pour faire des trucs un peu élaborés (même si cela ne représente que 5% du total).

    Pour l'indexation, il y a des techniques quand même sinon se serait mal venu de la part de google.

    Citation Envoyé par mamelouk
    si tu as une page qui as une partie fixe et une partie dynamique, tu marque l'endroit ou tu veut que ta partie dynamique soit avec un ID et dans ton code java tu fait Root.get(ID).add(tes_widgets)
    Merci mais je sais. Sauf que les widgets Java que tu insères, ils sont bien quelques part codés en Javascript dans un module. S'ils sont dans ton module principal ou dans un autre module lié, ils feront partis du "javascript monobloc" généré à la compilation et cela ne résout pas mon problème. Si c'est au moment de l'action d'insertion des widgets que le module supplémentaire contenant les dits widgets est téléchargé par le client, tu m'apprends un truc mais je doute que ce soit le cas ??? A creuser ...

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  6. #6
    Expert éminent
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Points : 7 679
    Points
    7 679
    Par défaut
    Bonjour,
    en fait, je ne parlais pas du cas des proxies, car ça, c'est un problème plus général et n'estpas spécifique à GWT.
    Je parlais plutôt du mécansime du RPC de GWT et des limitations qu'il impose:
    - Les objets de tansfert qui doivent implémenter IsSerialisable (interface fourni par Wicket)
    - Dans une moindre mesure, les interfaces de services qui doivent implémenter RemoteService.

    Pour le premier point, ça m'oblige soit à polluer mes pojos métier avec une interface GWT pas question, ou encore créer une autre hiérachie d'objets de transferts dépendant de GWT ainsi que le code de conversion de et vers mes POJOs casse gueule dans une application suffisamment conséquente.

    Je pense notamment à un autre moyen pour faire du RPC (remoting) qui est hessian: lles objets transférables sont des pojos ordinaires, de même pour les services, à aucun momeent je ne lie mon code à la lib de remoting.

  7. #7
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par djo.mos
    - Les objets de transfert qui doivent implémenter IsSerialisable (interface fourni par Wicket)
    Je pense que tu veux dire fourni par GWT ??? Tu fais trop de Wicket !
    Ce n'est plus obligé depuis la dernière version, Serializable peut suffire.
    Dans le groupe GWT, ils expliquent leur choix initial par un problème de sémantique : leur IsSerializable signifiait serialisable en javascript, ce qui est différent de l'interface Serializable de sun. Mais suite aux critiques des utilisateurs qui savent ce qu'ils font , ce n'est plus requis.

    Citation Envoyé par djo.mos
    - Dans une moindre mesure, les interfaces de services qui doivent implémenter RemoteService.
    Cela, je suis bien d'accord, c'est mal foutu. Il auraient pu faire mieux.
    Personnellement, j'ai détourner leur système en faisant à GWT ce que le MVC2 a fait au MVC .
    J'ai fait "un super service" qui envoit/reçoit les objets que je veux.
    Pour chaque service SS, cela m'évite d'écrire :
    • l'interface SSServiceAsync,
    • l'interface SSService qui étend leur RemoteService,
    • et la classe d'implémentation SSServiceImpl qui étend leur RemoteServiceServlet.

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  8. #8
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    Citation Envoyé par djo.mos Voir le message
    - Les objets de tansfert qui doivent implémenter IsSerialisable (interface fourni par Wicket)
    je savais pas que c'était impossible de travailler sans implémenter IsSerializable alors je l'ai fait...

    moi mes POJO implément rien de spécial et le transfert se passe très bien ?

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  9. #9
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    Citation Envoyé par djo.mos Voir le message
    - Dans une moindre mesure, les interfaces de services qui doivent implémenter RemoteService.
    est ce que vous m'éclairer en m'expliquant pourquoi c'est pas bien? moi ca m'a donné l'occasion d'aborder les Servlet en douceur (je connaissais rien à ce concept)

    A part le fait d'avoir une classe qui a pour suffixe ASync (ce qui devrait disparaitre à l'avenir), je vois vraiment pas le problème

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  10. #10
    Expert éminent
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Points : 7 679
    Points
    7 679
    Par défaut
    Citation Envoyé par benwit
    Je pense que tu veux dire fourni par GWT ??? Tu fais trop de Wicket !
    vi en effet.

    Citation Envoyé par benwit
    Ce n'est plus obligé depuis la dernière version, Serializable peut suffire.
    Dans le groupe GWT, ils expliquent leur choix initial par un problème de sémantique : leur IsSerializable signifiait serialisable en javascript, ce qui est différent de l'interface Serializable de sun. Mais suite aux critiques des utilisateurs qui savent ce qu'ils font , ce n'est plus requis.
    Oki, mon point ne tient plus la route dans ce cas, et tant mieux ! La première approche etait pour le moins pénible.

    Ca répond aussi à mamelouk
    je savais pas que c'était impossible de travailler sans implémenter IsSerializable alors je l'ai fait...

    moi mes POJO implément rien de spécial et le transfert se passe très bien ?
    Je savais pas que les versions courantes n'imposent plus cette limite.

    Citation Envoyé par mamelouk
    est ce que vous m'éclairer en m'expliquant pourquoi c'est pas bien? moi ca m'a donné l'occasion d'aborder les Servlet en douceur (je connaissais rien à ce concept)

    A part le fait d'avoir une classe qui a pour suffixe ASync (ce qui devrait disparaitre à l'avenir), je vois vraiment pas le problème
    Bah le simple fait que je suis obligé de faire un adapter GWT-ready pour chacun de mes services est un problème: ça ajoute beaucoup de code inutile à mon application. Je dis inutile car comme j'en ai déjà parlé, il existe plusieurs solutions de remoting qui n'imposent pas une pareille limitations et qui exposent directement mes services, sans que je sois obligé de les adapter.

  11. #11
    Membre averti
    Profil pro
    Développeur Java
    Inscrit en
    Novembre 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Novembre 2007
    Messages : 301
    Points : 368
    Points
    368
    Par défaut
    Pour répondre aux histoires de POJO :

    Serializable User-defined Classes
    A user-defined class is serializable if

    1. it is assignable to IsSerializable or Serializable, either because it directly implements one of these interfaces or because it derives from a superclass that does
    2. all non-final, non-transient instance fields are themselves serializable, and
    3. it has a public default (zero argument) constructor

    The transient keyword is honored, so values in transient fields are not exchanged during RPCs. Fields that are declared final are also not exchanged during RPCs, so they should generally be marked transient as well.
    Source: documentation version 1.4

    J’avais déjà posté mes critiques sur GWT dans l’autre sujet, je les remets en forme ici :

    - L'intégration n'est pas parfaite avec l'existant. Je trouve qu’une nouvelle technologie devrait toujours s’intégrer parfaitement avec ce qui est déjà existant pour éviter de perdre tout ce qui était intéressant dans les autres technologies.
    Pour ma part, je voulais utiliser Spring et Hibernate. Dans le cas de Spring, ça se passe plutôt bien avec GWT-SL. On peut concentrer tous ces contrôleurs. Dans le cas d’Hibernate, c’est un peu plus la merde dans le sens où Hibernate utilise des proxys pour les collections. Avec Gwt4Hibernate, on ne s’en sort pas trop mal, mais il y a du progrès à faire.

    - Il y a relativement peu de Widgets de base. On peut pallier ça avec GWT-Ext et ExtJs. Par contre, ce dernier vient de changer de licence pour passer en GPL...

    - Il n'impose rien dans le domaine de l’architecture et cela peut vite devenir inmaintenable si quelque chose n'est pas fait de ce côté. Alors que dans les frameworks classiques, on suit le traditionnel MVC qui nous permet d’avoir quelque chose de bien rodé.

    - On utilise du Javascript donc ça pose un souci vis-à-vis de l'évolution des navigateurs. Firefox 3.0, Internet Explorer 8.0 ? Vu que l’on ne contrôle pas le processus de génération du Javascript cela pourrait être un problème.

    - La vision tournée « monopage » (enfin, c'est comme ça que je le vois) ne s'adapte pas toujours à ce que l'on recherche. Cela rejoint la remarque nº 5.

  12. #12
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par darkxan
    - Il y a relativement peu de Widgets de base. On peut pallier ça avec GWT-Ext et ExtJs. Par contre, ce dernier vient de changer de licence pour passer en GPL...
    C'est vrai que ça manque encore de widgets mais cela ne pourra que s'améliorer avec le temps ...

    GWT-Ext, ça m'a beaucoup plus initialement mais depuis les histoires de licences, ça m'a un peu refroidit ...
    D'un coté, on a GWT-Ext (développé initialement par Sanjiv) qui est un wrapper des librairies de Ext-JS (les libs d'ext sont requises).
    De l'autre, on a Ext-GWT (ex MyGWT développé initialement par Darell) qui définit en pur GWT des composants au même look and feel que Ext-JS)

    Puisque le premier projet est plus dépendant de l'évolution d'Ext-JS, j'aurai préféré que ce soit celui-ci qui rejoigne l'équipe de Jack Slocum. Malheureusement, c'est l'inverse qui s'est produit, ajoutant la confusion des noms et provoquant la création de fork ...


    Citation Envoyé par darkxan
    - Il n'impose rien dans le domaine de l’architecture et cela peut vite devenir inmaintenable si quelque chose n'est pas fait de ce côté. Alors que dans les frameworks classiques, on suit le traditionnel MVC qui nous permet d’avoir quelque chose de bien rodé.
    C'est un avantage si on veut se faire sa propre architecture (c'est possible de faire du MVC) mais sinon, ta remarque est pertinente.

    Citation Envoyé par darkxan
    - On utilise du Javascript donc ça pose un souci vis-à-vis de l'évolution des navigateurs. Firefox 3.0, Internet Explorer 8.0 ? Vu que l’on ne contrôle pas le processus de génération du Javascript cela pourrait être un problème.
    Cela pourrait être un problème mais je ne m'inquiète pas trop là dessus.
    Premièrement, parce que c'est Google, il s'entend bien avec la fondation Mozilla et/ou est capable de nous pondre un navigateur s'il le souhaite .
    Deuxièmement, parce que GWT c'est principalement un compilo et je pense qu'on pourrait l'adapter à d'autres langages de scripts.

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  13. #13
    Membre averti
    Profil pro
    Développeur Java
    Inscrit en
    Novembre 2007
    Messages
    301
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Novembre 2007
    Messages : 301
    Points : 368
    Points
    368
    Par défaut
    GWT-Ext, ça m'a beaucoup plus initialement mais depuis les histoires de licences, ça m'a un peu refroidit ...
    Pour ma part, j'utilise GWT-Ext 2.0.3 et Ext-Js 2.0.2 (version proposant du LGPL). Normalement, il n'y a pas de problème de licence. Par contre, je vais être bloqué avec l'utilisation de la version 2.0.2 et donc de tous les bugs qui vont avec...
    Note : Il y a plein de Widgets vraiment sympathique par contre, on perd parfois la force de l'Ajax : c'est-à-dire son dynamisme. En effet, avec certains Layouts il n'y a plus la possibilité de faire des modifications, un comble pour du Javascript !

    C'est un avantage si on veut se faire sa propre architecture (c'est possible de faire du MVC) mais sinon, ta remarque est pertinente.
    Je suis d'accord que c'est un avantage, mais nous ne sommes pas tous architecte. Et je suis forcé de constater que ce n'est pas mon cas. D'ailleurs, je n'ai pas trop vu d'articles là-dessus. J'en ai vu quelques-uns et les solutions me faisaient froid dans le dos.

    Pour ma part, je pense utiliser le design pattern « Command » pour découpler tout ce qui est RPC et les modifications de l'interface de mes composants. Dans mon cas, cela s'adapte bien mais je ne suis pas sûr que cela soit bien pour tous les cas.

    Dans un premier temps, j'avais essayé d'utiliser un ensemble d'actions. Le composant graphique récupère une action (qui hérite une classe abstraite) via une fabrique et invoque la méthode « execute ». L'utilisation de la classe abstraite permet de gérer les logs, les exceptions, possiblement la gestion des droits. Par contre, je ne trouvais pas ça terrible au niveau de la modification de la vue. C'est pour ça que la notion de « Receiver » du pattern « Command » est intéressant dans mon cas.

    Cela pourrait être un problème mais je ne m'inquiète pas trop là dessus.
    J'ai remarqué que mon code ne marche déjà plus sous FF 1.5 donc j'ai eu un coup de stress avec FF 3.0 et IE 8.0.

  14. #14
    Membre régulier Avatar de Caroline76
    Profil pro
    Inscrit en
    Avril 2008
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2008
    Messages : 94
    Points : 110
    Points
    110
    Par défaut
    Nous utilisons GWT pour des applications et pas pour des sites web (ou alors, seulement des petits modules), donc l'historique ou le mono-page n'est pas vraiment un probleme.

    Pour les objets metiers, je genere des classes utilisables par mon client (maven le fait), mais des methodes de conversion doivent etre ecrites. C'est un peu lourd, ca fait du travail en plus, et c'est source de bug, mais nous n'avons pas trouve d'autre solution.

    Programmer AJAX en Java, c'est super, mais j'ai eu des bugs lorsque mes objets n'etaient pas "supprimer" par un garbage collector non present, ou different de celui de java, dans JS (que je connais tres peu), donc perte de temps une fois de plus.

    Sinon, nous sommes globalement satisfaits de cette technologie.

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    104
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 104
    Points : 61
    Points
    61
    Par défaut
    Salut benwit,Je pense que ce débat est très instructif pour toute la communauté qui aime gwt.J'ai pas compris ton entendement sur cette partie
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    Les concepteurs ayant imaginé un mécanisme de gestion de l'historique, il tend à disparaître
    peux tu m'éclairer stp.
    Merçi

  16. #16
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2008
    Messages
    64
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : Avril 2008
    Messages : 64
    Points : 59
    Points
    59
    Par défaut
    Si j'ai bien compris l'internationalisation de Gwt, le fichier properties se met dans le package client et tout se fait en local notamment le changement de langue....
    Ça simplifie le programme (pas d'accès serveur, pas de recompilation....) mais donne les inconvénients cités.

  17. #17
    Membre habitué
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    258
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2006
    Messages : 258
    Points : 171
    Points
    171
    Par défaut
    Concernant le manque de composant graphiques, et les soucis de licence GWT-Ext, aujourd'hui vers quel wrapper vous allez vous tourner ? (si on souhaite avoir de l'open source total).
    Que pensez-vous de SmartClient ? j'ai fais un tour sur la démo, perso je trouve que cela rame.

  18. #18
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par dolfendo Voir le message
    Salut benwit,Je pense que ce débat est très instructif pour toute la communauté qui aime gwt.J'ai pas compris ton entendement sur cette partie
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    Les concepteurs ayant imaginé un mécanisme de gestion de l'historique, il tend à disparaître
    peux tu m'éclairer stp.
    Merçi
    Avec les applications et sites web classiques, on passe d'une page à une autre.
    Le navigateur garde l'historique de navigation de manière à pouvoir revenir en arrière ...

    Avec les applications et sites utilisant AJAX, on modifie uniquement une partie de la page.
    Certaines personnes disent que c'est un problème car pour l'utilisateur lambda, ça n'a plus le comportement habituel :
    L'interface graphique change mais il ne peut plus revenir en arrière ...
    Ce qui est normal puisque l'adresse de la page n'a pas changé pour le navigateur qui n'a pas renseigné son historique.

    Ce problème tend à disparaître avec GWT car les concepteurs ont prévu un mécanisme (avec l'iframe) qui permet dans son application GWT de gérer l'historique du navigateur. On peut donc développer en AJAX, modifier une page partiellement et modifier l'historique de manière à avoir un comportement classique (L'utilisateur peut revenir à l'état précédent avec le bouton de retour).

    Puisque le mécanisme est prévu, je pense que ce n'est plus un véritable problème.
    Si on veut éviter d'avoir un historique, c'est plutôt un avantage !
    Mais si on veut l'historique similaire à ce qu'on aurait en mode classique (page à page), c'est une petite faiblesse. "Petite" car on peut le faire, "faiblesse" car quoi qu'on en dise, cela fait un truc de plus à gérer.

    J'espère avoir été plus clair.

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  19. #19
    Membre chevronné

    Homme Profil pro
    Architecte logiciel
    Inscrit en
    Novembre 2006
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 252
    Points : 1 954
    Points
    1 954
    Par défaut
    Citation Envoyé par tatemilio2 Voir le message
    Concernant le manque de composant graphiques, et les soucis de licence GWT-Ext, aujourd'hui vers quel wrapper vous allez vous tourner ? (si on souhaite avoir de l'open source total).
    Que pensez-vous de SmartClient ? j'ai fais un tour sur la démo, perso je trouve que cela rame.
    J'en reste à Ext-js et le binding gwt associé. C'est pas du 100% gwt, mais l'avantage est que la lib ext-js est bien développé, relativement compacte et performante.

    J'ai pas mené de benchmark mais j'ai l'impression que le compilateur produit un code js assez peu performant en regard de ce que l'on peu faire à la main. Faudrait que je mène des tests avec le 1.5.

  20. #20
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    Citation Envoyé par fluff Voir le message
    Si j'ai bien compris l'internationalisation de Gwt, le fichier properties se met dans le package client et tout se fait en local notamment le changement de langue....
    Ça simplifie le programme (pas d'accès serveur, pas de recompilation....) mais donne les inconvénients cités.
    Si j'ai bien compris (corriger moi si je me trompe), l'internationalisation de GWT peut se faire de deux manières différentes :

    La méthode statique
    Elle consiste à avoir des fichiers de propriétés par langue (ensemble de clé/valeur) dans son package client. Le compilateur GWT remplace les clés du code source java par les valeurs lors de la fabrication du code javascript. C'est pour cela qu'il génère autant de versions compilées que de langues.
    Comme le remplacement se fait à la compilation, il peut indiquer des erreurs comme le manquement d'une clé.
    L'intéret, c'est qu'une fois les fichiers js envoyé sur le poste client, ce dernier dispose d'une version intégrale dans une langue sans avoir besoin de rappeler le serveur. La contrepartie, c'est que pour changer de langue, il faut rajouter un paramètre de locale dans l'url et re-télécharger la version pour la nouvelle langue.
    Un autre inconvénient, c'est que pour modifier une chaine de caractère, si vous pouvez modifier uniquement le fichier de propriété sans toucher au code, il faudra quand même recompiler.

    La méthode dynamique
    Cette méthode utilise des dictionnaires embarqué dans le code js généré. Le remplacement peut se faire dynamiquement dans la partie cliente. L'intérêt est de pouvoir modifier les chaines directement dans le fichier js généré car elles sont regroupés dans un même tableau javascript (le dictionnaire) contrairement au cas précédent où elles sont un peu partout.

    Dans les deux cas il n'y a plus d'accès serveur une fois le code client sur le client. Dans le cas du statique, une recompilation est obligatoire (à moins que vous ne faisiez un recherche remplace dans le code js généré à vos risques et périls)

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

Discussions similaires

  1. GWT peut-il remplacer les jsps ?
    Par le Daoud dans le forum GWT et Vaadin
    Réponses: 76
    Dernier message: 14/07/2008, 13h33
  2. [2D] Faiblesse de l'algo de collision pixel-perfect
    Par CPPTryer dans le forum Physique
    Réponses: 3
    Dernier message: 28/03/2006, 19h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo