Performance von Web-Frameworks

[Michael Voigt]

Hallo Leute,

ich bin ein absoluter Laie und Java EE. In meiner Firma planen wir jetzt die Entwicklung eines größeren Projekts in Java EE - Technologie. Die Zugriffe auf dem System werden voraussichtlich enorm sein.

Hierbei ist mir die Aufgabe für die Entwicklung des Web-Tier zugekommen. Ich habe mich daraufhin schon etwas in diesem Bereich umgehört und bin auf folgende Frameworks gestoßen

1. Tapestry
2. Struts 2
3. JSF Facelets
4. Wicket
5. GWT

Da wie bereits oben beschrieben, die Zugriffe auf das System enorm sein werden, stellt sich für mich natürlich im Vorfeld die Frage auf welches Framework man setzen sollte. Denn auf der einen Seite liest man unter Contenmanager.de, das die Web-Engine für Java im verhältniss zu PHP sehr langsam sein soll. Auf der anderen Seite liest man allerdings auch (wikipedia.de), daß Tapestry auf Performance ausgelegt ist.

Könnt Ihr (Professionals) mir mal bitte eine Einteilung der obigen Frameworks geben. Insbesondere bezugnehmend auf diie Performance? Auf welches Framework würdet Ihr setzen?

Michael

 

[maki]

Denn auf der einen Seite liest man unter Contenmanager.de, das die Web-Engine für Java im verhältniss zu PHP sehr langsam sein soll.

Wenn die so etwas schreiben, würde ich abstand davon nehmen dort nochmals zu lesen.

Was sind denn "enorme" Zugriffe?

 

[Michael Voigt]

Denn auf der einen Seite liest man unter Contenmanager.de, das die Web-Engine für Java im verhältniss zu PHP sehr langsam sein soll.

Wenn die so etwas schreiben, würde ich abstand davon nehmen dort nochmals zu lesen.

Was sind denn "enorme" Zugriffe?

Enorm bedeutet

in unserer Firma arbeiten ca. 500 Personen (die täglich damit arbeiten werden) hinzukommen ca. 1500 Partnerfirmen / Kunden, wobei unser größter Kunde knapp 6000 Mitarbeiter zählt. D.h. im schlimmsten Fall muß der Server ca. 1 Mio Anfragen standhalten.

 

[ps]

Ich würde auf Struts2 setzen. Aus drei Hauptgründen:

a) ich kenne mich damit sehr gut aus
b) es hat sich bewährt (AdSense, JIRA, Confluence, etc)
c) es ist sehr flexibel

wenn du jetzt aber eine reine ajax anwendung bauen willst ist vielleicht GWT die bessere wahl...

Das die Webengine von Java langsam ist .. nunja .. *lach*. Ich schließe mich meinem Vorredner an, vermeide es dort weiter zu lesen.

 

[gex]

Aus technologischer Sicht wäre sicherlich JSF mit Facelets nicht daneben.

Geht es aber um enorm viele Zugriffe und auch grössere Datenmengen (mit grossen Tabellen), so
ist Struts 2 sicherlich schneller als JSF + Facelets, da JSF vom UI-Komponentenmodell her gesehen schwerfälliger ist.

Entsprechende Benchmarks haben das auch bewiesen.

 

[Terminator]

Also ich kenne die aufgeführten Frameworks wie Struts ... zwar nicht, bin aber dennoch der Meinung der Vergleich mit JSF schon ansich falsch ist.
Mein Vergleich wie Struts vs Spring vs ... wär dann besser.


JSF ist ein Standard - damit mein ich jetzt net es ist DAS Framework, sondern dass es die Grundlage ist.
Sun hat eben für alle Java Web Entwickler eine einheitliche API definiert und auch sicherlich bewusst gleich mit in EE integriert.
Auf diese Standard Schnittstelle können jetzt eben alle verlässlich aufbauen und auch andere Java Techniken können dann leichter integriert werden.
Mit allen mein ich nicht nur uns Ententwickler, es wird bzw ist gibs ja schon von verschiedenen Firmen Componenten, ... und auch die IDEs bieten schon erste Plugins an.


Ob man dann darauf zur Vereinfachung noch ein anderes Framework einsetzen möchte, ist ja jeden selbst überlassen.
Aber bei nem neuen Projekt nicht auf JSF zu setzen halte ich für nen grossen Fehler.

 

