Freitag, 3. September 2010

News

Montag, 15. März 2010 | News

"JSF ist DAS UI-Framework im JavaEE-Umfeld"

(Link zum Artikel: http://www.entwickler.de/jaxenter//054426)

Dieses Jahr widmet sich die JAX mit gleich zwei Tagen dem Thema Java Web Development, special JavaServer Faces. Andy Bosch, Autor des Buches "Portlets und JavaServer Faces", wird mittwochs den JSF Day moderieren, während Matthias Weßendorf am Freitag zu JSF Extreme einlädt. Wir sprachen mit beiden über das Thema JSF und was uns auf den Tagen erwarten wird.

JAXenter: Es ist stiller um JSF geworden, im Bereich der Java-Webentwicklung geben hippe Frameworks wie Grails, (J)Ruby on Rails oder Wicket derzeit den Ton an. Wie hält die JSF-Community dagegen?

Matthias Weßendorf: Findet ihr? Ich finde, dass gerade bei JSF einiges passiert: Die ganzen Bibliotheken stellen gerade auf JSF2.0 um und stellen ihre "Macken" als Bugs gegen die Spezifikation und die Implementierungen ein. Die JSF EG arbeitet MR-Releases der Spec ein und sammelt Ideen für die Zukunft. Überhaupt ist JSF 2 gut angenommen: Das zeigt, dass dieses Release notwendig war!

Andy Bosch: Wer sagt denn, dass es stiller geworden ist? Ich empfinde es gerade anders herum. Über JSF 2.0 wird sehr viel gesprochen. Es wird meist anerkennend erwähnt, dass viele Schwierigkeiten aus JSF 1.x sehr gut gelöst wurden und JSF 2 jetzt eine sehr mächtige Basis für Webanwendungen bereitstellt. Die Expert Group von JSF 2.0 ist sehr bemüht, den Prozess offen und lebendig zu gestalten. Ich habe persönlich noch nie eine Expert Group erlebt, die mit der Community derart intensiv im Dialog ist. Auch empfinde ich persönlich den ersten Hype um Grails / Rails / Wicket vorüber. Jetzt muss der Markt zeigen, ob diese Frameworks auch von der Masse angenommen werden.

JAXenter: Welche Antworten gibt es aus dem JSF-Lager auf modernste Anforderungen wie Ajax-Unterstützung oder mobile Clients wie z.B. iPhone?

Andy Bosch: Naja, Ajax ist nicht mehr wirklich eine „moderne“ Anforderung. Jedes Webframework muss es quasi out-of-the-box schon mitbringen. JSF hat die Ajax-Funktionalität im Standard bereits festgelegt, so dass auf dieser Basis umfangreiche Komponenten im OpenSource-Bereich entstehen können. Für die Unterstützung anderer Devices oder Ausgabeformate generell ist JSF konzeptionell bereits seit Beginn an dafür ausgelegt. Es gibt die Trennung von UI-Komponente und Renderer. So kann ein Render-Kit ausgetauscht werden, ohne die Funktionalität neu programmieren zu müssen. Wicket z.B. ist hier viel stärker an HTML gebunden als JSF, was hier eine eigene Abstraktion bietet.

Matthias Weßendorf: Ajax würde ich nicht mehr als "modern" bezeichnen: Es ist ein Muss-Kriterium. JSF 2 hat ein minimales Ajax-API, das weiter ausbaufähig ist. Generell kann man das API gut mit der eigenen JSF-Bibliothek nutzen, so dass "interoperability issues" in Zukunft weniger werden. Verschwinden werden sie nicht (gänzlich). Ein Grund: Uploads via PPR. JSF 2 weiß nichts über Uploads, aber jede JSF-Bibliothek. Uploads sollen aber innerhalb von JSF 2.x berücksichtig sein.

Zum Thema iPhone/Android wird auch einiges angeboten, von verschiedenen JSF "Tools": IceFaces, PrimeFaces oder Trinidad. Trinidad hat den Vorteil, dass man auf bewährte TAGs/Komponenten zurückgreifen kann. Das Look-And-Feel wird über ein CSS-Skin angepasst. Ich schreibe eine "mobile" Seite und liefere sie für iPhone und Android aus: Das Look-And-Feel wird via Runtime angehängt. Das ist sehr schick: Ohne neue Komponenten zu erstellen/benutzen.

JAXenter: Spätestens in diesem Jahr richten sich alle Blicke auf HTML5: welche Auswirkungen wird dies auf JSF haben und wie bereitet man sich ggf darauf vor?

Matthias Weßendorf: Sehr gut. Für Apache MyFaces gibt es (wird es geben) ein "Google Summer of Code" Projekt, das ein HTML5 RenderKit für JSF2 realisieren wird. Die Gotchas werden wieder in die Spezifikation zurückfließen. Innerhalb der EG gab es kleinere Überlegungen, das eine oder andere Widget zu spezifizieren. Aber... Specs sind langsam... MyFaces wird schon bald erste Ergebnisse liefern können.

JAXenter: Seit letztem Jahr ist das Thema JSF mit zwei Special Days auf der JAX vertreten. Was rechtfertig eurer Meinung nach diesen hohen Stellenwert?

Matthias Weßendorf: Ganz einfach: Es ist die meistverbreitete UI-Technologie im Java-Umfeld. Wachsende Teilnehmerzahlen bei anderen "JSF Events" unterstreichen diesen Trend.

Andy Bosch: JSF ist das UI-Framework im JavaEE-Umfeld. Es hat seit mehreren Jahren bereits eine ständig steigende Entwickler- und Anwenderzahl. Viele Firmen und Organisationen setzen auf JSF, weil es zum einen ein Standard ist, zum anderen aber auch, weil es funktional mittlerweile sehr ausgereift ist. Ich denke, JSF ist es gelungen, die Vorteile eines Standards mit den Vorteilen einer aktiven und schnell reagierenden Open-Source-Community zu verbinden. Dadurch ist JSF sehr populär geworden, was wiederum ein verstärktes Interesse an JSF hervorruft.

JAXenter: Unter anderem wird es auf der JAX um Comet gehen. Welche Vorteile haben Entwickler von push-Diensten wie Comet?

Andy Bosch: Ich selbst bin mir beim Thema Comet noch unschlüssig, ob ich jubeln soll oder lieber fluchen. Sicherlich, Server-Side Push ermöglicht ein ganz neues Spektrum von Anwendungen und UI-Möglichkeiten als bislang. Schaut man technisch aber etwas genauer hinter die Kulissen, ist das teilweise schon noch eine üble Frickelei von JavaScripten. Von daher würde ich meine Einschätzung momentan mit „optimistisch beobachtend“ beschreiben.

Matthias Weßendorf: Interactive GUIs. Das Web kann nun liefern, was der Desktop schon seit Jahrzehnten kann: Wird im Backend was "verändert" bekommt der (Web)Client eine Benachrichtigung ohne große Verzögerung. Das ermöglicht die Erstellung von richtig coolen (Web)Anwendungen! Auch hier gibt es bereits JSF Libs, die das Themen angehen: Oracle's ADF Faces, IceFaces und PrimeFaces. Achja, mit dem steigenden Interesse an WebSockets wird hier eine weitere Optimierung getroffen: Bidirektionale Kommunikation!

JAXenter: Ein Thema auf den JSF Days werden Reporting-Tools sein. Was macht diese so wichtig für die Webentwicklung?

Andy Bosch: Webanwendungen machen heutzutage oftmals mehr, als nur ein paar lustige Apps darzustellen. Komplette Workflows werden über Webinterfaces abgearbeitet, teilweise haben sogar Enterprise-Suiten keine eigenen „Fat-Clients“ mehr. Alles erfolgt nur noch Browserbasiert. Was liegt somit näher, als auch Auswertungen (Reports) online erstellen und analysieren zu können. Bislang hat sich der Anwender immer in zwei Welten bewegen müssen: in der Webanwendung und parallel in verschiedenen Reporting-Tools. Durch die Möglichkeit, beides zu kombinieren, kann der Anwender künftig sehr komfortabel direkt aus seiner Webanwendung die benötigten Berichte erzeugen und ausdrucken.

JAXenter: Das Web Profile ist noch realtiv jung – was bringt es eurer Meinung nach Neues bzw. wie verändert es die Java-Web-Landschaft?

Matthias Weßendorf: Weniger ist mehr! Das Web Profile beinhaltet wichtige Bestandteile, die für die meisten Anwendungen ausreichen. Nicht umsonst laufen bereits heute viele Web-Anwendungen im Tomcat/Jetty ab.

JAXenter: Eine Session wird sich genau mit diesem Thema beschäftigen: Java Web Profile versus Spring Web. Kannst du uns schon einen kurzen Ausblick auf die Lehren geben, die du aus dem Vergleich ziehen wirst?

Matthias Weßendorf: Schlüsselpunkt ist JSF: Es lässt sich mit beiden Welten einfach nutzen, wie auch JPA. Während ich im Web Profile alles habe, was ich brauche, baue ich es mir mit Spring zusammen. Beide Welten haben ihre Vor/Nachteile. Die Session zeigt das WIE mit WELCHER Umgebung und geht auf ein paar Feinheiten der Konstellationen ein.

JAXenter: Vielen Dank für das Gespräch!

Matthias Weßendorf ist Softwareentwickler bei Oracle. Dort arbeitet er an ADF Faces RichClient, einer Ajax-basierten JSF-Komponenten-Bibliothek. Matthias ist ebenfalls aktives Mitglied der Open-Source-Gemeinschaft, wo er sich überwiegend bei den Apache-Projekten MyFaces und Apache engagiert. Vorher war er als CMS-Entwickler der Pironet NDH AG an der Entwicklung eines next-generation CMS, mit UI-Techniken wie XUL und Ajax, beteiligt.

Andy Bosch ist unabhängiger Berater und Trainer für JavaServer Faces und Portlets. Er ist Autor verschiedener Fachbücher (JavaServer Faces, Portlets und JSF) sowie Betreiber der Plattformen http://www.jsf-forum.de und http://www.jsf-portlets.net. Zudem ist er Mitglied der Expertengruppe des JSR-301 (Portlet Bridge Specification for JavaServer Faces) und Mitglied in SENS (www.SoftwareExperts.de).

(cf)

Links

andere Artikel dieser Serie

Kommentare

Gravatar Trepper 15.03.2010
um 16:00 Uhr Wicket finde ich zwar _deutlich_ schöner als JSF, aber ich glaube die Zukunft gehört eher der REST-Architektur und intelligenteren Clients, z. B. HTML + JavaScript. Von der Architektur des Webs her ist es falsch, den GUI-Zustand des Clients auf dem Server zu speichern und früher oder später wird die Evolution diesen Versuch korrigieren und damit JSF auslöschen. #zitieren
Gravatar Kritiker 15.03.2010
um 16:05 Uhr Die Websites jsf-forum.de zeigt sehr schön, wie wenig JSF zum Web passt, auch wenn es in Version besser geworden ist. Der URI http://www.jsf-forum.de/forum/pages/forum/forum.jsf sollte eigentlich auf eine bestimmte Diskussion verweisen. Es kommt zwar insgesamt vier mal das Wort "forum" vor, aber relevante Informationen, um eine Seite zu identifizieren fehlen - peinlich. Von der Optik und Bedienung wäre jedes PHP-Forum besser ... #zitieren
Gravatar Simon 15.03.2010
um 16:19 Uhr Ich bin ebenfalls Treppers Meinung. Der Lifecycle von JSF ist viel zu kompliziert und in Kombination mit "Ajax-enabled" Frameworks wie Richfaces sind die Anzahl Requests eine Katastrophe. #zitieren
Gravatar Sascha 15.03.2010
um 17:41 Uhr Was mich bei diesem ganzen JSF-Hype wahnsinnig ärgert: Es wird immer so dargestellt, als ob JSF DIE Mega-Antwort auf alle Probleme ist. Zu Beginn des JSF-Hypes war ich dem Ganzen eigentlich sehr positiv eingestellt, letztendlich ist es aber alles wieder gekommen "wie immer".
Die erste JSF-Spec war ein Witz, diverse Dinge, die man schon aus dem Struts2-Alltag kannte, fehlten. Das Ganze zu benutzen war einfach nur ein Krampf, es wurde Wert gelegt auf Features, die kein Mensch benötigte, dafür fehlten grundlegende Sachen. Die Navigationsmöglichkeiten waren bescheiden, man konnte Seiten nur schwer wiederverwenden, die Oberflächen sahen schon damals altbacken aus, Toolunterstützung war kaum vorhanden und eigene Komponenten zu bauen extrem schwierig. Nützliche Dinge musste man "von aussen" nachrüsten (wie Facelets), und/oder auf Komponentenbibliotheken umsteigen, die ausserhalb des Standards operieren, um zumindest halbwegs brauchbare AJAX-Funktionen zu bekommen. Für flexiblere Navigationen wird dann meist Spring Webflow nachgerüstet.
Nach zig Jahren hat man es dann endlich mal geschafft, die Kinderkrankheiten auszumerzen (die traurigerweise von Anfang an bekannt waren) und klopft sich dann schön auf die Schulter ob dieser wahnsinnigen Erfolgsstory. "AJAX ist ja schon im Standard definiert". Das AJAX aber 2005/2006 schon als "Standard" galt, aber erst seit Ende 2009 im JSF-Standard definiert ist: Soll DAS ein Erfolg sein?
Vielleicht sollte man einfach auch mal einige Entwickler aus der Industrie fragen, was die davon halten, statt Leute die am Standard mitarbeiten oder von Konferenz zu Konferenz tingeln. Ich zumindest glaube nämlich, das von Leuten, die mit 3+ Personen mehr als 2+ Jahre an EINEM grossen JSF-Projekt arbeiten, mehr sinnvoller Inhalt zum Thema "JSF ist ein Erfolg" zu erwarten ist als von Leuten, die sich ein paar Showcases von 10 Seiten zusammenbasteln, um die super CSS-Fähigkeiten von neuen Komponenten oder "Guck mal, wir können PPR" zu zeigen. DAS sind nämlich echt nicht die Probleme, die die Welt da draussen ausserhalb des Reissbretts hat.
Wirkt jetzt vielleicht ein wenig provokant, ist aber keinesfalls beleidigend gemeint. Nur um das von vornherein klarzustellen :-) #zitieren
Gravatar Dag 15.03.2010
um 20:05 Uhr Wicket FTW #zitieren
Gravatar Trepper 16.03.2010
um 09:33 Uhr @Sascha Du sprichst mir aus der Seele! Ich war anfänglich auch von JSF angetan und habe mein erstes Projekt 2005 damit in Angriff genommen. Aber je mehr man sich mit JSF beschäftigt, desto hässlicher wird es. JSF ist vielleicht der letzte große Auswuchs der alten Java-Krankheit, etwas von einem Komitee entwerfen, statt in der Praxis reifen zu lassen. Bestes Beispiel sind die sinnlosen Renderer, obwohl mit JSF kaum etwas anderes als HTML gerendert wird. Stattdessen werden so grundlegende Dinge wie HTTP GET komplett außen vor gelassen. Unfassbar! Wie schon gesagt halte ich den ganzen Ansatz von JSF für krank und es wäre nicht schade drum, wenn es aussterben würde.

