Dois j’utiliser Vaadin cadre

Question

J’ai juste essayé de jouer avec Vaadin cadre et il me semble très facile à utiliser. De plus ce que j’aime son cadre est qu’il est construit sur le dessus de GWT. Que pensez vous, dois je continuer à utiliser ce cadre ou il est préférable de s’en tenir avec GWT.

Answer 1

Hey. Comme un avertissement, je travail pour la société de développement de Vaadin.

Vaadin utilise GWT dans une façon que l'on dispose d'un ensemble de composants précompilé dans GWT. Vous pouvez, bien sûr, en plus de faire vos propres composants si vous le souhaitez. Cependant, l'ensemble des composants est assez complète, et peut souvent être personnalisé pour votre propre besoin. Cela signifie que vous n'avez pas à recompiler votre code de Java vers JavaScript à chaque fois que vous changez d'application. Vous venez de combiner la disposition de tous les composants.

Le cadre est gérés par le serveur, de sorte que la logique est géré côté serveur. Les composants a deux parties, le client et le serveur de fichier. Le côté client est juste un mannequin "afficher" pour le composant. Une fois que vous interagissez avec elle, il envoie un message au serveur qui a été pressé/écrit/etc. Ensuite, le serveur décide de ce qui doit être fait. C'est pour plus de sécurité, parce que vous ne pouvez pas "pirater" la logique que seule une petite API signifiait pour l'envoi des demandes est disponible dans le javascript. Ce peut être, dans certains cas, un peu de compromis avec la rapidité de l'application, mais je ne pense pas que c'est un si mauvais. Le pire de la vitesse des bosses sont généralement db requête aller-retours et un tel, qui n'a rien à voir avec le choix du framework d'INTERFACE. La lenteur des démos comme le suggère peut-être parce que vous êtes loin d'être le serveur ou il y a une forte utilisateur frappé à l'instant. Essayez-la dans un environnement propre, à proximité de la la finale de l'application de votre application, pour voir comment il se comporte. Il y a quelques prêts d'application que vous pouvez juste de déployer de le tester.

Je suppose que le choix se résume à ce que vous essayez de faire. Vaadin est bon pour les applications web, que vous pouvez construire une normale de l'application Java et ne la dynamique de l'INTERFACE utilisateur web pour facilement. Si vous faites quelque chose de plus traditionnel site web, où les utilisateurs uniquement les vues de la page - plus activement interagit avec elle, puis Vaadin est pas la meilleure façon d'aller. Aller avec certains autres cadres comme des rails ou d'un framework php etc. Je pense que vous êtes plus à faire une application comme vous êtes ce qui suggère que vous êtes en utilisant GWT maintenant, donc Vaadin devrait être bon.

Poser plus de questions, ici, sur le Vaadin forums ou sur le canal irc #vaadin @freenode et peut-être que quelqu'un peut vous donner une raison de plus pourquoi ou pourquoi ne pas utiliser Vaadin.

Answer 2

Eh bien, je voudrais commenter quelque chose.

Après près de 1,5 an à l'élaboration d'un pas si énorme GWT application, à l'aide de toutes les meilleures pratiques que j'ai appris de la dernière Google I/O comme MVP, EventBus, CommandPattern, etc. Je dis cela du fond de mon cœur: après avoir passé des jours à essayer d'obtenir les choses fonctionnent de la façon dont mon équipe et le client voulait à la fois techniquement et visuellement, même après la sortie de UiBinder, Vaadin m'est venu comme une lumière au bout du tunnel.

Après avoir écrit près d'un millier de passe-partout actions pour le modèle de commande, un autre millier de présentateurs et de points de vue et un autre millier de gestionnaires d'événements, etc.. pour ne Pas avoir à traiter avec près de 75% de ces classes et encore le maintien d'un bon modèle de l'approche (appfoundation add-on), un peu de surcharge du réseau est acceptable. Avec Vaadin, out-of-the-box, vous obtenez de bons widgets, la pagination, la liaison de données, le layouting sans faille. Tout cela pour quoi? Certains plus de consommation de mémoire dans le serveur-côté.

Je crois que je peux dire c'est acceptable parce que je ne suis pas la construction du prochain Facebook ou quelque chose. Je suis encore capable de gérer des milliers d'utilisateurs simultanés par support de serveur et pourtant, le maintien de faibles temps de latence aller-retours.

Avec Vaadin, je peux construire une application agréable, avec près de la moitié des lignes de code et encore, l'application semble plus complète. :-)

!! Mise à JOUR le 23 février 2011: je ne peux pas insister sur la façon dont on doit être conscient de chaque cadre de ses limites. Vaadin est pas différent. Il faut être conscient que Vaadin abstraction de toute forme de code html ou javascript. Aussi, le HTML résultant est veeeery lourd et vous devez prendre soin de l'histoire de l'état des modifications vous-même. Donc, être conscient de ces frais généraux lorsque vous générez votre projet.

Marcos Alcantara

Answer 3

Avertissement: je ne suis affilié à aucun des bibliothèques mentionnés ci-après (mais sais mon chemin autour d'eux assez bien.

Comme vous, je suis tombé sur ce post lors de la réflexion qui pile/cadre à utiliser pour un nouveau projet. J'ai eu une solide expérience avec le Jeu! (ok, en Scala, mais ce n'est pas pertinente ici), mais le poids des widgets et leur intégration transparente avec le côté serveur + le Swing comme le développement a piqué mon intérêt. C'était à la fin de 2010, et que les réponses m'a convaincu de faire Vaadin un essai, j'ai décidé de revenir et écrire la réponse que j'aurais aimé lire ici, esp. comme la question est toujours d'actualité aujourd'hui. Pendant ce temps, Vaadin est allé à partir de la version 6 à 7 avec quelques améliorations notables qui ont été nécessaires, Jouer! est passé de la version 1 à la 2 et I (+ une petite équipe) a réalisé un petit nombre de projets couronnés de succès avec les deux cadres.

Je pense que la comparaison est intéressante parce que les deux cadres

1. exécution de la JVM et de tirer parti de ses abondantes de l'écosystème
2. ne pouvait pas être plus en désaccord dans leur approche pour les applications web et ce que vous, en tant que développeur faut s'en préoccuper, et
3. dans une moindre mesure, la façon dont ils se rapportent à Java EE.

Louange

En une phrase, si vous trouvez l'idée du portage d'une application de bureau à un navigateur tout en étant complètement abstraction de la base de la requête HTTP/mécanisme de réponse convaincante, alors Vaadin est probablement ce que votre candidat pour faire des applications web. Son Swing comme approche pour la programmation peut être un jeu d'enfant pour ceux qui sont plus heureux loin de la basse-levelness de HTML et de JavaScript. Une nouvelle demande de votre application est en effet le démarrage d'une nouvelle instance et le reste de l'écoulement est à vous et à votre logique. Liens revenir à la bonne vieille de boutons pour la navigation et vous êtes libre de composer vos mises en page à l'aide des nombreux modèles intégrés sans jamais être nécessaire de modifier le HTML ou le CSS. L'API est généralement tout à fait cohérente et, certes, bien documenté (le Livre de Vaadin est obligatoire de lire. Le faire à fond, comme beaucoup de choses sont facilement disponibles, par exemple. la liaison de vos haricots pour les composants et les validateurs, ...). Les widgets ont une bonne compatibilité inter-navigateur, assurant ainsi la cohérence du comportement de votre application sur un large éventail de clients.

Vérification de la réalité

Nous avons eu un bon temps à développer et tester nos Vaadin apps. Les choses sont devenues plus claires et plus nuancée quand nous avons lancé la première version et a commencé à recueillir des commentaires. Nous avons réalisé que nous avions effectivement un parti pris assez de points essentiels, à savoir:

1. En 201x, la plupart des utilisateurs ont une longue histoire de l'utilisation du web, et peu d'entre eux en fait guère usage des applications de bureau. Le point clé ici est que les navigateurs normalisé le UX de l'interaction avec des liens hypertexte, un arrière, un avant et un bouton de rechargement, omniprésent onglets et parfois des fenêtres, et l'idée de base que la plupart des actions de déclencher une requête HTTP et attend une réponse. C'est le contrat implicite que les sites web se conformer à et autour de laquelle ils sont construits. Par conséquent, nous ne devrions pas être surpris lorsque les utilisateurs se sont plaints qu'ils ne pouvaient pas utiliser les boutons précédent et suivant qu'ils ont été utilisés pour, ou que les onglets ne fonctionnent pas de la manière prévue. Et nous sommes convenus. Nous avons cassé l'invisible contrat liant les utilisateurs et les navigateurs. En fait, nous étions nous-mêmes implicitement ne pas utiliser notre navigateur avec le Vaadin application de la façon dont nous avons utilisé avec n'importe quel autre site web. Bien sûr, vous pouvez revenir en arrière à ce livre et de le lire attentivement sur la réplication d'une expérience de navigation web avec l'URL de fragments, et vous verrez que c'est en fait plus compliqué que prévu car Vaadin applications sont dynamiques. En outre, le MVC ou MVP paradigmes ne sont que légèrement imposé sur le développeur, en revanche pour Jouer! où il n'y a pratiquement pas d'autre option. Ne prenez pas cela à la légère, mais votre cerveau est utilisé pour le blanc lumineux de l'écran affiché pendant une fraction de seconde à la suite d'un changement de page. Lorsque les utilisateurs cliquent sur et s'attendre à être pris une nouvelle page, le navigateur reconnaît en montrant le sablier (ou une de ses variantes). Avec l'AJAX, les demandes sont placés derrière les coulisses. Il y a aujourd'hui des lieux où la de petites, presque chirurgicale AJAX grèves sont devenues la norme, mais pas pour les grands de l'INTERFACE utilisateur mise à jour.