[ps]

Also ich kenne die aufgeführten Frameworks wie Struts ... zwar nicht, bin aber dennoch der Meinung der Vergleich mit JSF schon ansich falsch ist.
Mein Vergleich wie Struts vs Spring vs ... wär dann besser.

Ja und Nein. Ich finde das kann man schon vergleichen.

JSF ist ein Standard - damit mein ich jetzt net es ist DAS Framework, sondern dass es die Grundlage ist.

JSF ist IMHO überhaupt kein richtiges Framework. Seam oder Shale sind Frameworks die auf JSF aufbauen.
Wenn man von Standards spricht: Servlets und JSP sind auch Standards. JSF ergänzt diese, ersetzt sie aber keinesfalls.

Es ist halt ein Komponentenmodell - für manche Anwendungen sicher besser geeignet, für viele aber auch eher nicht geeignet.

Sun hat eben für alle Java Web Entwickler eine einheitliche API definiert und auch sicherlich bewusst gleich mit in EE integriert.

Meinst du jetzt Servlets und JSP oder JSF? ;-)

Auf diese Standard Schnittstelle können jetzt eben alle verlässlich aufbauen und auch andere Java Techniken können dann leichter integriert werden.

JSF ist aber nicht DIE Webschnittstelle für JavaEE, siehe oben.

Mit allen mein ich nicht nur uns Ententwickler, es wird bzw ist gibs ja schon von verschiedenen Firmen Componenten, ... und auch die IDEs bieten schon erste Plugins an.

Ob man dann darauf zur Vereinfachung noch ein anderes Framework einsetzen möchte, ist ja jeden selbst überlassen.
Aber bei nem neuen Projekt nicht auf JSF zu setzen halte ich für nen grossen Fehler.

Es kommt auf das Projekt an - bei manchen Projekten bietet sich ein komponentenbasierter Ansatz wie JSF an. Bei vielen Webprojekten erzeugt man damit aber nur einen Overhead und hat nicht sehr viel Nutzen davon. Persönlich sehe ich bei den meisten Webprojekten eigentlich einen Actionbasierten Ansatz (Struts(2), Spring MVC, etc) weit vorne... Komponentenbasiert ist eigentlich nur sinnvoll wenn die Anwendung Clientcharakter hat, also man eine Anwendung baut die auch als Rich Client realisiert werden könnte...

 

[gex]

Bei JSF geht es halt vor allem um die UI-Komponenten - und der Komponentenbaum dahinter braucht Performance.

JSF kann beliebig mit anderen Frameworks (e.g. Spring) kombiniert werden.

 

[ps]

JSF kann beliebig mit anderen Frameworks (e.g. Spring) kombiniert werden.

Jein. "Spring" sagt in diesem Kontext nicht viel. Wenn du den DI Container meinst: Ja. Den kannst du mit jeder Java Applikation benutzen.

"Spring MVC", ein Webframework vergleichbar mit Struts(2), ist allerdings actionbasiert und somit nicht so gut mit JSF integrierbar. Es geht wahrscheinlich (es gibt auch ein Plugin für Struts2) ... aber der Sinn sei jetzt mal dahingestellt. IMHO eigentlich nur für Integrationsarbeiten sinnvoll.

 

[Michael Voigt]

Entsprechende Benchmarks haben das auch bewiesen.

Hast du evtl. einen Link zu diesen Benchmarks?

 

[ps]

-> http://www.java-forum.org/de/topic75280_performance-struts-vs-faceltes-vs-jsp.html

Hier gabs das Thema schonmal .. dort hab ich die Benchmarks gepostet.

 

[Michael Voigt]

JSF kann beliebig mit anderen Frameworks (e.g. Spring) kombiniert werden.

Jein. "Spring" sagt in diesem Kontext nicht viel. Wenn du den DI Container meinst: Ja. Den kannst du mit jeder Java Applikation benutzen.

"Spring MVC", ein Webframework vergleichbar mit Struts(2), ist allerdings actionbasiert und somit nicht so gut mit JSF integrierbar. Es geht wahrscheinlich (es gibt auch ein Plugin für Struts2) ... aber der Sinn sei jetzt mal dahingestellt. IMHO eigentlich nur für Integrationsarbeiten sinnvoll.