Guckt euch lieber REST (JAX-RS), GWT oder Wicket oder meinetwegen auch Servlets + FreeMarker an, aber vergesst JSF. #zitieren
Gravatar Trepper 16.03.2010
um 09:35 Uhr ... und noch was: In der Szene, besonders auch im Javamagazin, fehlen kritische Betrachtungen. Da schreiben immer wieder die gleichen Anhänger von bestimmten Technologien, denen die nötige kritische Distanz fehlt. #zitieren
Gravatar Denker 18.03.2010
um 12:05 Uhr Wie wäre es mit GWT + JAX-RS? Damit hätte man Webanwendungen mit reichhaltigen GUIs und würde zugleich das Problem mit der Zustandsverwaltung auf dem Server vermeiden. #zitieren
Gravatar Marc Teufel 20.03.2010
um 18:10 Uhr Ich frage mich, wie/wieso/warum kann ein Framework wie JSF so schlecht sein, wie es hier von so manchem dargestellt wird? Wir/ich sind/bin selbst gerade in einer Art Selbsfindungsphase, manche nennen es auch Evaluierung, und ich dachte eigentlich schon, dass ich mit JSF zum Ziel kommen kann. Lasst mich kurz erklären warum ich das denke: Das Quasi-Argument für JSF ist wohl das Argument des Standards, aber das ist für mich garnicht mal so relevant. Viel relevanter für mich ist, dass es sich um ein Framework handelt, um das sich weit mehr schlaue Köpfe aus verschiedenen Firmen Gedanken gemacht haben, als es beispielsweise bei Wicket der Fall ist. Nicht nur das große Firmen wie Oracle hinter JSF stehen, nein auch in der Industrie durfte ich in den letzten Wochen viele Firmen kennenlernen, die ihre alten Legacy-Anwendungen nach Java migrieren wollen und sich eben für JSF entschieden haben. Gründe waren meist: Standard, Technologien die länger Markt ist, Ausgereiftheit, akzeptierte Technologie, viele Zusatzbibliotheken am Markt verfügbar, relativ einfach JSF-Experten zu finden usw...
Wenn also soviele Experten in den vielen unterschiedlichen Firmen sich für dieses Framework entscheiden, dann kann ich mir nicht vorstellen, dass diese Entscheidung aus dem Bauch heraus getroffen wurde sondern wohlüberlegt ist und ich denke auch, dass es etwas mit der Qualität des Standards zu tun hat. Für JSF gibt es unzähliche Addons, Addons für die ich auch Support bekomme. Klar, ich bekomme auch für Frameworks wie Wicket oder GWT Addons, doch diese sind oftmals in einer nicht vergleichbaren Qualität. Das gleiche gilt für Schulungen, im Umfeld von JSF ist das Angebot größer, reichhaltiger und ich kann aus einem größerem Pool der Erfahrung schöpfen wenn ich mich für JSF entscheide. Das sind, finde ich, schon gewichtige Argumente, wenn man die ganze Thematik nüchtern betrachtet.
Die technische Seite ist natürlich auch wichtig, ich fände es auch hip, wenn ich mein großes Webprojekt ganz locker flockig und groovy in Groovy und Grails hacken könnte, aber die technische Seite ist eben nur eine Seite der Medaille. Und mir wird in diesem Blog leider zu heftig über eben nur diese Seite diskutiert.
Ich will hier keine Lanze für JSF brechen, ich bin selbst auch hin- und hergerissen und deshalb fände ich es schön wenn hier ein konstruktives Pro und Contra seitens Euch Entwickler und Entscheider stattfinden könnte. Mich interessiert vor allem auch Erfahrungen aus Projekten mit JSF, gute wie schlechte...

