Différence entre Apache Tapestry et Apache Wicket
Apache Wicket ( http://wicket.Apache.org/ ) et Apache Tapestry ( http://wicket.Apache.org/ ) sont les deux frameworks Web orientés composants s - contrairement aux frameworks basés sur l'action comme Stripes - par la Fondation Apache. Les deux vous permettent de construire votre application à partir de composants Java. _ {Ils me ressemblent beaucoup tous les deux}.
Quelles sont les différences entre ces deux cadres? Est-ce que quelqu'un a de l'expérience dans les deux? Plus précisément:
- Quelles sont leurs performances, à quel point la gestion des états peut-elle être personnalisée, peuvent-ils être utilisés sans état?
- Quelle est la différence dans leur modèle de composant?
- Que choisiriez-vous pour quelles applications?
- Comment s’intègrent-ils avec Guice, Spring, JSR 299?
Edit : J'ai lu la documentation des deux et j'ai utilisé les deux. Vous ne pouvez pas répondre suffisamment aux questions à la lecture de la documentation, mais à l’expérience de leur utilisation pendant un certain temps, par exemple, comment utiliser Wicket en mode sans état pour les sites hautes performances. Merci.
Quelques différences pertinentes telles que je les vois:
- Tapestry utilise une structure de page Semi-statique, dans laquelle vous pouvez utiliser des conditions Et des boucles pour obtenir un comportement dynamique . Wicket est Complètement dynamique; vous pouvez charger de manière dynamique, les remplacer à l'exécution, etc. Les conséquences de sont que Tapestry est plus facile à optimiser. et que Wicket est plus performant. flexible dans son utilisation.
- Les deux frameworks Sont à peu près aussi efficaces en exécution , Mais Wicket s’appuie sur Le stockage côté serveur (par défaut, la page courante De la session et après pages dans un «cache de second niveau» qui est par défaut un fichier temporaire dans le système de fichiers ). Si cela vous dérange, pensez Au nombre de sessions simultanées Que vous attendez aux heures de pointe et Calculez avec, disons, environ 100 Ko par session (Ce qui est probablement sur le dessus). Cela signifie que vous pouvez exécuter environ prendre en charge 20k sessions simultanées pour 2GB. Dites 15k parce que vous avez besoin de cette mémoire pour d'autres choses également. Bien entendu, l’inconvénient de stocker Est qu’il ne fonctionnera bien que Avec une affinité de session, ce qui limite donc Lors de l’utilisation de Wicket. Le cadre Vous donne le moyen De mettre en œuvre des pages sans état, mais si Vous développez des applications Totalement apatrides, vous pouvez envisager un cadre différent.
- L'objectif de Wicket est de prendre en charge le typage statique au maximum, tandis que Tapestry consiste davantage à enregistrer des lignes de code. Donc, avec Tapestry, votre base de code est probablement plus petite, ce qui est bon pour la maintenance, et avec Wicket, vous êtes beaucoup typé de manière statique, ce qui facilite la navigation avec un IDE et la vérification avec un compilateur, qui est également bon pour la maintenance. Quelque chose à dire pour les deux à mon humble avis.
J'ai lu à quelques reprises maintenant que les gens pensent que Wicket fonctionne beaucoup par héritage. Je tiens à souligner que vous avez le choix. Il existe une hiérarchie de composants, mais Wicket prend également en charge la composition bien que des constructions telles que IBehavior (au-dessus desquelles le support Ajax de Wicket est construit). En plus de cela, vous avez des choses comme les convertisseurs et les validateurs, que vous ajoutez aux composants, globalement, ou même comme une préoccupation transversale en utilisant certains des écouteurs de phase fournis par Wicket.
RÉVISÉaprès avoir étudié Tapestry 5.
Le but de Wicket est une tentative visant à rendre un développement Web similaire à l'interface graphique de bureau one. Ils ont très bien réussi à le faire aux dépens de l'utilisation de la mémoire (HTTPSession).
Le but de Tapestry 5 est de rendre très optimisé (pour le processeur et la mémoire) framework web orienté composant.
Le très gros écueil pour moi était les réponses "Wicket supporte le composant sans état!" aux arguments "Wicket a besoin de mémoire". Bien que Wicket prenne effectivement en charge les composants sans état, ils ne constituent pas "un élément central du développement de Wicket". Par exemple, un bogue dans StatelessForm n'a pas été corrigé depuis très longtemps - voir StatelessForm - problème avec les paramètres après l'échec de la validation }.
- IMHO using Wicket est un peu plus rapide jusqu'à ce que vous optimisiez/ajustiez les paramètres de l'application web
- IMHO Wicket est plus difficile à étudier si vous avez programmé des applications Web et souhaitez penser en termes de traitement des demandes
- Tapestry 5 automatiquement recharge les classes de composants dès que vous les modifiez. Les deux cadres rechargent le balisage des composants.
- Forces de guichet séparation du code/, Tapestry 5 vous donne juste cette capacité. Vous pouvez également utiliser une syntaxe moins verbeuse dans Tapestry 5. Comme toujours, cette liberté nécessite davantage de précautions.
- Le noyau de Wicket est plus facile à déboguer: les composants utilisateur sont basés sur l'héritage, tandis que les composants utilisateur de Tapestry 5 sont basés sur des annotations. De l’autre côté, cela pourrait faciliter les transitions vers les versions futures pour Tapestry puis pour Wicket.
Malheureusement, tutoriel sur Tapestry 5 } ne souligne pas que l'exemple de code Tapestry tel que 't: loop source = "1..10" ...' puisse être une mauvaise pratique. Il faut donc s’efforcer d’écrire les conventions/bonnes pratiques d’utilisation de Tapestry si votre équipe n’est pas très petite.
Mes recommandations :
- Utilisez Wicket lorsque la structure de vos pages est très dynamique et que vous pouvez vous permettre de dépenser 10 à 200 Ko de mémoire HttpSession par utilisateur (il s’agit de chiffres approximatifs).
- Utilisez Tapestry 5 dans les cas où vous avez besoin d'une utilisation plus efficace des ressources.
Voici une comparaison assez complète de Developer Works d'IBM.
http://www.ibm.com/developerworks/Java/library/os-tapestrywicket/index.html?ca=drs
Mise à jour: le lien est mort, mais vous pouvez trouver la page sur http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/Java/library/os-tapestrywicket/index .html? ca = drs
Je pense que Wicket est un framework plus simple à utiliser.
De plus, Wicket permet le rechargement de classe via le système de remplacement par code à chaud de votre IDE. C'est tout ce qui est requis pour que Wicket puisse exécuter des versions modifiées des classes d'une application en cours d'exécution. Les restrictions habituelles s'appliquent au remplacement de code à chaud, telles que devoir s'exécuter en mode débogage (Eclipse) et ne pas être en mesure de modifier les aspects structurels d'une classe (c'est-à-dire le nom de la classe, la modification des signatures de méthode, etc.).
Je n'aime pas le modèle de programmation Tapestry et je connais de nombreux développeurs qui quittent Tapestry à cause de trop de changements et d'incompatibilités de développement. Voir: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
Essayez http://incubator.Apache.org/click/ . C'est un framework Web Java étonnant. Certains l'appellent «Wicket made right» ;-)
Wicket est un très bon framework web. Le meilleur de tout ce que je sais. Je l'utilise depuis la version 1.3 et j'obtiens toujours ce que je veux. Wicket possède une excellente intégration avec Spring - utilisez simplement l'annotation @SpringBean dans votre code pour injecter n'importe quel bean printanier dans vos classes.
Comme je l'ai dit quand 4.1 était la version stable officielle:
Avant de vous engager, vous devriez jeter un coup d’œil sur l’historique du développement de Tapestry. Tapestry a effectué de nombreuses mises à niveau non compatibles sans poursuivre la prise en charge des versions antérieures. Les correctifs de la version 4.1 ne sont plus traités dans un délai raisonnable. À mon avis, cela n’est pas acceptable pour la version officielle stable.
S'engager à utiliser Tapestry 5 signifie:
vous devriez devenir un committer; vous devez suivre tous les nouveaux développements, abandonner les anciennes versions aussi rapidement que possible; conserver vous-même des versions stables.