Also wenn ich es jetzt richtig von euch Verstehe bleiben im Grunde nur zwei Ansätze übrig

JSF Faclets
Struts 2

Wie sieht es aus mit der (lt. wikipedia.de) hohen Performance von Tapestry?

Lt. wikipedia ist Struts ja monolitisch, d.h. für mich die Performance ist nicht gerade berauscht, da kein Lightweight. Sehe ich das richtig?

Um einige Komponenten (z.B. Navigator) zu realisieren habe ich in einem Buch über Seam (mtp - Verlag) gelesen, dass dieser über zustandsbehaftete Beans realisiert wird. In einem Buch über J2EE (Thomas Stark) habe ich hingegen gelesen, das zustandsbehaftete Beans sehr performanclastig sind. Jetzt stellt sich für mich die Frage, sollte man (ich komme aus der PHP - Szene) diese Navigation nicht über POST verschicken? Wie sind eure Erfahrung?

Hier stellt sich für mich daran anschliessend noch eine weitere Frage JSF ist ja (so wie ich in JSF, Hanser Verlag) richtig gelesen habe, für zustandsbehaftete Beans gedacht. Würde dieses dann nicht der Performance entgegen stehen?

 

[HLX]

Wenn hier die Server-Performance das wichtigste Argument sein soll, möchte ich nochmals auf GWT zurückkommen.

In dem AJAX-Framework wird die GUI vollständig clientseitig verarbeitet. GUI-Komponenten werden einmalig heruntergeladen und von da an aus dem Browsercache bezogen, solange bis die Anwendung vom Entwickler aktualisiert wird. Dadurch wird lediglich die BL übertragen und serverseitig verarbeitet. Es steht dem Entwickler frei, Teile der BL ebenfalls clientseitig auszuführen, so dass die Server- und Netzlast nach belieben minimiert werden können.

 

[Guest]

Lt. wikipedia ist Struts ja monolitisch, d.h. für mich die Performance ist nicht gerade berauscht, da kein Lightweight. Sehe ich das richtig?

Nein, der Wiki-Artikel ist veraltet und bezieht sich auf Struts 1. Mitlerweile sind die Actions POJOs und auch sonst hat sich ziemlich viel verändert in Version 2.

 

[klarkimming]

Hallo,

ich bin ein absoluter Laie und Java EE. In meiner Firma planen wir jetzt die Entwicklung eines größeren Projekts in Java EE - Technologie. Die Zugriffe auf dem System werden voraussichtlich enorm sein.

Hierbei ist mir die Aufgabe für die Entwicklung des Web-Tier zugekommen. Ich habe mich daraufhin schon etwas in diesem Bereich umgehört und bin auf folgende Frameworks gestoßen

1. Tapestry
2. Struts 2
3. JSF Facelets
4. Wicket
5. GWT

Es fehlen in deiner Aufzaehlung:

6. Applets (wieder Ueberlegungswert)
7. Flex !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
8. Frameworks wie z.B. extJS

Erstmal solltet Ihr euch entscheiden, ob Ihr ein RIA erstellen moechtet oder eine traditionelle Web-Anwednung.
(Im aktuellen Java-Magazin z.B ein Ueberblick ueber RIA)

Allgemeine Anmerkung:

Du bist ein

absoluter Laie

und meinst eine Technologieauswahl treffen zu koennen ?

Es gibt in diesem Forum vermutlich niemanden der die Vor- und Nachteile ALLER acht Technologien aufzaehlen kann. Dann muesst Ihr euch auch noch entscheiden welche IDE Ihr benutzt, vom einrichten des Projektes mal ganz zu schweigen. Dann fehlt komplett das Thema Sicherheit. Was wollt Ihr dort einsetzen (Spring-Security, etc.).

Fazit:

Egal, welches Framework Ihr einsetzt: Holt euch Hilfe und zwar nicht ihn Form von Forenpost, sondern durch eine Unternehmensberatung!!!!!! Die sollen alles aufsetzen und euch am Anfang bei der Implementierung unterstuetzen. Spaeter werdet Ihr Sie dann vermutlich nicht mehr brauchen.

Wie siehts eigentlich mit dem Java-Wissen im Gesamtunternehmen aus ? Gibt es dort Personen, die mind. 3 Jahre Berufserfahrung als Softwareentwickler / Architekt im Java Bereich haben ? Wenn nicht ....

Wenn ja, dann muessen die sich um sowas kuemmern!

 

[Terminator]

@pa

> JSF ist IMHO überhaupt kein richtiges Framework
doch ist es


> Meinst du jetzt Servlets und JSP oder JSF?
mein schon JSF
bist du wohl noch auf EE 1.4, da wars noch nicht mit dabei


> JSF ist aber nicht DIE Webschnittstelle für JavaEE
Nee noch nicht, JSP war aber auch einmal am Anfang.
Mit JSF 2.0 halten eben andere View Techniken wie bsw Facelets Einzug in EE6.
Kenn JSP und Facelets - ziehe letzteres auf jedenfall vor.


> Komponentenbasiert ist eigentlich nur sinnvoll wenn die Anwendung Clientcharakter
Der Punkt is mal in die Zukunft zu gucke.
Der Trend bei WebApps geht eben in die Richtung.
Findest doch scha überall AutoComplete Eingaben, Tab Menüs, ...




@klarkimming
N Überblick in Foren zu verschaffen ist voll kommen ok.
IDE is eigentlich egal, Security is auch mit EE allein möglich.

Des mit der Berufserfahrung stimm ich dir voll zu!
Sonst is da 2010 noch nix fertig

 

[SnooP]

Eine "Portalähnliche" Seite (sprich ziemlich viel Zugriff) würde ich aktuell nie mit JSF machen... ich persönlich finde JSF zwar ganz gut (zumindest > 1.2 und mit Facelets), aber auch nur in Zusammenspiel mit diversen Komponentenlibs und auch der entsprechenen Erfahrung. So richtig der Brüller ist das ganze auch nicht... Tapestry5 sieht übrigens schonmal gar nicht soo schlecht aus... - Struts2 wird bei uns auch schon recht erfolgreich verwendet, würde ich aktuell auch immer vorziehen. Grails ist z.B. auch noch ganz nett, wenn die Anwendung klein ist und nicht unbedingt rasend schnell sein muss...

ob JSF 2.0 der Kracher schlechthin wird und die Probleme die viele mit JSF haben beseitigt, weiß ich übrigens nicht... das wird sich erst später zeigen... es gibt halt genügend andere Frameworks, die zeigen, dass man mit deutlich weniger Konfiguration und Ballast auskommt.... und damit evtl. sogar eine Spur flexibler bleibt...

 

[Guest]

Hallo,

ich bin ein absoluter Laie und Java EE. In meiner Firma planen wir jetzt die Entwicklung eines größeren Projekts in Java EE - Technologie. Die Zugriffe auf dem System werden voraussichtlich enorm sein.

Hierbei ist mir die Aufgabe für die Entwicklung des Web-Tier zugekommen. Ich habe mich daraufhin schon etwas in diesem Bereich umgehört und bin auf folgende Frameworks gestoßen

1. Tapestry
2. Struts 2
3. JSF Facelets
4. Wicket
5. GWT

Es fehlen in deiner Aufzaehlung:

6. Applets (wieder Ueberlegungswert)
7. Flex !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
8. Frameworks wie z.B. extJS

Erstmal solltet Ihr euch entscheiden, ob Ihr ein RIA erstellen moechtet oder eine traditionelle Web-Anwednung.
(Im aktuellen Java-Magazin z.B ein Ueberblick ueber RIA)

Allgemeine Anmerkung:

Du bist ein

absoluter Laie

und meinst eine Technologieauswahl treffen zu koennen ?

Es gibt in diesem Forum vermutlich niemanden der die Vor- und Nachteile ALLER acht Technologien aufzaehlen kann. Dann muesst Ihr euch auch noch entscheiden welche IDE Ihr benutzt, vom einrichten des Projektes mal ganz zu schweigen. Dann fehlt komplett das Thema Sicherheit. Was wollt Ihr dort einsetzen (Spring-Security, etc.).

Fazit:

Egal, welches Framework Ihr einsetzt: Holt euch Hilfe und zwar nicht ihn Form von Forenpost, sondern durch eine Unternehmensberatung!!!!!! Die sollen alles aufsetzen und euch am Anfang bei der Implementierung unterstuetzen. Spaeter werdet Ihr Sie dann vermutlich nicht mehr brauchen.