Los, jetzt seid Ihr dran ! Have Fun !
Euer Marc #zitieren
Gravatar Trepper 22.03.2010
um 09:41 Uhr @Marc Ich kann deine Überlegungen gut nachvollziehen und tatsächlich bin ich auch der Meinung, dass ein Standard viel Wert ist, selbst wenn es technisch vielleicht bessere Lösungen gibt. Die Kompromisse, die man für den Standard eingehen muss, wiegen dessen Beschränkungen in vielen Fällen mehr als auf - wenn der Standard gut ist. Und genau das stelle ich bei JSF in Frage. Dein Argument, dass etwas gutes dabei herauskommt, wenn sich ein Komitee aus vielen vermeintlichen schlauen Köpfen zusammensetzt sollten durch J2EE und JSF 1 widerlegt sein. Zusammengefasst ist deine Überlegung nichts anderes, als die Überlegung der Herde zu folgen. Aber es gab auch mal eine J2EE-Herde und heute ist jeder froh, davon weg zu sein!

Abgesehen davon, dass ich JSF im Vergleich zu Wicket viel zu umständlich finde, ist schon der Grundansatz davon krank. Der Zustand des Clients gehört auf den Client. Wenn man gegen dieses Grundprinzip des Webs verstößt bezahlt man das durch teure und schlecht skalierende IT-Infrastruktur. Ich empfehle dir, das Buch über REST von Stefan Tilkov zu lesen. Danach will man sowas wie JSF nicht mehr benutzen und wenn doch, ist man sich zumindest sehr viel klarer über die Nachteile.

Also, lass dich nicht zu sehr von der Herde leiten, denn sie kann auch in die falsche Richtung laufen. Technologieentscheidungen werden in Unternehmen nicht immer auf der besten Grundlage getroffen ... #zitieren
Gravatar RPR 22.03.2010
um 23:35 Uhr Volle Zustimmung für Trepper und Sascha: Da gibts nichts mehr hinzufügen, danke! #zitieren
Gravatar Marc Teufel 23.03.2010
um 13:43 Uhr Sorry, ich kann Trepper noch nicht ganz zustimmen. Aber der Reihe nach. Das mit der Herde kann man so oder so sehen. Denn wenn wenn man einem Standard vertraut, läuft man nicht unbedingt einer Herde nach. Einen Standard zu vertrauen hat etwas mit Sicherheit, Zuverlässigkeit, Solidität und natürlich auch Investitionsschutz zu tun. Das könnte man jetzt nämlich auch so auslegen, als würde Trepper alle Standards in Frage zu stellen (Ich weiss er tut es nicht! :-) ). Aber gut, vielleicht ist es in meinem letztem Beitrag nicht richtig zur Geltung gekommen, mir geht es aber auch garnicht so sehr um den Standard. Mir geht es um die Vorteile, die ein Standard mit sich bringt. Ich möchte jetzt nicht alle nochmal aufzählen, kann man ja oben nachlesen. Mir geht es darum mein Projekt auf ein robustes, stabiles und langlebiges Fundament stellen zu können. Das ist der Kern. Welche Projekte habt Ihr umgesetzt mit Wicket? Oder GWT? Oder REST (obwohl REST für mich eher eine Technik für den Datenaustausch darstellt als ein Framework bzw. Fundament auf dass ich eine umfangreiche Geschäftsanwendung setzen könnte; wobei ich zugeben muss, dass ich das Tilkovsche Buch noch nicht kenne).
Erzählt doch mal ein bisschen aus Euren Projekten, aus Eurem Alltag mit den alternativen Technologien.

Trepper schreibt, dass er ja Standards eigentlich sinnvoll findet, nur der JSF-Standard an sich, also seine Umsetzung, wäre schlecht. Gleiches schreibt auch Sascha. Okay, zu sagen "JSF ist schlecht" ist die eine Seite, mich interessiert aber WAS ist schlecht an JSF ? Welche Probleme habt Ihr mit JSF gehabt? Fallstricke? Geht Euch der Standard nicht weit genug? Warum? Was fehlt Euch? Das sind die Informationen, die für mich interessant und relevant sind.

Vielleicht meldet sich auch mal ein Befürworter von JSF und schreibt von seinen Erfahrungen. Es soll kein Glaubenkrieg entstehen, lasst uns sachlich miteinander diskutieren. Ich bin gespannt wie sich das hier weiterentwickelt. #zitieren
Gravatar Holger 23.03.2010
um 15:43 Uhr oh... so stehe ich zwischen den Stühlen. Also vorab: Ja, ich verwende JSF und häufig sogar recht gerne. Zumindest wenn es darum geht, schnell ein gewünschtes Ziel zu erreichen, wenn Performance und Skalierbarkeit keine große Rolle spielen (das soll es glatt geben). Im Intranet-Umfeld muss man nicht gleich mit GWT schießen.

Die Diskussion aber finde ich sehr gut, denn die Kritik trifft exakt. Groß, schwerfällig, ein Müllhaufen an State wird auf den Client geschleppt (FireBug explodiert förmlich, wenn man sich die hidden Fields ansieht) und jedes mal an den Server übertragen wird. Nur mit vielen Tricks kann diesen Wust minimieren. Und wie da noch AJAX reinpassen will ist mir schleierhaft und in der Praxis der glatte Wahnsinn (s. RichFaces). Sowohl Client als auch Server erliegen am Herzinfarkt.

Auf der anderen Seite (s.o.) ist eine JSF incl. Facelets eine tolle Technologie, um einfach schnell aus fertigen Komponenten gute Lösungen zu bauen, die User mögen. Weniger der Standard als z.B. Primefaces. Einfach in den Werkzeugkasten greifen, zusammenstecken. Fertig.

Das ist die Krux dabei. Nur was soll ich tun? Gebt mir bitte ein Framework wie Wicket aber mit riesen Bibliotheken *lach*, dass auch noch sich direkt an anderen Technologien (z.B. Spring) einsteckt nebst großer Community. Im Moment fällt mir außer JSF eben nur wenig ein. #zitieren
Gravatar Trepper 23.03.2010
um 17:31 Uhr JSF verfolgt aus meiner Sicht einen grundsätzlich verkehrten Ansatz, der auch mit den Vorteilen eines Standards nicht aufgewogen werden kann. Es ist genauso falsch, wie es bei DOS falsch war, ein Betriebssystem ohne Speicherschutz zu entwickeln. Also richtig fundamental falsch! Das Grundproblem ist, dass der ganze Ansatz von JSF den Prinzipien des Webs zuwiderläuft. Der Clientzustand gehört auf den Client und nur auf den Client.

Wenn man gegen diese Grundprinzipien verstößt, um ein vermeintlich einfaches und komfortables Entwicklungsmodell zu bekommen, wird man das an anderen Stellen teuer bezahlen; zum einen durch nötige Trickserei beim Programmieren und zum anderen bei der Skalierbarkeit der Systeme.

REST sehe ich übrigens auch nicht als Framework an, sondern als einen Architekturstil, nämlich den Architekturstil des Webs. Darauf aufbauenend gibt es dann schöne Frameworks wie JAX-RS (bzw. Implementierungen davon wie Jersey).

Interessant dazu finde ich übrigens auch diesen Artikel über Wicket und GWT. http://blog.leonpennings.com/?p=76 Mit JSF wäre der Vorsprung von GWT noch krasser. #zitieren
Gravatar Sascha 23.03.2010
um 19:07 Uhr Hallo,

vorab: Ich finde es gut, das sich mittlerweile so eine Diskussion hier entwickelt hat, ich bin doch überrascht, wie sehr mein Ursprungs-Kommentar da einige Nerven sowohl positiv als auch negativ getroffen hat :-)

Um auch einige Dinge klarzustellen: Ich persönlich finde JSF als Idee nicht schlecht. Ich finde den Ansatz der Komponentenbibliotheken eine sehr gute Sache und mag es, das ich mir schnell neue Oberflächenkomponenten über externe Bibliotheken "dazustöpseln" kann. Genau hier fängt das Problem aber auch an: Mittlerweile benutze ich aus dem JSF-"Standard" nur noch die Oberflächenkomponenten. Für das Templating ist Facelets integriert, für flexible Navigationen Spring Webflow, für die Bean-Verwaltung Spring. Soviel zum "Standard".

Was mir zudem seltsam erscheint sind diese immer wiederkehrenden Artikel im JavaMagazin und auch hier, von denen über JSF als DIE Lösung gesprochen wird. Spreche ich mit Entwicklern, die JSF über Jahre in Projekten einsetzen (für mich ist ein "Projekt" an dieser Stelle eine Anwendung, in der mehr als ein Mannjahr Entwicklung steckt, KEINE 3-5 Seiten CRUD-Anwendungen, die gern als Referenz genommen werden!), bekomme ich genau die gleichen "Probleme" geschildert, die ich ja hier auch kommentiert habe. Darüber wird aber seltsamerweise weder im JavaMagazin noch hier in Artikeln noch auf Konferenzen wie der JAX gesprochen. Da ist immer alles super. Ist ja auch kein Wunder, sind ja auch immer die gleichen Autoren/Speaker, die da durch die Landen tingeln, und manchmal frag ich mich schon, wo da noch die relevante Praxiserfahrung herkommen soll, um solche Technologien tatsächlich objektiv zu betrachten (von der Tatsache, das man für eine objektive Beurteilung vielleicht nicht grad Core-Committer sein sollte sprech ich mal nicht).

Alles ist immer "total toll", der Standard ist jetzt noch besser, super neue Funktionen. Das streite ich auch nicht ab, für neue Projekte ist das sicher eine feine Sache. Gerne unterschlagen werden aber drei Punkte:

1. Viele Probleme von JSF 1.1 und 1.2 waren schon vorher bekannt und in anderen Frameworks auch schon entsprechend gelöst. Stichpunkt: Navigation und Wiederverwendbarkeit von Seiten und Seiten-Teilen. Im Standard (bis 1.2) wurde sich auf den kleinsten gemeinsamen Nenner geeinigt und der war schlicht eine inakzeptable Mischung von Struts 1 mit dem XML-Overhead von J2EE. Klar ist das jetzt im 2.0er anders, aber da sind wir bei Punkt 2:

2. Bis Dinge in den Standard wandern, vergehen Jahre. Stichwort AJAX-Unterstützung, Facelets. Ob ich in JSF 2.0 flexiblere und wiederverwendbare Navigationen a la Spring Webflow hinbekomme, hab ich ehrlich gesagt noch nicht angeschaut. Es kann aber nicht sein, das ich vier Jahre auf
geregelte AJAX-Unterstützung warten muss, Standard hin oder her.

3. Für ältere aber weiterlaufende Projekte ist es schwierig, das ganze ordentlich upzugraden, da meist eben schon andere Frameworks als "Workarounds" für die ganzen Schwächen so tief im System verankert sind, das man jetzt schauen muss, wie man das am Besten auf 2.0 bekommt. Aber vielleicht hab nur ich das Problem und/oder die Meinung, das sich auch ein langlaufendes Projekt technologisch weiterentwickeln muss :-)

Zu diesem ganzen Zirkus von wegen "JSF-CSS-Fähigkeiten" und der Qualität bzw. Prioritäten, die da innerhalb der Apache-JSF-Teams gesetzt werden, hab ich hier http://it-republik.de/jaxenter/artikel/Trinidad-goes-iPhone-2916.html schon was geschrieben. Ich bin immer noch verwundert, wieviel Relevanz dem Thema CSS und Styling dort zugesprochen wird. Wenn DAS die Probleme sind, die die JSF-Gemeinde bewegen, dann bitte ich um erhellende Aufklärung und Beispielprojekte aus der Industrie :-) #zitieren
Gravatar Trepper 23.03.2010
um 19:22 Uhr Das mit den stark eingefärbten Artikeln im Java-Magazin ist mir auch schon öfter aufgefallen. Das Schöne am Java-Magazin ist, dass es von Leuten geschrieben wird, die ganz nah an der Entwicklung der jeweiligen Technologien dran sind. Aber das Schlechte ist, dass diese Autoren nicht genug Abstand zur Technologie haben. Das Java-Magazin hat einfach keine richtige Redaktion, die den Inhalt selbst recherchiert oder zumindest kritisch prüft, so wie es etwa die c't macht.

