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
En effet GWT-Ext (nom technique GXT et précédemment MyGwt) ne se base pas sur ExtJS vu qu'il est entièrement réécrit en Java. Il utilise par contre les CSS et les images du projet Ext.Envoyé par mamelouk
Comme l'a dit benwit, ils ont embrouillé tout le monde avec tout cela.
C'est toujours le même développeur: Darrell. Maintenant, il doit être aidé par les développeurs de Ext et il ne travaille plus pour la gloire car il y a un modèle économique en dessous.
J'ai l'impression que GWT-Ext et GXT(Ext GWT) sont deux librairies différentes, bien qu'elles reposent toutes les deux sur Ext JS.
Salut à tous
Je voulais juste venir déposer mon grain de sel, car on entend partout des gens dire "ah la gestion de l'historique c'est un peu chiant on doit le faire soi même, etc..."...
La seule chose que j'ai à dire c'est : ne confondez pas les inconvénients dus à un choix technologique et ceux dus à un framework.
En l'occurrence la gestion de l'historique et des favoris est pourrie par AJAX et non par GWT. Ce dernier a au contraire du mérite car il nous propose une solution plus ou moins élégante et qui plus est grâce au modèle Java avec quelques classes bien codées, cela devient très vite beaucoup plus facile à gérer qu'avec pas mal d'autres frameworks AJAX. (Du genre ta vue/action implémente une interface NeedHistoUpdate et derrière un mécanisme gère ça à ta place).
Si on me disait en Flash l'historique, c'est lourd, là OK, car Flash est à la fois une technologie et un framework, et c'est donc bien à lui qu'incombe l'inconvénient gestion de l'historique (d'ailleurs on peut gérer l'historique en Flash, je suis curieux ?)
C'est comme le côté "il faut savoir faire des css" > On parle bien d'application web là, et encore une fois à moins d'être en techno flash (ou c'est beaucoup plus compliqué qu'une CSS), il a toujours fallu avoir des connaissances en HTML / CSS pour faire du web. Tout comme il faut savoir faire du Java pour faire une webapp Tomcat ! Et personne ne reproche à à Tomcat.
Donc pour reprendre les différents points cités :
#1 - Le fait de coder en JAVA son IHM
Comme request j'aurais bien aimé un mécanisme déclaratif. Mais j'ai tendance à avoir envie de m'enfuir quand je vois tout le code XML super verbeux que certains frameworks génèrent. Mais c'est vrai qu'après avoir vu la manière de faire de Flex qui est vraiment sympa, on se pose des questions. Cela dit rien n'empêche de développer une couche pour faire du déclaratif en XML et de parser ensuite cela pour générer de l'interface. Ca risque de ramer un peu par contre, et ça prend du temps on est d'accord.
#2 - La gestion de l'historique
Non pertinent car ce n'est pas lié à GWT mais à AJAX. Cela dit GWT propose un mécanisme satisfaisant pour y remédier.
#3 - L'indexation par les moteurs de recherche
Non pertinent encore une fois car ce n'est pas le problème de GWT mais d'AJAX à la base. Quand quelqu'un choisit de faire quelque chose en AJAX ce point est déjà foutu, avant même qu'il ait choisi la technologie qu'il allait employer. Donc on fait l'amalgame entre inconvénient du à la techno et inconvénient du au framework. Cela dit on peut toujours avoir un site 100% Ajax et être premier dans Google, il faut se motiver un peu c'est tout.
#4 - L'internationalisation
Je trouve qu'ils auraient pu séparer les constantes du code JS généré... Si on change de langue il recharge tout le code alors que seuls les libellés ont changés... Moyen moyen, je comprends pas vraiment leur approche. Et j'ai pas encore trouvé d'autre moyen que d'écrire locale=lang_lang dans l'url pour changer la langue ! Un peu aberrant j'aimerais pouvoir changer de langue sans recharger la page. Après on est en Java donc on fait ce qu'on veut, mais je parle ici du mécanisme par défaut.
#5 - Les modules
Je trouve au contraire que c'est un point fort de GWT qui permet de vraiment découper son application proprement. Assez vite on peut avoir plusieurs modules qui évoluent indépendamment avec une gestion du cache de chacun, pour éviter de tout recompiler à chaque fois, etc... On se retrouve avec des projets correctement découpés si on le souhaite.
#6 - L'intégration des données des POJO
A part pour Hibernate pas de problème que du bonheur, surtout au niveau de la propagation des exceptions. Et il suffit d'étendre la classe GwtLazyPojo ce qui est relativement simple comme solution au problème. On se fait un super-objet qui étend cette classe, les autres objets du domaine étendent le super-objet et c'est bon. De toute façon avec Hibernate on a toujours plus ou moins un super objet qui contient une méthode getId() ou getPk() pour simplifier le problème des identifiants uniques. Le problème incombe pour moi plus à Hibernate qu'à GWT qui met des proxys partout. Est-ce qu'on n'essayerait pas de faire porter le chapeau à GWT pour un des côtés les plus relous d'Hibernate ? Quand on envoie un objet métier Hibernate via RMI ou Spring Remoting à un serveur distant, ça ne se passe pas forcément mieux que pour GWT, et on ne dit pas que c'est la faute de RMI ou de Spring, mais bien à cause des proxy hibernate. Au final grâce à HB4GWT on a une solution pour faire du POJO avec Hibernate sans pour autant écrire un DTO par objet métier. Ce qu'aucun autre framework comparable à GWT ne propose.
Je rajouterait un 7ème point :
# 7 - Pas assez de recueil de bonnes pratiques ou de frameworks de développement d'IHM
Certains disent qu'on a trop de liberté dans GWT et qu'on risque de se perdre. Moi je pense que la liberté c'est que des avantages car personne ne nous impose ce qu'il faut faire, si on se perd c'est pas à cause de la liberté offerte au départ (enfin si), mais pour moi à cause du manque de librairies adaptées pour gérer tout ça correctement, ou parce qu'on est pas forcément assez orienté architecture. Mais GWT n'est pas à mettre tel quel entre toutes les mains on est d'accord.
J'attends vraiment avec impatience un bon framework client pour GWT (je ne parle pas d'une collection de Widgets, mais de quelque chose qui permet de vraiment bâtir une application rapidement). Je pense qu'on peut même faire du RAD avec GWT il suffit de mettre une bonne surcouche par dessus. J'avais commencé à développer quelque chose qui allait dans ce sens mais pas assez abouti pour être publié. Et surtout pas assez bien conçu.
Sinon à la page précédente quelqu'un dont j'ai oublié le nom (désolé le forum n'est pas en Ajax donc si je retourne à la page 2 mon petit doigt me dit que je vais perdre mon message ^^) parlait de Flex. Ca m'intéresse énormément d'avoir le retour de quelqu'un qui a bossé sur les 2 technologies, car j'ai découvert Flex hier et j'ai été bluffé. Cela dit je connais bien GWT et je sais qu'on peut aller très loin avec. Je me demande donc si Flex tombe en rade un peu avant sur certains concepts, ou si il peut concurrencer GWT en tout point ?
Ne serait-ils pas plutôt destiné à un usage différent ?
Flex aurait une vocation plus multimédia et grand public et GWT une vocation application d'entreprise ergonomique ?
Je ne sais pas trop, mais il m'a été présenté comme un framework satisfaisant à destination des entreprises et je dois avouer qu'il avait l'air plutôt convaincant comme tel. Interface agréable, de qualité et rapide à mettre en œuvre, avec ActionScript pour exécuter du code côté client (c'est là que se trouve ma plus grosse inquiétude, ActionScript peut-il vraiment rivaliser avec la puissance du Java comme langage objet sur le client ?), serveur Java ou tout ce qu'on veut avec même une implémentation proposée de Comet... Bref, que du lourd !
Et je n'ai pas l'impression que la stratégie d'Adobe au niveau de Flex se limite à des tâches du style site multimédia uniquement. Du moins leur communication semble également aller dans le sens des applications d'entreprise plus traditionnelles, ainsi que dans le sens de sites webs grands plublic. Mais on s'éloigne du sujet...
GWT
Ce qui me gène c'est l'adhérence des DTO avec le framework GWT. Par contre, avoir une couche de DTO (qui je le rapelle est l'image "affichable" d'un graphe d'objets métiers) est nécessaire pour peu qu'on utilise un ORM ...
Avec hibernate comme ORM on fait comment pour transférer des objets métiers à la couche javascript ? La couche DTO est nécessaire et fait partie des pattern utilisé en J2EE. Par contre pouvoir utiliser des POJO aurait été préférable.
L'autre inconvénient qu'on peut voir (qui n'est pas critique) c'est l'intégration à spring de la couche de service. On ne peut pas utiliser, comme avec struts l'injection de dépendance dans les servlets GWT.
Cela dit il est possible de n'utiliser GWT que pour l'IHM et d'utiliser ensuite du JSON + XMLHttpRequest pour l'interaction avec le serveur.
C'est même recommandé lorsqu'on veut échanger avec d'autres technos serveurs comme PHP.
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.
gwt/spring est maintenant
Il est maintenant depuis qque temps d'ailleurs de controler GWT via spring et de faire de l'injection de dépendance dedans je crois qu'il est également possible d'utiliser GWT comme IHM pour les portlets 2.0 (jsr 268 je crois).
GWT a de moins en moins de limitations.
Pour moi la plus grosse faiblesse de GWT c'est le layouting.
Imbriquer par exemple un CaptionPanel dans un TabLayoutPanel avec scrollbar ca parait tout bête.
Dans GWT c'est un cauchemard.
Bug à gogo: Scrollbars qui n'apparaissent pas, CaptionPanel qui déborde sur le TabLayoutPanel, TabLayoutPanel qui déborde la taille de l'écran sans raison.
Des exemple comme ça il y'en a à la pelle.
Parfois on insère au milieu un autre type de Panel et miracle ça marche, parfois non.
A chaque écran j'ai eu envie de me tirer une belle dans la tête à un moment ou un autre.
Je pense que c'est important de bien maitriser les Css pour pouvoir gérer ses écrans convenablement.
Sur mes appli j'utilise beaucoup le FlowPanel, qui ne sont que des dv html, et je leur fix des classes css que je controle avec mon Css. Ca me permet de faire des écrans qui fonctionnent correctement avec tout les navigateurs, mais j'avoue que si certaines notions de css ne sont pas comprises ca peut rendre fou.
j'arrive un peu tard mais c'est mon actualité : Dev en GWT, donc j'essaie de poursuivre le débat aujourd'hui !
pvoncken ditSur mes appli j'utilise beaucoup le FlowPanel, qui ne sont que des dv html, et je leur fix des classes css que je controle avec mon Css. Ca me permet de faire des écrans qui fonctionnent correctement avec tout les navigateurs, mais j'avoue que si certaines notions de css ne sont pas comprises ca peut rendre fou.
c'est cela que je trouve bizarre, moi j'essaie d'utiliser(
je fais peut-être mauvaise route !) tous les différents panels mis à ma disposition(FlowPanel, VerticalPanel, DockLayoutPanel..etc...j'utilise souvent moi FlexTable.......en essayant de préférence d'employer les panel qui se transforme en div ensuite à la place de table!) afin d'agencer mon IHM comme voulu et je me sers de la CSS seulement pour modifier seulement sa présentation(background, border, font,....voir margin, padding si nécessaire : comme ils disent "à la SWING" : agencement de panel/layout. J'ai codé bcp de client lourd dans ma jeunesse!)mais je n'essaie pas de modifier son comportement ou son positionnement comme on ferait avec une JSP pour structurer ma page (position, overload ..)
j'ai peut-être mal compris ton propos ?
Ma conclusion aujourd'hui: GWT permet de coder l'IHM tout en java; oui mais on a besoin de sérieuse compétence en CSS si on veut réaliser des IHM un peu sexy....
cela me choque pas trop car la cible c'est le web->navigateur web.
votre avis m'intéresse sur ces remarques.......pour savoir par exemple s'il faut que j'achète un livre sur CSS afin de monter en compétence....
Monter en compétence sur Css est une très bonne idée qui te servira pour Gwt et pour tous tes autres projets Web, aujourd'hui et dans le futur.
C'est une stratégie cohérente d'utiliser tous les panel que google met à disposition avec Gwt. Surtout si tu ne maitrise pas completement les Css. Ils sont fait pour ca, donc il n'y a pas de souci sur ce point.
Après, pour ceux qui maîtrisent Css, c'est beaucoup plus puissant de n'utiliser que des FlowPanel auxquels on fixe des nom de class Css afin de manipuler leur présentation (et pas leur comportement). Le positionnement fait parti de la présentation et pas du comportement.
En réalisant ton appli avec des FlowPanel, tu peux changer entirement la présentation juste en changeant la feuille de style. Mieux encore, tu peux définir une feuille de style par média, afin que ton appli soient compatible avec des smartphones, des tablettes ou des desktop ou même des téléviseurs... (voir mediaquery)
Il ne s'agit en fait que d'utiliser les Css dans le but pour lequels ils ont été créé.
Un conseil, au lieu d'acheter un livre, tu peux commencer par consulter des sites et des ressources disponibles sur la toile et qui font le tour des bases et qui sont vraiment bien fait.
-edit- une précision pour les flowpanel, personnellement j'étands les flowpanels et je fixe la class Css dans le constructeur de ma nouvelle classe que je peux ainsi réutiliser de manière factorisée.
tu dis
j'en étais persuadé au moment ou tu l'as dit mais ......+ je code des DockLayoutPanel, enchainé avec des ScrollPanel et des VerticalPanel, FlexTable.....un bon mélange ...C'est une stratégie cohérente d'utiliser tous les panel que google met à disposition avec Gwt. Surtout si tu ne maitrise pas completement les Css. Ils sont fait pour ca, donc il n'y a pas de souci sur ce point.à la manière swing du à mon historique de developpeur....GWT a pu en + avoir ce style d'argument !
Je me dis Maintenant que c'est pas si bête ....j'étais loin LOIN d'être convaincu par ce que tu disaisbeaucoup plus puissant de n'utiliser que des FlowPanel auxquels on fixe des nom de class Css afin de manipuler leur présentation (et pas leur comportement)Tout ça pour dire : est-ce qu'il y a bcp de gens
qui font comme pvoncken (FlowPanel et ensuite CSS) car de l’expertise forte en CSS : tout se passe bien!
ou
composition des différents layouts mis à disposition (au départ RootLayoutPanel ..puis...DockLayoutPanel avec des HorizontalPanel, SimplePanel, FlexTable..etc..etc....)
là MOIdu bidouillage de code ! car comportement
je pense m'y prendre pas trop mal avec les layout (à la mode swing : c'est peut-être mon tort?) et vous ?
difficile de donnée des exemples précis!
Salut,
Je serai curieux de voir comment tu garanties une taille fixe pour un module JS même si l'application évolue et augmente en terme de fonctionnalité... à moins d'avoir mal compris ce que tu voulais dire...
++
Tu as bien compris.
Je te rassure, en théorie tu as raison, si mon application GWT augmente en fonctionnalités, le code javascript généré augmente bien.
Sauf qu'en pratique :
mon application GWT n'est pas une application métier mais une méta-application qui est un "viewer GWT" côté client. Elle consiste à afficher des composants graphiques (le modèle de cette méta-application) et à réagir à des évènements. Bien entendu, si j'ajoute de nouveaux composant graphiques élémentaires, le code JS croit. Sauf qu'au bout d'un moment, avec un nombre de widgets assez large qui couvre la plupart des besoins, le code JS tend à ne plus évoluer.
mon application métier, elle, est une application pur serveur. Lorsque l'application métier croit en fonctionnalités, j'ai bien entendu plus de vues (code Java côté serveur) mais ces vues sont constitués de composants élémentaires envoyés par RPC sous forme de données au viewer GWT qui les affiche.
Tu comprend le principe ?
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.
oui, je comprend le principe.
Je comprend que le code JS ne croît pas proportionnellement au nombre de widgets utilisés mais bien au nombre de widgets développés... quoiqu'on peut réutiliser dans de nombreux cas, une base de code commune.
La phrase citée dans mon précédent post, laisser croire, à mon sens, que tu avais trouvé la formule magique pour tout coder en une seule fois... ce que je ne conçois pas.
Le nombre de ligne de code croît plutôt de manière logarithmique et non exponentielle, heureusement !
Pour rebondir sur ce que tu dis lnp, je préciserais que GWT propose une technique de code-splitting, qui consiste à fragmenter le code javascript sur plusieurs fichiers et à l'injecter dans le DOM à la demande du client. C'est une des principales amélioration de la version 2.5 (novembre 2012).
Cette dernière version commence à fournir un Framework vraiment productif, à l'heure où on cherche de plus en plus à avoir des interfaces riches et réutilisables sur plusieurs périphériques (Serveur, bureautique, domestique, smartphone, tablette, etc.). Personnellement je crois que GWT ouvre une petite passerelle timide entre JAVA et HTML5... A suivre
C'est peut être un détail, mais par exemple sous GWT je trouve absurde de ne pas pouvoir utiliser plusieurs fois un Widget que l'on a instancié. Mais je crois que cette limitation se trouve également dans Swing.
Sinon je suis d'accord avec djmalo pour les problèmes de LayoutPanel et les scrollbar qui ne sont pas là alors qu'elle devraient l'être ..
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager