Was sind die Hauptnachteile von Java Server Faces 2.0?

Gestern habe ich eine Präsentation zu Java Server Faces 2.0 gesehen, die wirklich beeindruckend aussah, obwohl ich derzeit ein glücklicher ASP.NET MVC / jQuery-Entwickler bin. Was mir an JSF am besten gefallen hat, war die große Anzahl von AJAX-fähigen UI-Komponenten, die die Entwicklung viel schneller zu machen scheinen als mit ASP.NET MVC, insbesondere auf AJAX-lastigen Sites. Integrationstests sahen auch sehr gut aus.

Da in der Präsentation nur die Vorteile von JSF hervorgehoben wurden, würde ich gerne auch von der anderen Seite hören.

Meine Fragen sind also:

• Was sind die Hauptnachteile von Java Server Faces 2.0?
• Was könnte einen JSF-Entwickler dazu bringen, ASP.NET MVC anstelle von JSF zu verwenden?

JSF 2.0 Nachteile? Ehrlich gesagt, abgesehen von der relativ steilen Lernkurve, wenn Sie keine soliden Hintergrundkenntnisse über die grundlegende Webentwicklung (HTML / CSS / JS, Server- gegenüber Client-Seite usw.) und die grundlegende Java-Servlet-API (Anforderung / Antwort / Sitzung) haben , Weiterleitung / Weiterleitung usw.) fallen keine ernsthaften Nachteile ein. JSF muss in seiner aktuellen Version immer noch das negative Image beseitigen, das es in den frühen Jahren gewonnen hat, in denen es mehrere schwerwiegende Nachteile gab.

JSF 1.0 (März 2004)

Dies war die erste Veröffentlichung. Es war voller Fehler sowohl im Kern- als auch im Leistungsbereich, über die Sie nichts wissen möchten. Ihre Webanwendung funktionierte nicht immer so, wie Sie es intuitiv erwartet hatten. Sie als Entwickler würden weinend davonlaufen.

JSF 1.1 (Mai 2004)

Dies war die Bugfix-Version. Die Leistung wurde noch nicht wesentlich verbessert. Es gab auch einen großen Nachteil: Sie können HTML nicht fehlerfrei in die JSF-Seite einbinden. Alle einfachen Vanille-HTML-Dateien werden vor dem JSF-Komponentenbaum gerendert . Sie müssen alle einfachen Vanillen in <f:verbatim>Tags einschließen, damit sie in den JSF-Komponentenbaum aufgenommen werden. Obwohl dies der Spezifikation entsprach, wurde dies vielfach kritisiert. Siehe auch ua JSF / Facelets: Warum ist es keine gute Idee, JSF / Facelets mit HTML-Tags zu mischen?

JSF 1.2 (Mai 2006)

Dies war die erste Veröffentlichung des neuen JSF-Entwicklungsteams unter der Leitung von Ryan Lubke. Das neue Team hat großartige Arbeit geleistet. Es gab auch Änderungen in der Spezifikation. Die wichtigste Änderung war die Verbesserung der Ansichtsbehandlung. Dadurch wurde JSF nicht nur vollständig von JSP getrennt, sodass eine andere Ansichtstechnologie als JSP verwendet werden konnte, sondern Entwickler konnten auch einfaches Vanille-HTML in die JSF-Seite einbinden, ohne sich mit <f:verbatim>Tags herumschlagen zu müssen . Ein weiterer Schwerpunkt des neuen Teams war die Verbesserung der Leistung. Während der Lebensdauer der Sun JSF-Referenzimplementierung 1.2 (die seit Build 1.2_08 um 2008 den Codenamen Mojarra trug) wurde praktisch jeder Build mit (größeren) Leistungsverbesserungen neben den üblichen (kleinen) Bugfixes ausgeliefert.

Der einzige schwerwiegende Nachteil von JSF 1.x (einschließlich 1.2) ist das Fehlen eines Bereichs zwischen dem Anforderungs- und dem Sitzungsbereich , dem sogenannten Konversationsbereich . Dies zwang Entwickler dazu, sich mit versteckten Eingabeelementen, unnötigen DB-Abfragen und / oder Missbrauch des Sitzungsbereichs zu beschäftigen, wenn die ursprünglichen Modelldaten in der nachfolgenden Anforderung beibehalten werden sollen, um Validierungen, Konvertierungen, Modelländerungen und Aktionsaufrufe erfolgreich zu verarbeiten komplexe Webanwendungen. Der Schmerz könnte gelindert werden, indem eine Bibliothek eines Drittanbieters verwendet wird, die die erforderlichen Daten in der nachfolgenden Anforderung wie MyFaces Tomahawk- <t:saveState> Komponente, JBoss Seam- Konversationsumfang und MyFaces Orchestra speichert Gesprächsrahmen.

Ein weiterer Nachteil für HTML / CSS-Puristen besteht darin, dass JSF den Doppelpunkt :als ID-Trennzeichen verwendet, um die Eindeutigkeit des HTML-Elements idin der generierten HTML-Ausgabe sicherzustellen , insbesondere wenn eine Komponente in der Ansicht mehrmals verwendet wird (Vorlagen, iterierende Komponenten usw.). . Da dies ein unzulässiges Zeichen in CSS-Bezeichnern ist, müssten Sie das verwenden \, um den Doppelpunkt in CSS-Selektoren zu umgehen, was zu hässlichen und seltsam aussehenden Selektoren wie #formId\:fieldId {}oder gerade führt #formId\3A fieldId {}. Siehe auch Verwendung der von JSF generierten HTML-Element-ID mit Doppelpunkt ":" in CSS-Selektoren. Wenn Sie jedoch kein Purist sind, lesen Sie auch Standardmäßig generiert JSF unbrauchbare IDs, die nicht mit CSS-Teilen von Webstandards kompatibel sind .

Außerdem wurde JSF 1.x nicht sofort mit Ajax-Funktionen ausgeliefert. Kein wirklicher technischer Nachteil, aber aufgrund des Web 2.0-Hype in dieser Zeit wurde es zu einem funktionalen Nachteil. Exadel war früh dran , Ajax4jsf einzuführen, das im Laufe der Jahre gründlich entwickelt wurde und zum Kernbestandteil der JBoss RichFaces- Komponentenbibliothek wurde. Weitere Komponentenbibliotheken wurden ebenfalls mit integrierten Ajax-Funktionen ausgeliefert, wobei ICEfaces bekannt ist .

Ungefähr zur Hälfte der Lebensdauer von JSF 1.2 wurde eine neue XML-basierte Ansichtstechnologie eingeführt: Facelets . Dies bot enorme Vorteile gegenüber JSP, insbesondere im Bereich des Templating.

JSF 2.0 (Juni 2009)

Dies war die zweite Hauptversion mit Ajax als Schlagwort. Es gab viele technische und funktionale Änderungen. JSP wird durch Facelets als Standardansichtstechnologie ersetzt, und Facelets wurde um Funktionen zum Erstellen benutzerdefinierter Komponenten mit reinem XML (den sogenannten Composite-Komponenten ) erweitert. Siehe auch Warum werden Facelets ab JSF2.0 als Ansichtsdefinitionssprache JSP vorgezogen?

Ajax-Kräfte wurden im Geschmack der <f:ajax>Komponente eingeführt, die viele Ähnlichkeiten mit Ajax4jsf aufweist. Anmerkungen und Verbesserungen bei der Konvention über die Konfiguration wurden eingeführt, um die ausführliche faces-config.xmlDatei so weit wie möglich zu beenden . Außerdem wurde das Standard-Trennzeichen für die ID des Namenscontainers :konfigurierbar, sodass HTML / CSS-Puristen erleichtert atmen konnten. Alles , was Sie tun müssen , ist es so zu definieren , init-paramin web.xmlmit dem Namen javax.faces.SEPARATOR_CHARund sicherzustellen , dass Sie nicht dem Charakter selbst überall in Client - IDs verwenden, wie zum Beispiel -.

Zu guter Letzt wurde ein neuer Bereich eingeführt, der Ansichtsbereich . Es beseitigte einen weiteren großen Nachteil von JSF 1.x, wie zuvor beschrieben. Sie deklarieren einfach die Bean @ViewScoped, um den Konversationsbereich zu aktivieren, ohne alle Möglichkeiten zu beeinträchtigen, die Daten in nachfolgenden (Konversations-) Anforderungen beizubehalten. Eine @ViewScopedBean lebt so lange, wie Sie sie anschließend senden und zu derselben Ansicht navigieren (unabhängig von der geöffneten Registerkarte / dem geöffneten Browserfenster!), Entweder synchron oder asynchron (Ajax). Siehe auch Unterschied zwischen Ansichts- und Anforderungsbereich in verwalteten Beans und Wie wählt man den richtigen Bean-Bereich aus?

Obwohl praktisch alle Nachteile von JSF 1.x beseitigt wurden, gibt es JSF 2.0-spezifische Fehler, die zu einem Showstopper werden könnten. Das @ViewScopedschlägt bei Tag-Handlern aufgrund eines Hühnerei-Problems beim teilweisen Speichern des Zustands fehl . Dies ist in JSF 2.2 behoben und in Mojarra 2.1.18 zurückportiert. Auch das Übergeben von benutzerdefinierten Attributen wie HTML5data-xxx wird nicht unterstützt. Dies wird in JSF 2.2 durch die neue Funktion für Passthrough-Elemente / Attribute behoben. Darüber hinaus hat die JSF-Implementierung Mojarra ihre eigenen Probleme . Relativ viele von ihnen hängen mit dem manchmal unintuitiven Verhalten von<ui:repeat> , der neuen Implementierung zum Speichern von Teilzuständen und dem schlecht implementierten Flash-Bereich zusammen . Die meisten davon sind in einer Mojarra 2.2.x-Version behoben.

Ungefähr zur Zeit von JSF 2.0 wurde PrimeFaces eingeführt, basierend auf jQuery und jQuery UI. Es wurde die beliebteste JSF-Komponentenbibliothek.

JSF 2.2 (Mai 2013)

Mit der Einführung von JSF 2.2 wurde HTML5 als Schlagwort verwendet, obwohl dies technisch nur in allen älteren JSF-Versionen unterstützt wurde. Siehe auch Javaserver Faces 2.2 und HTML5 - Unterstützung, warum ist noch XHTML verwendet wird . Die wichtigste neue Funktion von JSF 2.2 ist die Unterstützung benutzerdefinierter Komponentenattribute, wodurch sich eine Vielzahl von Möglichkeiten eröffnet, z. B. benutzerdefinierte tabellenlose Optionsfeldgruppen .

Abgesehen von implementierungsspezifischen Fehlern und einigen "nervigen Kleinigkeiten" wie der Unfähigkeit, einen EJB in einen Validator / Konverter einzufügen (bereits in JSF 2.3 behoben), gibt es in der JSF 2.2-Spezifikation keine wirklich großen Nachteile.

Komponentenbasierte MVC vs Anforderungsbasierte MVC

Einige mögen sich dafür entscheiden, dass der Hauptnachteil von JSF darin besteht, dass es nur sehr wenig feinkörnige Kontrolle über das generierte HTML / CSS / JS ermöglicht. Das ist nicht JSFs eigenes, nur weil es ein komponentenbasiertes MVC-Framework ist, kein anforderungs- (aktions-) MVC-Framework. Wenn ein hohes Maß an Kontrolle über HTML / CSS / JS Ihre Hauptanforderung ist, wenn Sie ein MVC-Framework in Betracht ziehen, sollten Sie sich bereits nicht mit einem komponentenbasierten MVC-Framework befassen, sondern mit einem anforderungsbasierten MVC-Framework wie Spring MVC . Sie müssen nur berücksichtigen, dass Sie das gesamte HTML / CSS / JS-Boilerplate selbst schreiben müssen. Siehe auch Unterschied zwischen Anforderungs-MVC und Komponenten-MVC .

Siehe auch:

• Was ist der Unterschied zwischen JSF, Servlet und JSP? (nur um die Grundlagen zu verstehen)
• Verwenden von JSF zum Entwickeln von tabellenlosen CSS-Layouts (ein weiterer Mythos über JSF)
• JSF gegen einfaches HTML / CSS / JS / jQuery (wenn JSF die falsche Wahl ist)
• Entwurfsmuster in Webanwendungen (veranschaulicht die Ideologie hinter MVC)

Nach 5 Jahren Arbeit mit JSF denke ich, dass ich meine 2 Cent hinzufügen kann.

Zwei Hauptnachteile von JSF :

1. Große Lernkurve. JSF ist komplex, das stimmt einfach.
2. Seine Bestandteile Natur. Das komponentenbasierte Framework versucht, die wahre Natur des Webs zu verbergen, was mit einer Vielzahl von Komplikationen und Katastrophen verbunden ist (z. B. die Nichtunterstützung von GET in JSF innerhalb von fast 5 Jahren).
   IMHO ist es ein enormer Fehler, HTTP Request / Response vor dem Entwickler zu verbergen. Nach meiner Erfahrung fügt jedes komponentenbasierte Framework der Webentwicklung Abstraktion hinzu, und diese Abstraktion führt zu unnötigem Overhead und höherer Komplexität.

Und kleine Nachteile, die mir in den Sinn kommen:

1. Standardmäßig setzt sich die ID des Objekts aus den IDs seiner Eltern zusammen, z. B. form1: button1.
2. Keine einfache Möglichkeit, das Fragment einer falschen Seite auskommentieren. Das Tag <ui:remove>benötigt syntaktisch korrekten Inhalt, der ohnehin analysiert wird.
3. Niedrige Qualität 3rd - Party - Komponenten , die beispielsweise nicht überprüfen isRendered()innen processXxx()Methode , bevor Sie fortfahren.
4. LESS & Sencha zu integrieren ist schwierig.
5. Spielt nicht gut mit REST.
6. Für UX-Designer nicht so einfach, da gebrauchsfertige Komponenten ihre eigenen CSS-Stile haben, die überschrieben werden müssen.

Versteh mich nicht falsch. Als Komponenten-Framework ist JSF in Version 2 wirklich gut, aber es ist immer noch komponentenbasiert und wird es immer sein ...

Bitte werfen Sie einen Blick auf die geringe Beliebtheit von Tapestry, Wicket und die geringe Begeisterung erfahrener JSF-Entwickler (was noch aussagekräftiger ist). Schauen Sie sich zum Kontrast den Erfolg von Rails, Grails, Django, Play! Framework - alle sind aktionsbasiert und versuchen nicht, die wahre Anfrage / Antwort und den zustandslosen Charakter des Webs vor dem Programmierer zu verbergen .

Für mich ist es ein großer Nachteil von JSF. IMHO JSF eignet sich für einige Arten von Anwendungen (Intranet, formularintensiv), aber für echte Webanwendungen ist dies kein guter Weg.

Ich hoffe, es hilft jemandem bei seinen Entscheidungen in Bezug auf das Front-End.

Ein paar Nachteile, die mir in den Sinn kommen:

1. JSF ist ein komponentenbasiertes Framework. Dies hat inhärente Einschränkungen, die mit dem Befolgen des Komponentenmodells zu tun haben.
2. AFAIK JSF unterstützt nur POST. Wenn Sie also irgendwo ein GET möchten, müssen Sie ein einfaches Servlet / JSP ausführen.
3. Die meisten Komponenten versuchen, Abstraktionen über Domänen wie relationale Datenbanken und Front-End-JavaScript bereitzustellen, und oft sind diese Abstraktionen "undicht" und sehr schwer zu debuggen.
4. Diese Abstraktionen sind möglicherweise ein guter Ausgangspunkt für einen Junior-Entwickler oder jemanden, der mit einer bestimmten Domäne nicht vertraut ist (z. B. Front-End-JavaScript), sind jedoch für die Leistung sehr schwer zu optimieren, da mehrere Ebenen beteiligt sind und die meisten Benutzer sie verwenden Ich habe wenig Verständnis dafür, was unter der Haube vor sich geht.
5. Die Vorlagenmechanismen, die normalerweise bei JSF verwendet werden, haben nichts mit der Funktionsweise von Webdesigern zu tun. Die WYSIWYG-Editoren für JSF sind primitiv und in jedem Fall gibt Ihnen Ihr Designer HTML / CSS, das Sie lange konvertieren müssen.
6. Dinge wie EL-Ausdrücke werden nicht statisch überprüft, und sowohl der Compiler als auch die IDEs leisten keine gute Arbeit beim Auffinden von Fehlern. Daher treten Fehler auf, die Sie zur Laufzeit abfangen müssen. Dies mag für dynamisch getippte Sprachen wie Ruby oder PHP in Ordnung sein, aber wenn ich dem Aufblähen des Java-Ökosystems standhalten muss, muss ich meine Vorlagen eingeben.

Zusammenfassend lässt sich sagen: Die Zeit, die Sie mit JSF sparen, da Sie nicht den JSP- / Servlet- / Bean-Boilerplate-Code schreiben müssen, haben Sie x10 ausgegeben, um ihn skalieren zu lassen und genau das zu tun, was Sie möchten.

Für mich ist der größte Nachteil von JSF 2.0 die Lernkurve nicht nur von JSF, sondern auch der Komponentenbibliotheken, die Sie verwenden müssen, damit es nützliche Arbeit leistet. Betrachten Sie die erstaunliche Anzahl von Spezifikationen und Standards, mit denen Sie sich befassen, um wirklich kompetent zu sein:

• HTML in den verschiedenen Inkarnationen. Tu nicht so, als müsstest du es nicht wissen.
• HTTP - Wenn Sie nicht herausfinden können, was los ist, müssen Sie Firebug öffnen und sehen. Dafür müssen Sie das wissen.
• CSS - Ob es Ihnen gefällt oder nicht. Es ist wirklich nicht so schlimm und es gibt zumindest einige nette Werkzeuge da draußen.
• XML - JSF wird wahrscheinlich der erste Ort sein, an dem Sie Namespaces in diesem Maße verwenden.
• Servlet-Spezifikation. Früher oder später werden Sie in diesem Paket Methoden aufrufen. Abgesehen davon müssen Sie wissen, wie Ihre Facelets in XHTML oder was auch immer umgewandelt werden.
• JSP (meistens, damit Sie wissen, warum Sie es in JSF nicht benötigen)
• JSTL (wieder hauptsächlich, um mit Legacy-Frameworks fertig zu werden)
• Ausdruckssprache (EL) in ihren verschiedenen Formen.
• ECMAScript, JavaScript oder wie auch immer Sie es nennen möchten.
• JSON - Sie sollten dies wissen, auch wenn Sie es nicht verwenden.
• AJAX. Ich würde sagen, JSF 2.0 macht einen anständigen Job, um dies vor Ihnen zu verbergen, aber Sie müssen immer noch wissen, was los ist.
• Das DOM. Und wie ein Browser es benutzt. Siehe ECMAScript.
• DOM Events - ein Thema für sich.
• Java Persistence Architecture (JPA), wenn Ihre App über eine Back-End-Datenbank verfügen soll.
• Java selbst.
• JSEE während du dabei bist.
• Die Context Dependency Injection-Spezifikation (CDI) und wie sie mit JSF 2.0 kollidiert und mit JSF 2.0 verwendet wird
• JQuery - Ich würde gerne sehen, dass Sie ohne auskommen.

Sobald Sie damit fertig sind, können Sie mit den proprietären Spezifikationen fortfahren, nämlich den Komponentenbibliotheken und Anbieterbibliotheken, die Sie unterwegs abholen werden:

• PrimeFaces (meine Komponentenbibliothek Ihrer Wahl)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (mein JPA-Anbieter)
• Überwintern
• Schweißen

Und vergiss den Container nicht! Und all diese Konfigurationsdateien:

• GlassFish (2, 3 usw.)
• JBoss
• Kater

Also - DAS MACHT ES EINFACH? Sicher, JSF 2.0 ist "einfach", solange Sie nur die grundlegendsten Webseiten mit den einfachsten Interaktionen verwenden möchten.

Einfach ausgedrückt ist JSF 2.0 die komplizierteste und umständlichste Mischung aus zusammengeklebten Technologien, wie sie heute im Softwareuniversum existiert. Und mir fällt nichts ein, was ich lieber benutzen würde.