Für die Autoren und ihre Technologien ist es eine schöne Plattform zur Selbstdarstellung und natürlich wollen sie sich auch nicht den Ast absägen, auf dem sie sitzen und erzählen so immer wieder wie toll doch alles ist. Wenn JSF 2 jetzt so viel besser ist, warum haben genau DIESE Autoren, dann nicht mehr über die Macken von JSF 1x geschrieben?! Ich kann mich an einen einzigen kritischen Artikel zu JSF im Java-Magazin erinnern und der kam nicht von den üblichen Verdächtigen. Das ist armseliger "Journalismus" (dieses Wort mag ich hier gar nicht benutzen). #zitieren
Gravatar RPR 23.03.2010
um 21:35 Uhr "Amseliger Journalismus" wie von Trepper beschrieben:
Genau das bemängele ich bereits seit einiger Zeit - sowohl im Magazin als auch hier im Portal.
Warum? Weil ich immer noch hoffe, dass die früheren glücklichen Zeiten wieder kommen, in denen ich kaum erwarten konnte, das nächste Heft zu lesen.
Was steht heute drin:
"Wie schaffe ich ein HelloWorld trotz Einsatz von Spring-Technologie X (von Eberhard)"
"Warum die Verwendung von EJB 3 nun endlich angeblich dem Nichtverwenden von EJB das Wasser reichen kann"
"Die nächste vollkommen abstrakte Sicht auf SOA" (Btw.: http://www.gregthearchitect.com/episode_SOA_this.html immer noch sehr sehenswert!)
"Spring-Batch: Wie ich ein paar Zeilen Datenaustausch innerhalb von 2 Jahren programmiert habe (Freund von Eberhard)."
"IBM / Oracle / XYZ BPM-Bloatware: Damit schützen Sie sich bis zur Rente vor weiterer Programmiertätikeit"
"Business-Process-Rules-Hype XXX - So bringen Sie die Kollegen von der Fachabteilung ganz sicher selbst zum Programmieren" (ganz sicher)
"Eberhard erklärt Ihnen, warum Spring immer besser als ein Standard ist"
"Warum Entwickler in 5 Jahren keine Arbeit mehr in Deutschland haben werden (wir helfen Ihnen beim Outsourcing nach Indien, ganz billig, keine Schleichwerbung")
"Faces-Tales: So erstellen auch Sie eine imperformante Franken-GUI - Heute: das Hello-World wird fertig"
"Endlich: Spring-Chunk-Maker in rc 21 erschienen : Das Prerelease 3.0.alpha.0.1.rc21 ist da! Was bringts neues? Fast so geil wie ich selbst (von Eberhard)"
Usw. usw.

Wie gesagt: Mir blutet das Herz immer mehr: Das Java-Magazin gehörte für mich jahrelang zum Berufsleben wie kaum etwas anderes - es verkörperte wie kaum etwas anderes die "Generation Java". Ich freute mich jahrelang jeden Monat auf endlich wieder viele gute Themen die ich brauchen konnte. (Besonders mochte ich die Open-Source-Perlen).
Heute blättere ich das Teil durch, such etwas, das für meine Arbeit relevant ist und finde kaum was.
50 % der Seiten sind Werbung.
Ich fang dann doch den ein oder anderen Artikel zu lesen an, ärgere mich (s.o.), suche weiter, nichts interessantes, OK, der JDK-7-Report ist noch halbwegs interessant, der Bericht über JavaFX entsprach demwas ich wusste - das Heft landet nach max. 15 Minuten im Papierkorb.
Bin trotzdem noch Abonnement - unverbeserlicher Optimist, es könnte ja wieder besser werden...
Deswegen - und weil Kritik ja konstruktiv sein soll: Bringt doch mal wieder davon:
- Praxisbericht: So stelle ich auf GIT (oder Mercurial) um - Servereinrichtung, IDE und Build.
- Open-Source-Perlen: XXX
- Classfish embedded: Schlankes direktes Starten und Debugging.
- Web-GUI heute: Tipps und Tricks zu Vaadin
- Filthy Rich Clients: Solche Tabellen sieht der Anwender gerne
- Das gescheiterte Projekt: Warum unsere Firma noch immer keinen (funktionierenden) ESB hat.
- SAP-Basis: ...
- JPA 2 mit Hibernate: Status Quo.
- Erfahrungsbericht: Migration JPA von Hibernate zu EclipseLink.
- E-Commerce-Strategien: Heute Ikea in China
- Funktionierende SOA: Das Fangen Sie mal klein an. #zitieren
Gravatar Trepper 23.03.2010
um 22:29 Uhr @RPR ich musste lachen bei deiner Java-Magazin-Parodie, leider ist die Lage wie beschrieben! Statt ein kritisches Fachmagazin zu sein, ist das Javamagazin zur Selbstdarstellungs- und Werbeplattform verkommen. Kritische Betrachtungen? Fehlanzeige. Gut gefallen mir die gelegentlichen Grundlagenartikel wie über das Speichermanagement und das ein oder andere vorgestellte Framework finde ich auch interessant, aber dahinter fehlt einfach eine Redaktion, die auf eine Linie, eine gute Themenmischung und vor allen Dingen auf Qualität achtet. Dieses ganze Spring-Geblubber kann ich auch nicht mehr lesen! Das Java-Magazin liest sich ja schon fast wie die Hauspost von SpringSource, obwohl ich nicht abstreiten will, dass der Laden ein paar gute Ideen hat und die auch gut umsetzt, aber es nervt einfach!

Vielleicht sollte die Redaktion einfach mal stärker die Leserschaft befragen, was sie interessiert, statt die 100. Folge von Spring zu bringen. #zitieren
Gravatar Trepper 24.03.2010
um 09:27 Uhr A critic view on JSF Framework
http://webmoli.com/2008/04/28/a-critic-view-on-jsf-framework/ #zitieren
Gravatar Sascha 24.03.2010
um 12:03 Uhr Ja,

leider viel Wahres dran. Zu der sehr Spring-lastigen Berichterstattung gesellt sich noch der hohe OSGi-Anteil. Auch hier immer sehr positive Berichterstattung, wenig bis gar nichts kritisches. Dritter grosser Punkt ist "Agilität". Zu 95 Prozent besteht auch die JAX aus diesen Themen. Ist man kein Mitarbeiter oder "Bekannter" der entsprechenden Firmen/Kollegen, hat man schon keine Chance, einen Beitrag auf dieser Konferenz zu platzieren. Ist jedenfalls mein Eindruck, wenn man sich die Speaker-Listen der vergangenen Jahre mal so anschaut. Die albernen "Sorry, aber versuchen Sie es gern nächstes Mal wieder mit einer Einreichung"-Mails kann man sich da auch sparen. Ohne zumindest nem Hinweis, was jetzt nicht passte, nützt es nichts.

Als Ergänzung noch zu den lustigen wiederkehrenden Themen im Java-Magazin. Ich finde die "Ich hab hier Tool xyz, beschreibe langwierig und langweilig, wie man das Zip entpackt und was da für Verzeichnisse existieren, dann machen wir einen Mini-Aufruf, der 0,005% der Funktionen mal zeigt und danach folgt direkt eine Bewertung des Nutzens und der Zukunft des Tools"-Artikel vom immer gleichen Autor auch faszinierend. Die sind so nach Schablone geschrieben und inhaltsleer, das ich mich frage, wo da die Aufwertung zur jeweiligen offiziellen Tool-Dokumentation im Internet bestehen soll, die ich von einem Fachmagazin erwarte.

