Outre l'argument de la simplicité de Guanet (c'est-à-dire Wicket, c'est un système plus simple IMHO) et la réactivité de GWT dans le client (État du client de GWT et JavaScript - Code secondaire potentiellement complexe du client) et le plus grand potentiel de mise à l'échelle de GWT, ce qui est L'argument d'utilisation de GWT sur Wicket?
Personnellement, j'ai fait beaucoup de développement de guichets, mais n'a eu qu'un regard rapide sur GWT il y a longtemps.
9 Réponses :
À mon avis, le plus grand avantage de GWT vous permet de travailler avec une langue de programmation - Java, avec toute la bonté qu'elle apporte.
avec CSS, ils forment une paire puissante.
Pour le mettre un autre moyen, vous pouvez surtout oublier JavaScript et HTML.
Que ce soit un avantage ou non surtout de vos compétences et vos exigences. Nous avons eu ce même débat interne et, à la fin, une équipe a choisi Wicket et un autre GWT.
Vous pouvez faire presque le même argument pour coder dans Wicket ..?
Non , vous ne pouviez pas. Pouvez-vous écrire des applications riches sur le côté client dans Wicket sans JavaScript?
Non - groups.google.com/group/google-appengine/msg/fe9792729081FC6 D . ATM GWT compile tout droit à partir de la source Java et non du code octet. Donc, le compilateur devrait être étendu pour reconnaître la syntaxe Scala.
Je peux penser à plusieurs raisons pour lesquelles GWT est un meilleur choix que le guichet, pour les applications Web d'affaires typiques:
Je ne suis pas d'accord avec GWT l'avantage "énorme". Il existe de nombreuses grandes entreprises qui mettent des cadres de merde (comme le cas de JSF par exemple). Certes, Google en général contribue de belles cadres, mais la fin de la journée, elle est plus importante qui l'a effectivement travaillé plutôt que la société qu'ils travaillaient.
En fait, lorsque vous lisez vos deux autres points, je soupçonne que vous ne savez pas grand chose à propos de Wicket et de ce qu'il vise.
"Les cadres Web centrés sur le serveur comme le guichet sont obsolètes." Avez-vous déjà essayé de construire une application Web reposante avec HTML 4 et JavaScript (écrit avec GWT ou non)? HTML 5 changera certaines choses qui faciliteront la tâche (ou possible dans certains cas). Wicket vous sauve beaucoup de maux de tête ici.
"GWT vient de Google. Cela peut être injuste, mais avoir une grande entreprise de logiciels respectés derrière un outil est un avantage énorme". Je ne comprends pas ce point? Wicket est d'Apache, vous savez, les personnes qui nous ont donné Apache HTTP Server, propagent le serveur Web le plus utilisé? Sans parler d'autres produits tels que Tomcat, Anti, Maven, Log4J, Apache Commons, juste pour n'en nommer que quelques-uns.
Pourquoi les cadres latéraux du serveur sont-ils obsolètes? Pouvez-vous récupérer cette déclaration de quelque manière que ce soit?
Étant donné que les cadres de serveur n'ont pas été conçus avec la plate-forme de navigateur Web moderne à l'esprit. Ils supposent que la plupart des indicateurs d'interface utilisateur sont exécutés dans le serveur, pas dans le navigateur. Cela a eu un sens dans le passé, car les moteurs JavaScript et HTML dans les navigateurs étaient beaucoup plus limités et plus lents qu'aujourd'hui, sans parler des problèmes de compatibilité qui sont maintenant principalement résolus. Mon point est que dans une application Web moderne, tout le code d'interface utilisateur peut et doit exécuter dans le navigateur, pas le serveur.
Il est un peu pas juste de comparer GWT avec Wicket (ou de même) car ils viennent vraiment de 2 camps différents. Le premier est un cadre de construction d'applications frontales JavaScript, tandis que ce dernier est un cadre de candidature classique Java Web.
Les points ci-dessous ne sont donc pas autant que GWT vs Wicket, mais plutôt une liste générale compilée lorsque nous avons décidé d'utiliser GWT pour une application Web JavaScript / Ajax avancée:
Le génie derrière GWT est que vous travaillez uniquement avec Java. Ils ont fait un excellent travail avec RPC le rendant presque transparent pour le programmeur. Beaucoup de fois que vous pensez que vous codez plus comme une application de bureau au lieu d'une application avec un client et un côté serveur vraiment défini.
C'est très similaire aux objectifs du guichet.
Oui, c'est exactement ce que cela ressent lors de l'écriture d'applications avec Wicket - toute la familiarité et la facilité d'écriture d'une application de bureau. L'avantage du guichet via GWT IMHO est que, comme dans le monde du développement de bureau, la liaison des objets de modèle d'interface utilisateur dans le Wicket est obtenu par des appels de méthode standard et des références d'objet. Dans GWT, lors de la liaison de votre UI à vos objets de modèle de domaine, vous devez vous coucher avec un partenaire de lit très étrange: «Object Marshalling» - ce qui vous convient si vous aimez faire des choses de manière difficile.
Les avantages sont essentiellement que GWT est un outil permettant de créer un client basé sur JavaScript, il convient donc mieux si vous souhaitez un client basé sur JavaScript.
Centres de guichet sur le serveur, et tout en permettant d'intégrer JavaScript dans des pages apatrides, la manipulation de l'état côté serveur est l'approche la plus naturelle.
Il faut noter que les architectures sont très différentes.
avec GWT, votre architecture se transforme en serveur client, un client épais sur le navigateur, appelant des appels vers «Procédures» (Services) au serveur, à l'envoi et à la réception des données Avec Wicket (et d'autres cadres de composants centrés sur le serveur, tels que JSF et Tapisserie), l'architecture est une "traditionnelle" 3-calques, et ce qui est envoyé et reçu sont Pendant que vous pouvez certainement mélanger les deux pour s'adapter à l'autre architecture, cela ne serait tout simplement pas très naturel.
Les gens ont tendance à se concentrer sur "qui est plus facile à utiliser" (qui est complètement subjectif, selon vos antécédents) ou "qui est plus beau et a plus de composants", mais il ne faut pas sous-estimer la différence architecturale, qui affecte L'approche que vous devez prendre pour gérer les aspects tels que la sécurité et l'évolutivité.
Je pense qu'un problème commun est que les gens prennent en compte les gens en compte, mais surestiment leurs besoins du niveau Web et négligent les aspects de sécurité. Mon expérience au moins.
Je suis d'accord, la plupart des gens ne savent tout simplement pas comment gérer la sécurité et croire que cela va par magiquement «arriver» avec une certaine configuration quelque part. À propos de l'évolutivité, je pense que les deux technologies géreront également une évolutivité «non-Facebook» de manière aussi bonne, mais les approches seront différentes. Et utiliser la mauvaise approche entraînera des problèmes tout aussi laids.
C'est drôle comment la définition de "traditionnelle" a changé au fil du temps. Il y a des années, cela signifierait une approche client-serveur (client épais). Avant qu'il s'agissait d'un guichet-terminal et d'un serveur (client léger). Maintenant que nous sommes de retour à des clients épais avec JavaScript, je me demande à quoi ressemblera la prochaine architecture de la clientèle mince.
J'ai été impliqué dans un projet basé sur GWT au cours des derniers mois. J'étais fait partie de l'équipe de développement de guichets pendant des années, attendez-vous à un changement et attendez-vous beaucoup de GWT (ce que j'ai toujours grimpé comme un autre formidable cadre Java).
Honnêtement, je suis déçu quand il s'agit de travailler avec GWT. Je pense - toute votre équipe - cette productivité a pris un gros succès. Théoriquement gwt est génial. Mais lorsque vous facteur dans les bizarreries et les limites du cadre, les rapports erreurs médiocres (en particulier lorsqu'il s'agit d'erreurs de sérialisation), les périodes de compilation longues (entre 3 et 10 minutes et notre projet n'est pas encore aussi grand), Le fait que, lorsque tout soit dit et fait, vous devez toujours tester pour tous les navigateurs et trouver des modifications et des contours de contournement, le fait qu'il produit un énorme téléchargement initial (presque un MB, que nous réduisons progressivement, mais avec beaucoup d'effort), etc., etc., je sens que le guichet est beaucoup plus facile et plus rapide de travailler avec.
Je ne déteste pas à travailler avec GWT. C'est encore beaucoup mieux que la plupart des frameworks Java. C'est juste que j'attendais beaucoup plus de travailler avec elle; Je m'attendais même à ce qu'il soit éventuellement plus agréable que le guichet. Mais à la fin, ce n'est tout simplement pas imho. Espérons que GWT 2.0 améliorera beaucoup de choses et, espérons-le, certaines des bizarreries du plug-in éclipse seront également redressées bientôt.
Après avoir eu une expérience (principalement indirecte) avec GWT 2.0 et UIBINDe, je peux confirmer que les choses se sont améliorées. Je me sens toujours comme si vous avez besoin de beaucoup de code de plomberie pour faire faire les choses qui ne sont pas difficiles à faire en utilisant tout droit JavaScript.
Un avantage du guichet via GWT serait que le guichet peut gérer le cas où vous souhaitez fournir une fuite pour les clients qui n'ont pas activé JavaScript. GWT est entièrement porc pour JavaScript, Wicket vous permet de dégrader gracieusement.
Il y a peu d'autres avantages du guichet sur GWT que je trouve.
Le guichet ne reste pas toujours à la normale HTTP, JavaScript est indisponible. Seuls les composants conçus pour revenir.
Je suis NEWBIE à GWT, mais après une étude, j'ai trouvé que GWT est "approprié" pour mon nouveau projet d'application Web pour son client-focus qui me fait avoir envie de coder une application de bureau. Aujourd'hui, nous avons un client haute performance prêt à exécuter une application au client. Ma candidature peut être faite uniquement en Java et la classe OOP Java permet de construire notre propre cadre prêt à l'emploi pour notre équipe.