1. Unerfahrene Entwickler erstellen normalerweise Anwendungen, die schmerzhaft langsam sind und deren Code sehr hässlich und schwer zu warten ist. Es ist täuschend einfach zu starten, erfordert aber tatsächlich einige Investitionen in das Lernen, wenn Sie gute Programme schreiben möchten.
2. Zumindest zu Beginn werden Sie oft an einem Problem "hängen bleiben" und mehr Zeit damit verbringen, Balusc-Beiträge im Internet zu lesen, als tatsächlich zu arbeiten :) Nach einer Weile wird es immer weniger davon sein, aber es kann immer noch ärgerlich sein.
3. Noch ärgerlicher, wenn Sie feststellen, dass das Problem nicht auf mangelndes Wissen / Fehler zurückzuführen ist, sondern auf einen Fehler. Mojarra war (ist?) Ziemlich fehlerhaft, und eine weitere Schicht von Komponenten fügt noch mehr Probleme hinzu. Richfaces war die größte Mist-Software, die jemals geschrieben wurde :) Ich weiß nicht, wie es jetzt in Version 4 ist. Wir haben Primefaces, was besser ist, aber Sie werden trotzdem auf Fehler oder fehlende Funktionen stoßen, insbesondere bei exotischeren Komponenten. Und jetzt müssen Sie für Primefaces-Updates bezahlen. Ich würde also sagen, dass es fehlerhaft ist, aber es wird besser, besonders nachdem die Version 2.2 einige Probleme mit der Spezifikation behoben hat. Das Framework wird ausgereifter, aber noch lange nicht perfekt (vielleicht myfaces besser?).
4. Ich finde es nicht besonders flexibel. Wenn Sie etwas sehr, sehr individuelles benötigen und es keine Komponenten gibt, die dies tun, ist dies oft etwas schmerzhaft. Ich spreche wieder aus der Perspektive eines durchschnittlichen Entwicklers - der mit Fristen, schnellen Lese-Tutorials und Stackoverflow, wenn Sie nicht weiterkommen, weil Sie keine Zeit haben, um zu lernen, wie es wirklich funktioniert :) Oft scheinen einige Komponenten "fast" das zu haben, was Sie brauchen, aber nicht genau und manchmal verbringst du möglicherweise zu viel Zeit, um es dazu zu bringen, etwas zu tun, was du willst :) Du musst vorsichtig sein, um zu bewerten, ob es besser ist, deine eigene Komponente zu erstellen oder vorhandene zu quälen. Wenn Sie etwas wirklich Einzigartiges erstellen, würde ich JSF nicht empfehlen.

Kurz gesagt, meine Nachteile wären: Komplexität, nicht sehr reibungsloser Entwicklungsfortschritt, fehlerhaft, unflexibel.

Natürlich gibt es auch Vorteile, aber das haben Sie nicht gefragt. Wie auch immer, das ist meine Erfahrung mit Framework. Andere haben möglicherweise andere Meinungen. Der beste Weg ist es, es eine Weile zu versuchen, um zu sehen, ob es für Sie ist (nur etwas komplexeres - keine naiven Beispiele - JSF glänzt wirklich dort :) IMHO bester Anwendungsfall für JSF sind Geschäftsanwendungen wie CRMs usw.

"JSF gibt HTML und JavaScript auf Ansichtsebene aus, die Sie nicht steuern oder ändern können, ohne den Controller-Code zu verwenden."

Tatsächlich bietet Ihnen JSF die Flexibilität. Sie können entweder Standardkomponenten / Komponenten von Drittanbietern verwenden oder eigene Komponenten erstellen, bei denen Sie die volle Kontrolle darüber haben, was gerendert wird. Es ist nur ein XML-Code, den Sie zum Erstellen Ihrer benutzerdefinierten Komponenten mit JSF 2.0 benötigen.

Ich bin überhaupt kein Java Server Faces-Experte. Aber meiner Meinung nach ist der Hauptnachteil, dass es serverseitig ist. Ich bin es leid, serverseitige Frameworks für Webpräsentationsschichten wie ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, PHP-Frameworks und Ruby on Rails-Frameworks zu lernen und zu verwenden. Ich verabschiedete mich von allen und begrüßte Angularjs und TypeScript. Meine Präsentationsebene wird im Browser ausgeführt. Es spielt keine Rolle, ob es von Windows IIS mit PHP oder ASP.NET oder von einem Apache-Webserver unter Linux bereitgestellt wird. Ich muss nur ein Framework lernen, das überall funktioniert.