"Früher" (ja, da war alles besser ;-)) bin ich im JavaMagazin teilweise über echte Perlen gestolpert und konnte ne Menge Infos draus ziehen. Die Erfahrungsberichte waren "ehrlich", Technologien wurden kritisch begutachtet. Irgendwann ist da aber irgendwas gekippt und das JavaMagazin wurde zum Werbemedium für die JAX-Sponsorfirmen und regular Speaker. Mittlerweile überlege ich mir auch ernsthaft, das Abo zu kündigen, da ich mich des Eindrucks nicht erwehren kann, das ich als Leser für dumm gehalten werde. Vielleicht denkt man einfach, das das Niveau der Leserschaft nicht so richtig hoch ist? #zitieren
Gravatar RPR 24.03.2010
um 13:53 Uhr wow - ich dachte schon, ich würde mit meiner kritischen Betrachtung nieder gemacht hier - aber durch die zusätzlichen Infos sehe ich nun langsam durch:

Werbeplattform für JAX- und sonstige Sponsoren.

Das erklärt vieles.
Auch die dümmlichen Quick-Votes in letzter Zeit hier.
Welche Alternativen gibt es? Hab früher auch mal das Java Spectrum gelesen - das enthielt damals aber fast nur Selbstbeweihräucherungen von selbsternannten Java-Consultant-Meistern. Also auch vollkommen kritiklos.
Ist das besser geworden?
Was gibts sonst noch? #zitieren
Gravatar Trepper 24.03.2010
um 13:57 Uhr Die Redaktion, bzw. das was davon übrig ist, hat offensichtlich gemerkt, dass man so sehr billig ein Heft machen kann und es immer noch genug Leute gibt, die es lesen. Für mich ist auch noch genug interessantes drin, um das Abo zu behalten, aber glücklich bin ich damit trotzdem nicht. Vielleicht sollte man ein _richtiges_ Entwickler-Magazin online aufmachen. Damit das ganze nicht in reine Selbstdarstellung abdriftet, sollte jeder Artikel von einem Lektor begleitet werden, der ansonsten keine Verbindung zum Autor hat. Bloß Geld damit zu verdienen könnte schwierig werden ... #zitieren
Gravatar RPR 24.03.2010
um 15:32 Uhr Online-Magazin: Das wär doch mal was! Ich wäre dabei und würde auch Zeit dafür opfern - wär doch mal wieder was sinnvolles! #zitieren
Gravatar Trepper 24.03.2010
um 17:26 Uhr Ein weiteres Indiz, dass JSF nicht wirklich "hipp" ist, gibt es auch hier: http://www.hiprank.com/gwt-vs-jsf-vs-wicket.html #zitieren
Gravatar Trepper 25.03.2010
um 16:52 Uhr "JSF ist kalr spezifikationsgetrieben. Das Fähnchen "Standard" wird so hoch gehalten, dass man weitverbreitete Problemfälle aus der Praxis nicht rechtzeitig wahrnimmt und im Standard vernachlässigt."
http://www.dpunkt.de/buecher/2921.html Seite 6 #zitieren
Gravatar Eberhard Wolff 26.03.2010
um 11:13 Uhr
RPR:
"Wie schaffe ich ein HelloWorld trotz Einsatz von Spring-Technologie X (von Eberhard)"
"Spring-Batch: Wie ich ein paar Zeilen Datenaustausch innerhalb von 2 Jahren programmiert habe (Freund von Eberhard)."
"Eberhard erklärt Ihnen, warum Spring immer besser als ein Standard ist"
"Endlich: Spring-Chunk-Maker in rc 21 erschienen : Das Prerelease 3.0.alpha.0.1.rc21 ist da! Was bringts neues? Fast so geil wie ich selbst (von Eberhard)"


Beeindruckend. Ich habe in 2009/2010 folgende Artikel im Java Magazin gehabt:
JSR 330 (siehe da - ein Artikel über einen Standard!) (3/2010)
Spring 3.0 (11/2009)
Spring 3.0M1 (5/2009)
Weihnachtsbuch (2/2009)

Ich finde es schade, dass so etwas einen solchen Kommentar und zudem noch anonym nach sich zieht. #zitieren
Gravatar Redaktion JAXenter 26.03.2010
um 11:31 Uhr Wir bitten alle Kommentatoren ausdrücklich, zur Sachlichkeit der Diskussion zurückzukehren. Konstruktive Kritik sowohl an der Sache als auch am Portal ist willkommen - persönliche Angriffe und böswillige Bemerkungen schaden hingegen allen, die von den Inhalten auf JAXenter profitieren möchten. #zitieren
Gravatar Sascha 26.03.2010
um 18:34 Uhr Hallo,

@Redaktion: Zustimmung zum Thema "persönliche" Angriffe.

Nichtsdestotrotz würde mich aber die Meinung der Redaktion zu der entsprechenden Kritik interessieren, das durchaus häufig zentral in ein Projekt (JSF, Spring, whatever, ist jetzt wirklich nicht auf diese beiden Technologien begrenzt) involvierte Personen sowohl über entsprechend positiv gefärbte Artikel im JavaMagazin, als auch als Speaker mit Beiträgen gleicher positiven Färbung auf der JAX vertreten sind? Es aber andersrum echt schwierig wird, kritische Auseinandersetzungen mit den jeweiligen Technologien zu finden, die von "Machern/Architekten/Senior-Developern" aus der Industrie kommen, die diese Technologien dann in grossen Projekten einsetzen und nicht nur in Hello-World-Demoszenarien?

Ich kann irgendwie nicht glauben, das es diese Leute entweder nicht geben soll oder diese keine Artikelvorschläge oder Konferenzbeiträge einreichen. :-) #zitieren
Gravatar Trepper 27.03.2010
um 10:23 Uhr Ich fände die Meinung der Redaktion auch interessant, zumal im Laufe der Diskussion deutlich herausgekommen ist, dass viele die Subjektivität der Artikel als nachteilig empfinden. Wenn Spring sich z. B. immer selbst darstellt, wird kaum kritisiert werden, dass die XML-Konfiguration aufgeblasen und altbacken ist und das auch das Java-Config-Projekt nicht völlig verhindern kann. In einem objektiveren Artikel würde wohl auch auf andere Ansätze wie CDI (Weld) eingegangen. #zitieren
Gravatar DeveloperKnight 30.03.2010
um 09:50 Uhr Ich muss mich jetzt hier doch mal zu Wort melden.
Wenn ich mir diesen ganzen "Thread" durchlesen, überkommt mich doch ein sehr bedenkliches Gefühl. Es wird gemeckert und gejammert, warum angeblich ständig die gleichen Leute irgendwelche Artikel verfassen, und JSF ist ja vollkommen Praxis-untauglich und ist nur im Kommitee entworfen usw. usw.

Gerade zum Thema der Artikel kann ich nur sagen: Dann reicht doch eigene Artikel mit eigenen Themen bei der Redaktion ein.

Was ich wirklich sehr bedenklich finde ist die Tatsache, dass sehr viele hier der Meinung sind, andere bauen ihnen ein tolles Framework, was dann kostenlos genutzt werden kann. Oder das Framework soll eine allumfassende Plugin-Unterstützung haben, am besten gleich mit allen hippen AJAX-Komponenten, die man dann nur noch zusammen stecken kann und gut isses.
So funktioniert das aber nicht.

Von daher möchte ich hier mal anregen, den Ball etwas flacher zu halten und mal zu überlegen, wer eigentlich die ganze Arbeit macht, über die hier so lautstark hergezogen wird.

