Java Server Faces 2.0 oder Tapestry 5.2? [geschlossen]

Nehmen Sie Ihr Angebot auf und schlagen Sie ein anderes Framework vor:

Wenn Sie eine wirklich schnelle Entwicklung wünschen, sollten Sie sich das Play Framework ansehen.

Ich habe JSF / Richfaces / Seam / Hibernate usw. benutzt und ich würde sagen, dass Play mehr als doppelt so produktiv ist. Es gibt keine Bereitstellungszyklen. Also keine Entwicklerausfallzeiten. Es hat JPA / Hibernate eingebrannt und viele Plugins, die seine Funktionalität in andere Richtungen erweitern.

Ich mag auch die Tatsache, dass es Ihre Seiten so leicht macht. Mein größtes Problem mit JSF war immer das Gewicht der Seiten (unnötige IDs, viele Tabellen, Client-Status usw.)

Nehmen Sie sich Zeit und sehen Sie sich den Webcast an.

Ich habe in den letzten Jahren hauptsächlich mit Tapestry 5 gearbeitet. Ich werde jedoch nicht evangelisieren. Die Wahl eines guten Web-Frameworks ist sicherlich eine gute Idee, aber normalerweise nicht Ihr Hauptproblem.

Eine Liste von guten und schlechten Dingen aus dem Kopf:

• Tapestry 5 hat eine ziemlich steile anfängliche Lernkurve. Überall gibt es Magie und Metaprogrammierung. Man könnte argumentieren, dass die Konvention gegenüber der Konfiguration übertrieben ist.

• Einfaches Zeug ist sehr einfach zu machen, härteres Zeug erfordert, dass Sie im Detail verstehen, wie Tapestry 5 funktioniert, und es kann schwierig sein, wenn Sie es (noch) nicht tun.

• Ich liebe das Nachladen der Live-Klasse. Sie ändern etwas in einer T5-Komponente oder Vorlage und Sie sehen es sofort. Wirklich nützlich, wenn Ihre App viele Sachen macht und 30+ in Jetty startet.

• Tapestry unterstützt keine dynamischen Seitenstrukturen. Dies ist normalerweise kein Problem, aber wenn Sie eine Art von Portallösung entwickeln, bei der Benutzer Komponenten individuell anordnen können, verwenden Sie Tapestry nicht. Tapestry ist für statische Strukturen, die es wirklich gut verarbeitet.

• Tapestry hat schöne URLs. package/page/${param1}/${param2} ...

• Tapestry verwendet die richtigen HTTP-Verben, um Dinge zu tun. Ein Link ist ein GET, ein Formular ist ein POST, das post-redirect-get-Muster ist die Norm.

• Die Community von Tapestry ist nicht sehr groß. Abgesehen von Howard Lewis Ship, gibt es ein paar andere Committer, aber nichts wie die Unterstützung, die Wicket hat. Tapestry entwickelt sich daher eher langsam.

• Tapestrys Ansatz beim Templating (HTML mit Typen und IDs instrumentieren) ist einer der besseren, die ich gesehen habe, aber es geht nicht so weit, wie Wicket Code aus dem HTML heraushält. Auf der anderen Seite sind die Klassendateien weniger ausführlich. Trotzdem denke ich, dass der Wicket-Weg vorzuziehen ist.

• Tapestry ist etwas zu wenig dokumentiert.

Ich mag Tapestry sehr, ich denke, dass du damit sehr produktiv sein kannst, und ich würde immer gerne an Projekten teilnehmen, wo es verwendet wird.

Ich würde jedoch empfehlen, auch Wicket zu überprüfen. Es scheint mehr Zugkraft gewonnen zu haben als Tapestry und löst einige Probleme weniger magisch, aber mit einem gesunden Menschenverstand.

(Ich habe JSF 1 nur kurz verwendet, was ich bei fast allem, was es getan hat, komplett ausgeschaltet hatte: jede Anfrage in einem POST zu verpacken (also grundlegende Web-Funktionalität zu brechen), JSPs zu verwenden, aber spezielle Tags für alles, sogar reines HTML ... Ich lese viel im JSF Camp verbessert, aber ich kann es nicht sagen, ich habe es nie wieder angeschaut.)

Sehen Sie sich meine Präsentation JSF 2.0 vs. Tapestry an 5: Ein Kopf-an-Kopf-Vergleich bei Jazoon 2010. Dies könnte Ihnen helfen, Ihre Entscheidung zu treffen.

Als Tapestry-Committer würde ich dir raten, Tapestry zu wählen, aber ich denke, der beste Weg, das Decison zu machen, ist, beides zu versuchen. Benötigen Sie mehr Demo-Anwendungen?

Ссылка