2. Dynamique des applications apportent leur lot de défis... et les ennuis. L'équilibrage de la charge (si vous êtes concerné) pour l'un est plus compliqué. La notion de transaction est tout à fait différente que Vaadin sessions couvrent de nombreuses demandes et sont, par conséquent, de long en contraste avec RESTE approche, mais relativement de courte durée, en termes de UX. En effet, il n'est pas rare pour les utilisateurs de revenir à une forme qu'ils ont commencé il y a quelques heures pour terminer leur tâche. Cela pourrait, en théorie, le travail avec Vaadin trop, mais vous auriez à garder les sessions en vie pour un long, long temps avec la mémoire bloqué tout le temps et réfléchissez bien à bien ce serait échelle w.r.t. utilisateurs simultanés.

   Stateful pages sont également plus difficile pour les utilisateurs à partager, laissez seul signet (en supposant que vous avez fait affaire avec l'URL de fragments).

3. Enfin, nous partageons l'impression que l'INTERFACE utilisateur est généralement plus lent que la logique étant sur le serveur. Bien sûr, vous pouvez toujours créer un widget chargé avec du JavaScript côté client pour diminuer le nombre d'aller-retours, mais vous devrez inévitablement à faire quelques mises à jour de l'INTERFACE utilisateur sur le serveur. Le JS est déjà assez lourd à interpréter dans mon expérience, et fait d'une moindre expérience sur des appareils mobiles (je suis au courant de TouchKit, mais encore: les applications HTML5 sur des appareils mobiles n'est pas suffisant pour moi). Aussi, gardez à l'esprit que le thread d'INTERFACE utilisateur est actif après une demande est publiée (ie. action de l'utilisateur sur le côté client, semblable à tirer de l'INTERFACE utilisateur des mises à jour) et sera accessible par le biais de différents auditeurs. Toutefois, la mise à jour de l'INTERFACE utilisateur de threads d'arrière-plan est plus compliqué (par exemple. pousser les mises à jour). Vaadin 7 amélioration de la situation à cet égard, et en particulier avec relativement plus léger du code HTML généré. D'importantes améliorations à l'INTERFACE utilisateur de réactivité ont été perceptibles en tournant simplement sur la compression HTTP.

Conclusion

Donc, nous avons fait une pause et je me demandais ce que nous avons trouvé intéressant dans le Vaadin approche pour commencer. Le développement initial avait été relativement douceur de roulement en produisant des résultats rapides, mais à retravailler quelques concepts pour accueillir web UX attentes nous a donné une forte impression de nager à contre-courant. Nous avons conclu que le séduisant les idée d'être absorbées (obscurci?) à partir de la requête/réponse HTTP mécanisme a donné une épée à double tranchant qui a dévoilé la véritable différence d'impédance entre les applications web et les applications de bureau.

Au lieu de faire semblant de croire que le web est encore une autre couche, nous avons fortement ressenti que l'on doit embrasser la façon dont il fonctionne et cela commence avec le fait d'avoir une URL centrée sur l'application (comme imposé par les Rails/Django/Jouer). Vous avez probablement entendu quelqu'un dire que les données survit à l'application. Aujourd'hui, les données sont visés par l'URL de ressources, donc on peut dire que les Url survivre données. Donc de base de la séparation des préoccupations devraient s'appliquer également à ce niveau. C'est sans doute pourquoi le web est devenu si populaire en premier lieu. Donc, nous avons revisité notre application à la structure plus autour d'un contrôleur de répondre à des actions à la Jouer fait sur des ressources, des chemins d'accès.