Jammern und meckern ist einfach, aber die Dinge anpacken und besser machen, das können die wenigsten.
Nur mal so als Denkanstoß... #zitieren
Gravatar Sascha 30.03.2010
um 12:06 Uhr @Developer:

Erstmal vorab: Ich erwarte nicht, das mir jemand hippe Frameworks baut. Du kannst auch davon ausgehen, das zumindest ich diverse Open-Source-Projekte schon mit Bug-Meldungen sowie Feature-Vorschlägen unterstützt habe, Artikel im Java-Magazin veröffentlicht und auch Konferenzbeiträge eingereicht habe (die aber abgelehnt wurden, um Fehlinterpretationen hier zu vermeiden). Mir ist aber nicht bekannt, das man erst mit einer entsprechenden "Vita" dazu berechtigt wäre, konstruktive Kritik zu äussern, aber ich denk dann einfach mal, das ich dann das Recht dazu habe. :-)

Das ich kein Anrecht auf super-duper-geile Frameworks habe ist mir bewusst, darum ging es zumindest in meiner Kritik aber auch nicht. Mich nervt es nur, wenn die Leute in den entsprechenden Steuer-Gremien (sei es für Standards oder für sonstige Bibliotheken) die Zeit verschlafen und jahrelang Dinge hochloben, die schon zum Zeitpunkt ihres Entstehens veraltet waren (bezogen auf den JSF-Standard) und dann mit der neuen Version, die dann endlich mal einen gescheiten Stand erreicht hat, so tun, als ob alles schon immer so gut gewesen wäre.

Wenn ich X Eur für eine Fachzeitschrift bezahle, erwarte ich, das sie sich objektiv mit solchen Themen befasst und nicht geprägt wird von schönfärbenden Artikeln der jeweiligen in das Projekt involvierten Personen, die auch gesetzte Speaker auf den vom gleichen Verlag veranstalteten Konferenzen sind. Die c't und die iX schaffen es ja auch, trotz einer Vielzahl von freien Autoren, die Objektivität im Auge zu behalten bzw. zu wahren.

Und jetzt bitte kein "dann kündige doch das Abo"-Hinweis, sowas ist genauso deplaziert wie "wenn's dir nicht passt, mach's doch selbst". Sowas kann man bei Projekten wie Wikipedia erwarten, nicht aber bei Fachzeitschriften und Fachkonferenzen, bei denen man für entsprechend aufbereitete Inhalte teilweise nicht wenig Geld bezahlt. Und da darf und kann ein zwischen den Ohren gesunder Mensch durchaus mal hinterfragen, was er da für sein Geld (oder das der Firma) eigentlich bekommt (ausser X Tage Hotel in einer anderen Stadt ;-))

Und zum Grundsätzlichen: Wenn man sich den Thread hier mal ordentlich durchliest, wird durchaus überwiegend konstruktiv Kritik geübt. Das als "jammern und meckern" oder "herziehen" zu verstehen, ist schon arg seltsam und zeugt von einer merkwürdigen Definition des Begriffs "Kritik", die vielleicht mal Grundlage einer Neubetrachtung sein sollte. #zitieren
Gravatar PGTaboada 31.03.2010
um 22:58 Uhr Sorry wenn ich mich mit diesem Kommentar nicht an der aktiven Diskussion einklinke, aber was bitte schön habe ich da ganz oben gelesen?

"Die ganzen Bibliotheken stellen gerade auf JSF2.0 um und stellen ihre "Macken" als Bugs gegen die Spezifikation und die Implementierungen ein."

Kann man dazu noch mehr lesen?

JSF hin oder her - mein größtes Problem mit JSF aktuell ist das es zum Standard erkoren wurde. Und somit steht sich JSF zu oft selber im Weg, denn der blaue Appserver kommt dummerweise schon mit JSF. Und ja, ich könnte da auch die RI austauschen, parent-first auschalten, etc - aber dann funktionieren leider meine bestehenden Anwendungen nicht mehr. Und ich freue mich heute schon auf die nächste Version, denn eins ist bei den Java EE Specs sicher: drop-in-replacements kennen wir nicht.

ps: Artikel schreiben für so ein gemischtes Publikum ist sehr schwierig, und das sage ich aus eigener Erfahrung. #zitieren
Gravatar PGTaboada 31.03.2010
um 23:19 Uhr Und JSF hört dann auf "Standard" zu sein, wenn ich mich für eine Bibliothek entschieden habe...
Bitte korrigiert mich wenn ich mich irre, aber wo ist mein "Standard-Mehrwehrt" wenn ich zwar einen standardisierten Komponentenmodell fahre, aber die angebotenen Komponenten nicht austauschbar sind, weil sie unterschiedliche Features, Programmiermodelle und Laufzeitverhalten haben?

Wer garantiert mir, das RichFaces 4.0 jemals weiter als "alpha/beta" kommen wird? Was ist mit IceFaces - wie gut geht es IceSoft? Wie gut geht es denen Morgen? Wie gross sind die Communities hinter den einzelnen Komponentenbibliotheken?

LOL! 7x1 = 7 soll falsch sein! Jetzt probiere ich 9-7 = 2, mal sehen ob es jetzt durchgeht... #zitieren
Gravatar BR 07.04.2010
um 20:20 Uhr Also Leute ich war lange Zeit nicht so nah an der Web-Entwicklung mit Java. Vor einem halben Jahr hatte ich dann Gelegenheit mit JSF 1.2 eine kleine Anwendung zu schreiben. Und ich würde sagen, dass ist gar nicht so schwer. Ich hätte mir übrigens gewünscht schon JSF2.0 einsetzen zu können. Wirklich enttäuschend ist, dass JSF erst so spät gekommen sind, dass wir heute schon eine lächerliche Inflation an Web-Frameworks haben, dass so viel Kraft und Zeit vergeudet wurde. [Beispielhaft wurden JSF u.a. von der im JCP blockiert abgelehnt, weil es doch Struts (damals noch in Version 1) gebe.]
Also zusammen gefasst: Es Sinn einen starken Standard zu haben - und mit JEE5 und JEE6 hat Java gerade noch nicht Kurve gekriegt. #zitieren
Gravatar Sascha 12.04.2010
um 16:30 Uhr @BR:

Es ist auch mit JSF 1.1 nicht "schwer" eine kleine Anwendung zu bauen und natürlich wird es (in der Regel) mit jeder neuen Version eines Standards "einfacher". Problem bei diesen Standards ist aber, das die "richtigen" Probleme eben in grossen Anwendungen auftreten und "stören".

"Kleine" Anwendungen kann ich mit dutzenden Web-Frameworks bauen. Eine "grosse", die über mehrere Jahre supported und weiterentwickelt wird, durchaus häufig von mehr als einem Entwickler, baut man eher mit einem Standard. Und genau hier offenbaren sich eben diverse Probleme, die ja hier mittlerweile ausführlich beschrieben wurden.

JSF 1.1 gibt es seit 2004 und hatte einen Funktionsumfang, der viele Probleme, die in anderen Frameworks schon gelöst waren, neu in einen "Standard" gegossen hat. Da von "stark" zu reden...Nuja :-) #zitieren
Gravatar PGTaboada 12.04.2010
um 18:23 Uhr JSF Ist Standard - ja.

Aber: JSF hört dann auf "Standard" zu sein, wenn ich mich für eine Bibliothek entschieden habe... Und die Unternehmen/ Entwickler die schliesslich aktiv an den einzelnen Komponentenbibliotheken arbeiten haben ganz eigene Vorstellungen über Design und Programmiermodell Ihrer Komponenten, und nicht selten haben Sie ganz eigene wirtschaftliche Probleme.

