Wicket vs Tapestry

[Fats]

Hallo miteinander!

Ich stehe gerade vor der Entscheidung, tapestry oder wicket als Framework zu verwenden. Ich hab schon das eine oder andere quergelesen, aber mir fehlt trotzdem noch so der globale Durchblick. Habt ihr beide schonmal im Vergleich gehabt?

Beide sind eventbasiert, ok. Tapsestry soll angeblich performanter sein. Sprechen wir von Porsche und Ferrari, oder von Porsche und Tretroller? Die Doku scheint bei beiden mittel bis gut vorhanden zu sein. Auch eine größere Community ist beiden eigen. Das klingt erstmal ganz gut.

Edit: Wie sieht es aus mit den Lernkurven beider Systeme? Ich möchte eigentlich nicht erst wochenlang im Kämmerlein basteln, bevor ich ein System verwenden kann? Und wie ist der Ressourcenhunger? Braucht man schon als Basis tonnenweise GB-Module im Server oder reichen da ein oder zwei GBytes?

Was gibt es sonst noch für Unterschiede? Eignet sich das eine besser für dies oder jenes als das andere? Oder ist es die Frage nach Schoko oder Vanille? ;-)

Viele Grüße
Fats

 

[Java.getSkill()]

ich kann nur für mich sprechen: ein selbstläufer ist Tapestry nicht. Zwar mächtig, aber eher ein "exklusiver" club. Sehr firmenlastig und imho für grössere Projekte ausgelegt.

0 plan über wicket.

Was möchtest du denn eigentlich entwickeln?

 

[Fats]

Was möchtest du denn eigentlich entwickeln?

Tja, gute Frage! Hängt etwas davon ab, was an mich herangetragen wird. Das beginnt bei der kleinen Webseite für "Tante Erna" mit ein paar dynamischen Features, geht über eine Webseite mit Mini-CMS im Hintergrund, kann aber auch ein kleines Portal sein, bei dem man sich registrieren, einloggen und ein Profil erstellen kann.

Ein Bankensystem werd ich wohl eher nicht aufsetzen

Viele Grüße
Fats

 

[number8]

Soweit ich weiß, wurde Wicket von Tapestry3 inspiriert.... egal.
Sonst kann ich nur sagen, daß wir einen Prototypen in sowohl Wicket als auch Tapestry implementiert hatten. Freilich alles subjektiv, aber der TapestryCode war für alle Beteiligten am besten lesbar. Die Performancezahlen weiß ich leider nicht mehr, aber sowohl bei einem, 10 und 100 Requests "gleichzeitig" lag Tap5 vorne. Das Live-Class Reloading ist außerdem ein enormer Produktivitätsgewinn.

 

[Deadalus]

Warum nicht JSF 2.0 mit einer Library wie PrimeFaces? PrimeFaces
Komponenten mit einer ähnlichen Komplexität suchst du bei Wicket oder Tapestry vergebens.

JSF 2.0 ist leicht zu lernen und hat durch den Standard eine gute Verbreitung. Als Server kann ich dir dazu Glassfish 3 empfehlen.

 

[Fats]

Tja, warum nicht JSF? Die Komponenten der PrimeFaces sehen wirklich verdammt gut aus!!! Ich hab JSF vor 2 Jahren mal ausprobiert und war ganz unglücklich. Ich hatte die Icefaces in den Fingern und irgendwie war alles ein endloser Krampf. Alleine das ewige Konfigurieren der faces.config nervte. Ein Haufen Fehlermöglichkeiten, etc. Was ich bis jetzt gelesen habe, so gehen Wicket und Tapestry etwas andere Wege und sollen angeblich einfacher zu handhaben sein und eine kürzere Einarbeitungszeit haben als JSF. Daher die Frage nach Wicket und Tapestry.

Fats

 

[Deadalus]

Also falls du dich eh am umschauen bist würde ich dir durchaus zu einem 2. Blick auf JSF raten.

Bei JSF 2.0 wird übrigens keine faces.config mehr benötigt. Managed Beans können komplett mit Annotations verwaltet werden.
JSP's wurden durch Facelets ersetzt, die zum einen durch die XHTML Struktur und zum anderen durch den Template Ansatz die Entwicklung der Webseiten erheblich verbessert.
Der größte Vorteil sind für mich aber klar die frei verfügbaren Komponentenbibliotheken.

 