Pour l'instant, nous gardons notre Vaadin des applications, mais en raison de certaines de ces contraintes et le changement fondamental de paradigme nous ne serons pas en commencer de nouveaux projets. Toutefois chapeau à l'équipe qui a construit techniquement cohérent, uniforme et bien documenté 360° framework Java pour le web ne nécessitant que très peu de connaissances sur le web rouages. Sur l'envers, ils ont même leur cadre avec une société qui vend des services de consultation. Je suis reconnaissant pour l'expérience et pour la façon dont il m'a fait réévaluer mon point de vue sur des applications web. Je vais surveiller de près son évolution, mais nous avons certainement besoin de plus de contrôle et de granularité.

J'espère qu'un jour Vaadin permettra de libérer de lui-même à partir de l'ensemble de la Servlet de l'architecture sur laquelle elle s'appuie pour avoir son propre serveur HTTP. Le mieux serait un MVC conception plus profondément enracinés dans le cadre. Mais c'est peu probable dans un avenir prévisible, puisqu'il semble avoir trouvé une niche lucrative parmi assaisonné d'entreprise Java gorilles qui ne jure que par EE. Briller sur.

TL;DR: je pense que Vaadin manque le point de ce que les webapps sont et, plus important encore, comment ils devraient se comporter. Il est temps que les programmeurs ont embrassé le web et la façon dont les utilisateurs interagissent avec elle (c'est à dire. bouton précédent, bouton de rechargement, des onglets et des favoris). Le plus proche d'une application web de bâtons pour les requêtes HTTP et de verbes, plus il est susceptible de correspondre aux attentes de l'utilisateur.

Answer 4

L'habitude de parler de Vaadin concerne le widget et les inquiétudes concernant l'aller-retour de la communication entre le client et le serveur.

Mais à mon avis ce surplombe la plus importante (peut-être révolutionnaire) aspect de Vaadin: il élimine complètement la tâche de la conception et de la mise en œuvre de la communication client-serveur qui est généralement requis pour les applications AJAX (le "A" et "X" en AJAX).

Avec Vaadin, vous pouvez oublier complètement DTO (objets de transfert de données), basé sur un protocole de problèmes de sécurité, Hibernate chargement différé des exceptions, etc.

Vous êtes dans un certain sens, le simple fait d'écrire régulièrement old Java Swing application de bureau, que vous vous en utilisez un autre UI toolkit de Swing.

Answer 5

De mon expérience, GWT nécessite beaucoup de code réutilisable et lent lors de la construction de complecated et INTERFACE utilisateur riche. D'habitude nous avons affaire avec assez complexe de l'application des modèles qui détient de nombreux permanent des objets du domaine. Pour ramener toutes ces données de client, vous aurez besoin d'introduire de client, de modèle et de fournir des données mécanisme de conversion. Nous avons utilisé des Bulldozers pour cela et il prend beaucoup de temps à la carte chaque déposée, créer des convertisseurs et de tester tout ça.

D'autre part, si ne pas tomber dans overengineering et si l'application n'est pas très compliqué, vous pouvez prendre un avantage de l'utilisation de ressources du client et ont moins de charge sur le serveur. De cette façon, vous pouvez réduire considérablement la communication avec le serveur et d'obtenir beaucoup plus réactif logiciel.

Vadin semble très développeur frinedly :) Mais j'ai un peu peur de "massive AJAX d'attaque" pour le serveur. J'ai de l'expérience dans ZK, et souvent nous avons été confrontés à des problèmes de performance lors d'une opération triviale sur l'INTERFACE fonctionne lent, car il nécessite de la communication avec le serveur.

Wicket est un autre bon cadre, mais il est plus adapté pour les sites web. Il peut fonctionner avec ou sans AJAX, peut être indexé par les moteurs de recherche. Et la chose la plus intéressante qu'il traite de nettoyer le code HTML - pas de balises personnalisées, pas de structures de contrôle, la stricte séparation des préoccupations et seuls les wicketid namigs pour les composants.

Il dépend essentiellement de vos besoins:

1. Si vous avez besoin de super simple et rapide d'application - utilisation de GWT et d'utiliser les ressources du client
2. Si votre application est assez complexe que Vaadin semble être la meilleure option
3. Si votre demande est publique et vous avez besoin d'une capacité d'index pour le RÉFÉRENCEMENT que choisi de Guichet.