Bitte korrigiert mich wenn ich mich irre, aber wo ist mein "Standard-Mehrwehrt" wenn ich zwar einen standardisierten Komponentenmodell fahre, aber die angebotenen Komponenten nicht austauschbar sind, weil sie unterschiedliche Features, Programmiermodelle und Laufzeitverhalten haben?

Wer garantiert mir, das RichFaces 4.0 jemals weiter als "alpha/beta" kommen wird? Was ist mit IceFaces - wie gut geht es IceSoft? Wie gut geht es denen Morgen? Wie gross sind die Communities hinter den einzelnen Komponentenbibliotheken?

Dann muss ich mich natürlich auch noch freuen, dass JSF so tief im AppServer integriert ist, das ich erstmal eine volle Migration durchführen muss, um in den Genuß von JSF 2.0 zu kommen. Und dann kann ich es nichtmal gezielt für eine Anwendung verwenden, nein, ich darf gleich alle Anwendungen auf das neue Standard hochziehen. Und bitte kommt mir nicht mit "das tolle an J(x)EE ist die Rückwärtskompatibilität" - denn das hat, wenn überhaupt - nur bei HelloWorld-Anwendungen funktioniert.

Gerade in Bezug auf JSF gibt es nicht schlechteres als "Standard" zu sein. Manager und Entscheider werden vor falschen Tatsachen gestellt und die Entwickler dürfen den Kampf mit dem Betrieb ausfechten.

Nein danke. #zitieren
Gravatar rn2540@gmail.com 12.04.2010
um 20:59 Uhr @Sascha, also mittlerweile ist JSF endlich bei 2.0 angekommen, und ich weiß' auch von durchaus JSF-Projekten / Produkten, in die mehrere Personenjahre eingeflossen sind - und nicht nur für die Fehlerbehebung bzw. den Kampf gegen das Framework. Ach ja - und jede Abend bete ich, dass niemals eine Struts 1 Anwendung übernehmen muss.

@PGTaboada, gebe dir in insofern Recht, dass ich aktuell nur ein supportetes / kommerzielles JSF-Framework empfehlen würde. Ich würde sogar ausdrücklich gegen irgendwelche alpha oder beta-JSF-Implementierungen votieren. Jedenfalls sofern die Anforderungen zwingend solche instabilen Implementierungen voraussetzen.
Deine anderen Argumente (Migrationsthematiken, tief in AppServer integriert, Kampf mit dem Betrieb) gegen JSF, JEE sind mir zu unspezifisch. Das sind doch Standardthemen :-) #zitieren
Gravatar Pgtaboada 12.04.2010
um 22:11 Uhr Ja, es sind Standard-Fragen.
Ich allerdings sehe die Tatsache das JSF ein JxEE Standard ist aktuell als groesstes JSF Problem - und inzwischen auch stärkstes Gegenargument. Meine Erfahrung mit JxEE ist die, dass das Prädikat "Standard" leider kein Qualitaetsmerkmal darstellt. #zitieren
Gravatar Sascha 13.04.2010
um 16:20 Uhr @rn2540: Ich habe auch nicht bestritten, das es Projekte gibt, in die mehrere Personenjahre eingeflossen sind, zumal ich selbst eins verantworte. Nichtsdestotrotz denke ich aber, das, wenn man sich Gedanken um seine Architektur und über Wiederverwendbarkeit macht (auch von Seiten/Seitenteilen), bei JSF 1.1 und 1.2 nicht umhin kam, essentielle Teile des Standards auszutauschen bzw. zu ergänzen. (Webflow/Facelets). Und ich sag mal so: Templating von Seiten oder dynamische Navigationen waren 2004 schon keine futuristischen "Braucht-Keiner" mehr, so das man da durchaus auch schon einen etwas kompletteren Standard 1.1 (oder auch 1.2) hätte erwarten können. Von Ajax in einer späteren Version sprech ich jetzt mal nicht.

Man fängt bei diesen Standards immer bei 100% Features (die Summe aller nützlichen Features, die man aus anderen Frameworks/Bibliotheken schon kennt) als Nice-to-Have an. Dann stellt man fest, das man das in einer ersten Version gar nicht schaffen kann, und einigt sich runter auf 50%. Von da aus wird dann jahrelang rumdiskutiert, welches die nächsten 25% sein sollen, implementiert die und kommt mit der nächsten Version raus. Mittlerweile dreht sich die Welt aber weiter. Ich gestehe einem Standard zu, das er immer ein wenig hinterherläuft, solch lange Zyklen wie bisher beim JSF-Standard sind aber schlichtweg lächerlich.

@Papick: Naja, man kann JSF ja weiterhin losgelöst aus dem JxEE-Standard benutzen und hat damit dann unter Tomcat zumindest diese Problemchen nicht. Aber grundsätzlich geb ich dir Recht. #zitieren
Gravatar andy 01.06.2010
um 10:59 Uhr Hallo,

die kritische Betrachtungen von JSF finde ich sehr aufschlussreich, zumal die meisten Artikel (wie bereits angesprochen) wenig von wirklich objektiver Kritik beinhalten.
Allerdings interessiert mich eure Meinung, welche wirklich ernst zunehmende Alternative zu JSF ihr "empfehlen" würdet und warum?
Ist es nicht auch so, dass wenn ich JSF (2.0) und bspw. die Komponentenbibliothek RichFaces mit Spring WebFlow (oder evtl. auch Seam) kombiniere, viele Nachteile von JSF "umgehe"? Mal abgesehen davon, dass damit viele Teile des Standards nicht mehr zum tragen kommen, aber durch Spring WebFlow die Kombination eines QuasiStandards mit einem offiziellen Standard zwar nicht DIE, aber zumindest eine gute Lösung hat? Mich würde eure Meinung hierzu interessieren, vorallem das WARUM NICHT und WAS SONST!? #zitieren
Gravatar PGtaboada 01.06.2010
um 12:26 Uhr Frag 5 Entwickler und du bekommst 5 Antworten. Hier ist meine:

Ich habe mit GWT sehr gute Erfahrungen gemacht. Die Anforderungen an die Betriebsinfrastruktur sind minimal. Das Programmiermodell ist sehr einfach zu lernen, gehört zu den Frameworks die sich am wenigsten Sorgen machen müssen um Finanzierung oder Zukunft, etc. #zitieren
Gravatar andy 01.06.2010
um 12:52 Uhr
PGtaboada:
Frag 5 Entwickler und du bekommst 5 Antworten.

Das ist mir schon bewusst, zumal ich denke, dass eine solche Entscheidung nie wirklich objektiv getroffen werden kann und enorm von den speziellen Anforderungen abhängt.

Aber um nochmals auf das auch angesprochene Thema JSF und SWF (Spring WebFlow) zurückzukommen:
Könnte nicht die Kombination von JSF mit bspw. Spring bzw. SWF oder anderen bewährten Frameworks, die bestimmte Nachteile von JSF beheben und die Vorteile von JSF nutzen oder sogar "bestärkten", JSF so "attraktiv" machen?! #zitieren
Gravatar Pgtaboada 01.06.2010
um 13:37 Uhr Du kannst mit SWF nur das machen, wofür SWF gedacht wurde. Wenn du mit SWF Probleme lösen willst und JSF attraktiver machen willst, dann ist die Antwort auf deine Frage nur dann JA, wenn deine Probleme im Bereich Navigation und Conversational-Scopes liegt. Wie du selber geschrieben hast: die Probleme mit einem Framework entstehen erst durch spezielle Anforderungen.

Kennst du deine Anforderungen, dann kann dir mit einem Workshop geholfen werden. Kennst du Sie nicht, musst du Münze werfen (z.Bsp. Durch Aussagen wie "wir bleiben beim Standard") oder deine Anforderungen erstmal rausfinden. #zitieren
+ Neuen Kommentar verfassen

Folgende Links könnten Sie auch interessieren