[number8]

Das Schreiben eigener Komponenten macht in Tap5 richtig Spaß und geht sehr schnell (ein wenig Kenntnis über die Renderphasen und schon gehts los). Ein tolles Feature sind außerdem die Mixins.

Mittlerweile gibt es einige Bibliotheken mit zusätzlichen Komponenten oder Bbliotheken die Freemarker unterstützen oder auch HTML cachen usw.

 

[a11158]

Also ich würde Dir Wicket empfehlen. Es bietet die meiste Flexibilität und ist
so strukturiert, wie man sich das wünscht.
Tapestry ist da eher weniger intuitiv aber auch leistungsfähig.
Beide eignen sich auch für große und sehr komplexe Anwendungen.
Vergleich:
Tapestry and Wicket compared

 

[pobv]

Vergleich:
Tapestry and Wicket compared

der Artikel ist zu alt:

Given the unsettled status of V5.0, we will focus on V4.1.

nach Version 4.x hätten sie das Framework auch umbennen können

 

[megachucky]

Freilich alles subjektiv, aber der TapestryCode war für alle Beteiligten am besten lesbar.

Sehe ich genauso. Bei Wicket ist der Code (meiner Meinung nach) einfach schwerer verständlich durch die inneren Klassen und die Swing-ähnliche Programmierung. Tapestry 5 verwendet Annotations - ich finde das viel übersichtlicher.

Kritikpunkt an Tapestry 5 ist eben, dass es nicht rückwärtskompatibel ist. Das kommt vermutlich - oder besser hoffentlich - nicht nocheinmal vor bei der nächsten Version.

Also nur Wicket und Tapestry zu betrachten ist leider nicht ausreichend. Es hängt aber eben auch davon ab, was du machen möchtest. Wenn du das noch nicht weisst, und einfach mal irgend eines lernen möchtest, dann würde ich das am weitesten verbreitetste nehmen, und das ist vermutlich JSF...

Ich würde aber auch dringend raten, JSF 2.0 zu evaluieren. Durch viele Vereinfachungen / Erweiterungen ist es mit JSF 1.2 nicht mehr zu vergleichen. Hier nenne ich jetzt mal nur als Beispiele ebenfalls Annotations und dass die Navigation nun nur noch optional in XML-Dateien konfiguriert wird. Außerdem ist es ein Standard (ja ja ich weiss...) und deswegen am weitesten verbreitet, inkl. vielen "Addons" wie ICEFaces, PrimeFaces usw.
Wenn du z.B. einen RichClient erstellen willst, kannst du mit CaptainCasa JSF-Anwendungen erstellen ohne überhaupt etwas über den JSF-Lifecylce zu wissen. Du kümmerst dich hier um die GUI und die ManagedBeans, den Lifecycle übernimmt das auf JSF aufbauende Framework.

Auch GWT sollte beachtet werden: AJAX-Webanwendungen nur mit Java zu progammieren und eine GUI mit guter Usability (da alles beim Start auf den Client geladen wird) sind sicher auch nicht schlecht. Gerade bei kleinen "Tante-Emma-Anwendungen" ist GWT sicher gut und mit geringer Einarbeitungszeit geeignet.

Für optisch ansprechende Anwendungen (Animations etc.) kommt man an RIA-Frameworks kaum vorbei, hierfür muss man dann aber eben eine zusätzliche Sprache lernen (wobei man bei den oben genannten bis auf GWT ja auch gute zusätzliche Kenntnisse in HTML etc. benötigt) - z.B. JavaFX (am nähesten zu Java), Flex oder Silverlight.
Mit der Zeit sind auch die Adobe- und M$-Produkt immer besser in Java-Backends integrierbar und dafür schon viel reifer (bezüglich Features, Tool-Support) als JavaFX.

Und falls du nur einfache CRUD-Webanwendungen bauen möchtest, wäre alles andere als ein CRUD-Framework (im Java-Bereich z.B. das ROMA Meta Framework) eine fatale Fehlentscheidung, da du damit locker 80 Prozent des Aufwands sparen kannst.