Wie siehts eigentlich mit dem Java-Wissen im Gesamtunternehmen aus ? Gibt es dort Personen, die mind. 3 Jahre Berufserfahrung als Softwareentwickler / Architekt im Java Bereich haben ? Wenn nicht ....

Wenn ja, dann muessen die sich um sowas kuemmern!

Also mir ist nicht so ganz klar was du hier so rum wetterst. Denn wie du, wenn du in größern Projekten bereits gearbeitet hast, weist gibt es eine sogenannte Bereichszuordnung. Natürlich interessiere ich mich über den mir zugeordneten Bereich hinaus, ich denke mal das sollte ganz natürlich sein.

Als nächstes ist mir aufgefallen, du nennst hier Frameworks, die nicht zur Debatte stehen, da sie entweder veraltet (Applets), lt. Google kaum dokumentiert (Flex, extJS) oder nichts mit Java zu tun hat (extJS ist JavaScript).

Drittens es du schreibst hier wir müssen uns entscheiden, welche IDE wir verwenden wollen? Über das warum lässt du dich nicht aus. Wir arbeiten mit Eclipse. Deshalb frage Ich dich warum?

Viertens Acegi habe ich keines wegs außer acht gelassen. Dieses war aber hier auch nicht die Frage.

Und zu guter letzt eine Unternehmensbereatung werden wir noch holen, aber erst dann wenn wir genügend Fragen haben, die sich im Vorfeld ergeben haben, und nicht Geld rausschmeissen, wenn Sie noch nicht benötigt wird. Was macht das für Sinn?

 

[Michael Voigt]

Eine "Portalähnliche" Seite (sprich ziemlich viel Zugriff) würde ich aktuell nie mit JSF machen... ich persönlich finde JSF zwar ganz gut (zumindest > 1.2 und mit Facelets), aber auch nur in Zusammenspiel mit diversen Komponentenlibs und auch der entsprechenen Erfahrung. So richtig der Brüller ist das ganze auch nicht... Tapestry5 sieht übrigens schonmal gar nicht soo schlecht aus... - Struts2 wird bei uns auch schon recht erfolgreich verwendet, würde ich aktuell auch immer vorziehen. Grails ist z.B. auch noch ganz nett, wenn die Anwendung klein ist und nicht unbedingt rasend schnell sein muss...

ob JSF 2.0 der Kracher schlechthin wird und die Probleme die viele mit JSF haben beseitigt, weiß ich übrigens nicht... das wird sich erst später zeigen... es gibt halt genügend andere Frameworks, die zeigen, dass man mit deutlich weniger Konfiguration und Ballast auskommt.... und damit evtl. sogar eine Spur flexibler bleibt...

Du schreibst du würdest im Grund JSF fast nie verwenden. Wie ist sieht es aber mit zustandsbehaftete Beans aus? Eine grundsätzliche Vorüberlegung zu unserem Programm ergab, das es einige Beans geben werden, die zustandsbehaftet sein werden. Wie sieht es hiermit im Vergleich JSF / Faclets mit Tapestry5 und Struts2 aus? Ich habe mich mal im Netz umgeschaut, habe aber keine vernünftige Dokumentation zu Tapestry gefunden. Kannst du mir einen Link nennen, wo man sich über Tapestry einlesen (evtl. deutsch) kann?

 

[ps]

@pa

> JSF ist IMHO überhaupt kein richtiges Framework
doch ist es

Ja, aber ein seeehr minimalistisches. Oder wie erklärst du dir das Frameworks wie Seam oder Shale auf JSF aufsetzen?
Ein Webframework ist für mich etwas das alle oder zumindest die meisten meiner Probleme löst - das ist bei JSF _alleine_ nicht der Fall.

> Meinst du jetzt Servlets und JSP oder JSF?
mein schon JSF
bist du wohl noch auf EE 1.4, da wars noch nicht mit dabei

Nein, bin ich nicht. Aber JSF ist kein Ersatz für Servlets oder JSP. Es ist eine ergänzende Technologie für komponentenbasiertes Arbeiten.