Nur meine zwei Cent.

Wir haben ein Beispielprojekt mit JSF entwickelt (es war eine dreiwöchige Recherche, daher haben wir möglicherweise einige Dinge verloren!)

Wir versuchen, Core JSF zu verwenden. Wenn eine Komponente benötigt wird, haben wir PrimeFaces verwendet.

Das Projekt war eine Website mit Navigation. Jede Seite sollte über Ajax geladen werden, wenn auf das Menü geklickt wird.

Die Site hat zwei Anwendungsfälle:

1. Eine Seite mit einem Raster. Das Raster wird über Ajax geladen und sollte Sortieren und Paging unterstützen
2. Eine dreistufige Assistentenseite. Jede Seite verfügt über eine clientseitige Validierung (für einfache Validierungen) und eine serverseitige Ajax-Basisvalidierung (für komplexe Validierungen). Jede Serverausnahme (von der Serviceschicht) sollte auf derselben Seite des Assistenten angezeigt werden, ohne zur nächsten Seite zu navigieren.

Wir haben das gefunden:

1. Sie müssen einige Hacks von omniFaces verwenden, um den Status der JSF-Ansicht zu korrigieren. Der JSF-Status wird beschädigt, wenn Sie Seiten über Ajax ineinander einfügen. Dies scheint ein Fehler in JSF zu sein und kann in den nächsten Versionen behoben werden (nicht in 2.3).
2. Der JSF-Flow funktioniert mit Ajax nicht richtig (oder wir konnten ihn nicht zum Laufen bringen!). Wir versuchen stattdessen, die Primeface-Assistentenkomponente zu verwenden, aber die Client-Validierung scheint nicht unterstützt zu sein und bedeutet, dass es sich nicht um einen Standard-JSF-Flow-Standard handelt.
3. Wenn Sie einige jQuery-Komponenten wie jqGird verwenden und JSON-Ergebnisse laden müssen, wird empfohlen, ein reines Servlet zu verwenden. Die JSF wird nichts für Sie tun. Wenn Sie diese Art von Komponenten verwenden, passt Ihr Design nicht in JSF.
4. Wir versuchen, einige Client-Skripte zu erstellen, wenn Ajax abgeschlossen ist, ajaxCompleteund haben festgestellt, dass der PF 4 seine eigenen Ajax-Ereignisse implementiert hat. Wir hatten einige jQuery-Komponenten und müssen ihren Code ändern.

Wenn Sie das obige Beispiel in ein Nicht-Ajax- Projekt (oder zumindest ein weniger Ajax- Projekt) ändern, treten nicht viele der oben genannten Probleme auf.

Wir fassen unsere Forschung zusammen als:

JSF funktioniert auf einer vollständig Ajax-Basis-Website nicht gut.

Natürlich finden wir in JSF viele nette Funktionen, die in einigen Projekten sehr hilfreich sein können. Berücksichtigen Sie also Ihre Projektanforderungen.

Informationen zu den JSF-Vorteilen finden Sie in den technischen Dokumenten von JSF. Meiner Meinung nach ist der größte Vorteil von JSF die KOMPLETTE UND RIESIGE Unterstützung von @BalusC ;-)

Für mich ist das größte Manko von JSF die schlechte Unterstützung für programmgesteuert (dynamisch) generierte Seiten.
Wenn Sie Ihre Seite dynamisch aus Java-Code erstellen (Seitenkomponentenmodell erstellen) möchten. Zum Beispiel, wenn Sie am WYSIWYG-Webseitenkonstruktor arbeiten. Eine angemessene Dokumentation dieses Anwendungsfalls ist nicht allgemein verfügbar. Es gibt viele Punkte, an denen man experimentieren muss und die Entwicklung sehr langsam verläuft. Viele Dinge funktionieren einfach nicht so, wie Sie es erwarten würden. Aber im Allgemeinen ist es möglich, es irgendwie zu hacken.
Gut ist, dass es kein Problem in der Philosophie oder Architektur von JSF ist. Es ist einfach nicht genug ausgearbeitet (soweit ich weiß).

