Différence entre Apache Tapestry et Apache Wicket

StackOverflow https://stackoverflow.com/questions/657352

Question

Apache Wicket ( http://wicket.apache.org/ ) et Apache Tapestry ( http://wicket.apache.org/ ) sont un cadre Web orienté composants - contraire aux frameworks basés sur l’action comme Stripes - de 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, dans quelle mesure la gestion des états peut-elle être personnalisée? Peut-on les utiliser 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?

Modifier : 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.

Était-ce utile?

La solution

Quelques différences pertinentes telles que je les vois:

  • Tapestry utilise une page semi-statique structure, où vous pouvez travailler avec conditionnels et boucles à réaliser comportement dynamique. Wicket est complètement dynamique; vous pouvez charger composants dynamiquement, les remplacer à l'exécution, etc. Les conséquences de ce sont que Tapestry est plus facile à optimiser, et que Wicket est plus souple dans son utilisation.
  • Les deux cadres sont à peu près aussi efficaces dans l'exécution, mais Wicket s'appuie sur stockage côté serveur (par défaut, le page en cours et passée pages dans un 'cache de second niveau' qui est un fichier temporaire par défaut dans le fichier système). Si cela vous dérange, pensez à propos de combien de sessions simultanées vous vous attendez à avoir aux heures de pointe et calculer avec environ ~ 100 Ko par session (ce qui est probablement du bon côté). Cela signifie que vous pouvez courir à peu près soutenir 20k sessions simultanées pour 2 Go. Dis 15k parce que tu as besoin de ça mémoire pour d'autres choses aussi. De Bien sûr, un inconvénient de stocker l'état est que ça ne fonctionnera que bien avec affinité de session, donc c'est un limitation lors de l'utilisation de Wicket. le cadre vous fournit un moyen mettre en œuvre des pages sans état, mais si vous développez pleinement apatride applications que vous pourriez 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, ce qui est également bon pour la maintenance. Quelque chose à dire à la fois à 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.

Autres conseils

RÉVISÉ après avoir étudié Tapestry 5.

L'objectif de Wicket est de tenter de développer un développement Web similaire à l'interface graphique de bureau . Ils ont très bien réussi à le faire aux dépens de l’utilisation de la mémoire (HTTPSession).

L'objectif de Tapestry 5 est de rendre très optimisé (pour le processeur et la mémoire) . Un framework Web orienté composants.

Le piège vraiment énorme pour moi était les réponses "Wicket prend en charge le composant sans état!" aux arguments "Wicket a faim de mémoire". Bien que Wicket prenne effectivement en charge les composants sans état, ils ne constituent pas "un objectif 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 utilisant 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 recharge automatiquement les classes de composants dès que vous les modifiez. Les deux frameworks rechargent le balisage des composants.
  • Wicket force la séparation des balises et des codes , Tapestry 5 vous donne simplement cette possibilité. 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, le didacticiel sur Tapestry 5 ne souligne pas que l'exemple de code Tapestry comme 't : loop source = "1..10" ... peut ê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 lorsque vous avez besoin d'une utilisation plus efficace des ressources

Je pense que Wicket est un cadre 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 pouvoir changer 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 /

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 spring dans vos classes.

Essayez http://incubator.apache.org/click/ . C'est un framework web java incroyable. Certaines personnes l'appellent & # 8220; Wicket made right & # 8221; ; -)

Comme je le disais quand la version 4.1 était la version officielle stable:

Avant de s’engager à l’utiliser, vous devriez jeter un coup d’œil sur l’historique de 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 le plus rapidement possible; maintenez vous-même des versions stables.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top