Das macht manchmal Sinn, manchmal eher nicht. Das Web ist halt nicht zustandslos... Request und Response. Das ist die Natur von HTTP. JSF versucht dies zu "verstecken" indem ein Baum aller Elemente und deren Zustände im Speicher gehalten wird: Das kostet Performance.

Wie gesagt: bei Anwendungen welche eher Clientnatur haben macht dieses Entwicklungsmodell Sinn. Bei herkömmlichen Webseiten aber eher nicht.

> JSF ist aber nicht DIE Webschnittstelle für JavaEE
Nee noch nicht, JSP war aber auch einmal am Anfang.
Mit JSF 2.0 halten eben andere View Techniken wie bsw Facelets Einzug in EE6.
Kenn JSP und Facelets - ziehe letzteres auf jedenfall vor.

Auch Servlets und JSP entwickeln sich weiter. Wie oben ausgeführt: JSF ist kein Ersatz für Servlets/JSP. Und ist auch nicht als solcher gedacht.

> Komponentenbasiert ist eigentlich nur sinnvoll wenn die Anwendung Clientcharakter
Der Punkt is mal in die Zukunft zu gucke.
Der Trend bei WebApps geht eben in die Richtung.
Findest doch scha überall AutoComplete Eingaben, Tab Menüs, ...

Einzelne JS-Gimmicks rechtfertigen IMHO noch lange kein komponentenbasiertes Framework. Und was verstehst du eigentlich unter WebApps?

Der Trend ist übrigens meist ein schlechter Ratgeber. Gerade in der Java Welt wird so viel sinnloser Quatsch gehyped das es nicht mehr schön ist. Man muss sich einfach das aussuchen mit dem man am besten ans Ziel kommt. Ob Standard oder nicht, ungeachtet irgendwelcher Trends.

 

[Terminator]

> Oder wie erklärst du dir das Frameworks wie Seam oder Shale auf JSF aufsetzen?
vielleicht sehen die Entwickler auch Vorteile bei dieser Schnittestelle


> Ja, aber ein seeehr minimalistisches
Find ich überhaupt net - was fehlt dir?


> Aber JSF ist kein Ersatz für Servlets oder JSP
Servlet stimm ich zu, bei JSP gibs eben andere View Technologies


> Das Web ist halt nicht zustandslos... Request und Response. Das ist die Natur von HTTP. JSF versucht dies zu "verstecken"
1. machste auch bei Servlet/JSP sobald du Objekte in die Session legts.
2. Mit tranisient Attribute kannste State Saving steuern
3. kann man den State auch zum Client rendern lassen wenn man das lieber möchte


> Einzelne JS-Gimmicks
Diese "Gimmicks" sind konkreter Teil der Webprogrammierung.
Auch auf herkömmlichen Webseiten, was immer das heissen mag, haste SortableTables, Paging, Grids, Charts, ...

 

[ps]

> Oder wie erklärst du dir das Frameworks wie Seam oder Shale auf JSF aufsetzen?
vielleicht sehen die Entwickler auch Vorteile bei dieser Schnittestelle

Naja - ein Framework bügelt doch eher die Unzulänglichkeiten einer Technologie aus ;-)
Struts und viele Andere hat sich den Schwächen von Servlets und JSP angenommen.
Seam und Shale nehmen sich den Schwächen von JSF an.

> Ja, aber ein seeehr minimalistisches
Find ich überhaupt net - was fehlt dir?

Zwei kleine Beispiele: Eine Layout-Engine.. die Möglichkeiten von purem JSF sind sehr dürftig. Ich rede von etwas vergleichbarem zu SiteMesh oder Tiles. Dann fehlt mir ordentlicher Validation-Support. Sehr minimalistisch was da vorhanden ist.
Diese Liste könnte man sicher noch ausbauen.. aber ich habe nach meinen Ersten Versuchen mit JSF für mich entschieden das es nicht in Frage kommt. Und daher sind mir die Schwächen auch nicht so gut vertraut

> Aber JSF ist kein Ersatz für Servlets oder JSP
Servlet stimm ich zu, bei JSP gibs eben andere View Technologies

JSPs sind doch technisch auch nichts anderes als Servlets.

> Das Web ist halt nicht zustandslos... Request und Response. Das ist die Natur von HTTP. JSF versucht dies zu "verstecken"
1. machste auch bei Servlet/JSP sobald du Objekte in die Session legts.