Wichtigstes Merkmal von Tapestry 5 ist für mich die Flexibilität des Frameworks. Dank Tapestry IoC können Sie fast jeden Code innerhalb des Tapestry-Kerns überschreiben.

Sieh mich nicht nach einer unvoreingenommenen Meinung ... Tapestry ist seit einigen Jahren mein Leben und ich liebe es weiterhin.

Das heißt, die Lernkurve wird weniger steil, die Dokumentation verbessert sich schnell und Igors Buch ist gleich um die Ecke.

Einige der Dinge, die die Leute verwirren, sind einfach fehlende Dokumentation; Zum Beispiel sind die Namenskonventionen optional, es gibt immer explizitere Konfigurationen (in Form von Methodenanmerkungen), mit denen einige Leute vertrauter sind.

Um ein paar Henning-Punkte anzusprechen:

Tapestry-Komponentenvorlagen sind von Grund auf statisch (und dies ist sehr wichtig für Tapestry's Skalierbarkeits- und Clusterfähigkeitsgeschichte). Ein Add-on, das Teil meiner TapX-Bibliothek ist, unterstützt dynamische externe Vorlagen, die die Lücke füllen.

Auch wenn Sie Ihre Vorlagen maximal frei haben wollen, können Sie das auch tun, zB:

& lt; form t: id="myForm" & gt;

... in der Vorlage, mit dem Rest in der Java-Klasse:

@Component (Parameter = {"zone = target", "clientValidation = Unschärfe",   "Kontext = Client", "Sicher = Wahr") privates Formular myForm;

.... mit anderen Worten, alle Tapestry-spezifischen Inhalte aus der Vorlage und in den Code. Nicht ideal für triviale Komponenten (mehr Wechsel zwischen Vorlage und Java-Quelle), aber großartig, um die Welten schön und getrennt zu halten.

Ich war ziemlich zufrieden mit Tapestry. Es ist ein anderer Ansatz als das, was die meisten Menschen gewohnt sind. Es verwendet eine Menge des gleichen Paradigmas wie WebObjects (auf dem der iTunes Store basiert).

Tapestry kann die Menge an Code, die Sie zum Ausführen einer Aufgabe schreiben müssen, sehr gut minimieren. Das ist großartig, wenn Sie erst einmal wissen, was Sie tun, aber es kann anfangs frustrierend sein, wenn Sie die Namenskonventionen lernen, weil einige Dinge auf magische Weise funktionieren und andere nicht, weil Sie falsch benannt haben.

Einer meiner Lieblingsaspekte bei Tapestry ist, wie wenig XML benötigt wird. Wenn Sie beispielsweise eine Hibernate-Entität erstellen, legen Sie sie im Paket com.example.entities ab und geben Sie die Annotation @Entity an. Es ist keine andere Konfiguration notwendig - kein XML, kein Hinzufügen des Klassennamens zu einer Datei, etc.

Ich würde sehr empfehlen, sich den tatsächlichen Code anzusehen, um zu sehen, was Sie denken. Hier sind ein paar Vorschläge:

wookicentral.com/ github.com/spreadthesource/wooki

tapestry.zones.apache.org:8180/tapestry5-hotel-booking/ github.com/ccordenier/tapestry5-hotel-booking

Sieh dir auch die Jumpstart-Seite an. Es enthält eine Reihe von Beispielen zusammen mit dem Code, der Ihnen genau zeigt, wie Sie die meisten der verschiedenen Komponenten verwenden. Es enthält auch eine Startpunkt-App, die Ihnen einige Benutzerverwaltungsfunktionen bietet, wenn Sie eine Anwendung darauf aufbauen möchten.

jumpstart.doublenegative.com.au/jumpstart/

Sehen Sie sich auch die überarbeitete Tapestry-Dokumentation an. Es ist noch nicht auf der Hauptseite veröffentlicht, aber es ist schon ein großer Schritt vorwärts:

people.apache.org/~uli/tapestry-site/

Verwenden Sie JSF 2, insbesondere wenn Sie Java EE 6-Funktionen verwenden. Wenn Sie eine ausgefallene Benutzeroberfläche haben möchten, probieren Sie Primefaces .

Gemäß Ihrer Anforderung ist es wichtig zu berücksichtigen, dass Sie MySQL verwenden, und das war's. Daher, wenn aus verschiedenen Blickwinkeln. Sie verwenden JPA2 (und Ihr Persistenzanbieter ist in diesem Fall zufällig Ruhezustand). Mit diesem Ansatz können Sie den verwendeten Persistenzanbieter oder die verwendete Datenbank schnell und einfach "austauschen".

Sieht aus wie Java EE 6 es löst.

Ich liebe diese Frage über Tapestry . Vielleicht wird es Ihre Entscheidung beeinflussen.