JSF 2 brachte Composite Components mit, die die Entwicklung von Komponenten vereinfachen sollten, aber ihre Unterstützung für dynamische (programmatische) Konstruktionen ist sehr schlecht. Wenn Sie einen recht komplizierten und fast undokumentierten Prozess der dynamischen Konstruktion von Verbundkomponenten überwinden, werden Sie feststellen, dass einige Verbundkomponenten, die etwas tiefer verschachtelt sind, nicht mehr funktionieren und einige Ausnahmen auslösen.

Es scheint jedoch, dass sich die JSF-Community dieser Mängel bewusst ist. Sie arbeiten daran, wie Sie an diesen beiden Fehlern sehen können:
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Mit JSF 2.2 sollte die Situation besser sein, zumindest wenn es um Spezifikationen geht.

Kommentar zu meinen letzten Monaten mit Primefaces / JSF:

• Wenn Sie Komponenten "von der Stange" verwenden können, ist das wohl nicht schrecklich.
• Es funktioniert jedoch nicht gut, sobald Sie nach draußen gehen und benutzerdefinierte Benutzeroberflächen benötigen. - Zum Beispiel mussten wir den Bootstrap von Twitter für unser Projekt verwenden. (Nicht Primefaces Bootstrap).
  • Jetzt funktionieren unsere Seiten wie folgt:
    • Seite wird geladen.
    • Der Benutzer interagiert mit einem Primefaces mit Ajax-Funktionalität
    • Die Javascript-Bindungen von Bootstrap brechen
    • Wir führen zusätzliches Javascript aus, um alles neu zu binden

Das Versprechen von JSF, das Schreiben von Javascript zu vermeiden, führte dazu, dass mehr Javascript geschrieben wurde als ohne Primefaces - und dieses Javascript behebt, was Primefaces kaputt macht.

Es ist eine Zeitsenke - es sei denn, Sie verwenden wieder "von der Stange". Auch sehr hässlich (Primefaces), wenn man mit Selen arbeiten muss. Es kann alles gemacht werden - aber auch hier bleibt nur so viel Zeit.

Vermeiden Sie dies auf jeden Fall, wenn Sie mit einem UX- / Designteam zusammenarbeiten und schnell auf der Benutzeroberfläche iterieren müssen - Sie können Zeit sparen, indem Sie jquery lernen / direktes HTML schreiben - oder sich Reagieren / Winkel ansehen.

JSF hat viele Vorteile. Da die Frage im Nachteil ist, möchte ich einige Punkte hinzufügen.

In einem praktischen Szenario für die Implementierung eines Webprojekts in einem bestimmten Zeitraum müssen Sie die folgenden Faktoren im Auge behalten.

• Haben Sie genug hochrangige Mitglieder in Ihrem Team, die die besten Kontrollen vorschlagen können, die für jedes Szenario geeignet sind?

• Haben Sie die Bandbreite, um die anfängliche Lernkurve aufzunehmen?

• Haben Sie genug Fachwissen in Ihrem Team, um die
  von den Entwicklern erstellten JSF- Inhalte zu überprüfen ?

Wenn Sie für die Fragen mit "Nein" antworten, befinden Sie sich möglicherweise in einer nicht wartbaren Codebasis.

JSF hat nur einen Nachteil: Bevor Sie mit der "JSF" -Entwicklung beginnen, sollten Sie die Webentwicklung, das Kern-Java und die Front-End-Architektur klar verstehen.

Heutzutage versuchen "neue" JavaScript-Frameworks nur, das komponentenbasierte "JSF" -Modell zu kopieren / einzufügen.

Unter allen "Mainstream" -Frameworks wie Spring MVC, Wicket, Tapestry usw. ist das JSF von Java EE mit seinen zusammengesetzten Komponenten die am besten ausgearbeitete Präsentationsschicht und komponentenorientierte Technologie. Es ist etwas umständlich und unvollständig im Vergleich zu Lösungen von HybridJava.