Aber nicht in diesem Ausmaß. Man kann sehr viel genauer steuern welche Daten man sichert und welche nicht - bei JSF wird aber der komplette Komponentenbaum ständig in der Session mitgeschleift.

> Einzelne JS-Gimmicks
Diese "Gimmicks" sind konkreter Teil der Webprogrammierung.
Auch auf herkömmlichen Webseiten, was immer das heissen mag, haste SortableTables, Paging, Grids, Charts, ...

Sicher, solche Sachen lassen sich nett mit Komponenten abbilden. Aber ich kann mir dafür auch eigene Tags bauen. Ich sehe keinen Großen Vorteil von "echten" komponenten.

 

[Terminator]

> Naja - ein Framework bügelt doch eher die Unzulänglichkeiten einer Technologie aus
Stimm ich dir schon zu
Man kann aber Frage auch anders sehen:
Warum setzt Framework XY nun JSF, wenns doch Servlets+JSP sehr gut lief.


> SiteMesh
hab ich jetzt erst mal kurz suchen müssen, bisher noch nie sowas gebraucht
das des den Response noch mal parst klingt aber net gut


> Tiles
Facelets hat diverse Template Tags mit dem allen möglichen Funktionen.
Gibt glaub ich auch noch JSFTemplating als View Technologie


> Validation-Support
Hmm - sind halt paar Standard Validator dabei.
Werden bestimmt noch mehr nach und nach, ausserdem kann man ja eigene schreiben.


> JSPs sind doch technisch auch nichts anderes als Servlets.
werden zu Servlets


> Aber nicht in diesem Ausmaß
Also wie schon mal erwähnt, dass Ausmass lässt sich eingrenzen
Übrigens ab JSF 2.0 kommt ein neuer Scope ins Spiel: viewScope
Reduziert die Session Nutzung erheblich


> Aber ich kann mir dafür auch eigene Tags bauen. Ich sehe keinen Großen Vorteil von "echten" komponenten.

Also ich kenns jetzt so dass Tags gleich den Response Code produzieren.
Weiss jetzt nicht wie ob da bei Struts noch mehr verknüpfbar ist.

bei JSF ist so:
- Tag ist verbunden mit ner Kompo
- Kompo kann ich erweitern bsw. um nen CurrencyConverter
- Kompo+Tag verbinde ich mit Standard InputTextRenderer
=> Formatiert anhand der View Locale + hab gleich serverseitige Funktionen/Werte

Vorteil:
- Renderer kann mehrfach genutzt werden
- Kompo kann sich State für späteren Postback merken
- Gleiche Tag kann über automatische Wechsel des RenderKits bsw WML rendern

 

[Florian Müller]

Hallo zusammen,

bin gerade auf diese recht angeregte und interessante Diskussion gestoßen - schön zu sehen dass das Thema Client Technologien aktuell kontroverse Debatten auslöst! ;-)

Prinzipiell kann im Augenblick glaube ich keiner sagen wo die Client-Reise hingeht, Fakt ist lediglich dass es Frameworks und Technologien mit kurzer Lebensdauer gibt (Hype-Frameworks!) und solche mit langlebiger Dauer (Trend-Frameworks!). Lass doch einfach mal ein paar Search Querries bei Google Trends los, z.B. "Ajax,Applet" - Du wirst interssante Resultate feststellen und kannst ganz grob ausloten wo einzelne Frameworks gerade stehen (aufsteigend oder abklingend).

Ganz klar an dieser Stelle: das sagt NIX über die technische Qualität eines Frameworks aus, ist ganz einfach nur ein interssantes Experiment um festzustellen ob Applets denn wirklich "tot" sind oder vielleicht gerade eine Rennasissance erleben ;-)

Ansonsten kann ich Dir noch empfehlene Dich mal bei uns auf richability (www.richability.com) umzuschauen. WIr evaluieren regelmäßig Technologien und haben einige schöne Demos zusammen gestellt, vielleicht hilft Dir ja das um ganz grob festzustellen in welche Richtung Ihr marschieren möchtet.

Falls Ihr irgendwann konkrete Hilfe für die Client-Technologie Auswahl braucht dürft Ihr uns gerne anpingen! ;-)

Schöne Grüße, Florian Müller!