Was sind die wichtigsten Nachteile der Java Server Faces 2.0?

Question

Gestern sah ich eine Präsentation auf Java Server Faces 2.0, die wirklich beeindruckend aussahen, obwohl ich bin derzeit glücklich ASP.NET MVC / jQuery-Entwickler. Was mir am besten gefallen über JSF die riesige Menge an war die UI-Komponenten AJAX-fähigen scheint Entwicklung viel schneller als mit ASP.NET MVC, vor allem auf AJAX-schweren Seiten zu machen. Integrationstests sahen auch sehr schön.

Da nur die Präsentation die Vorteile von JSF betont, würde Ich mag über die andere Seite auch hören.

Also meine Fragen sind:

• Was sind die wichtigsten Nachteile der Java Server Faces 2.0?
• Was könnte einen JSF Entwickler machen prüfen, mit ASP.NET MVC anstelle von JSF?

Answer 1

JSF 2.0 Nachteile? Ehrlich gesagt, abgesehen von der relativ steile Lernkurve, wenn Sie nicht über ein solides Hintergrundwissen über grundlegend Web-Entwicklung (HTML / CSS / JS, Server-Seite im Vergleich zu Client-Seite, usw.) und die grundlegender Java-Servlet-API (Request / Response / session, Weiterleiten / Umleiten, etc.), kommen keine ernsthaften Nachteile in dem Sinne. JSF in seiner aktuellen Version muss noch von der negativen Bild, um loszuwerden, es während des frühen Alter gewonnen, bei dem es mehrere gravierenden Nachteile waren.

JSF 1.0 (März 2004)

Dies war die erste Version. Es wurde mit Fehlern in den beiden Kernen und Leistungsbereichen, die Sie wollen wissen, über nicht überladen. Ihre Webapplikation nicht immer funktionieren, wie Sie würde intuitiv erwarten. Sie als Entwickler laufen würden schwer weg zu weinen.

JSF 1.1 (Mai 2004)

Das war die Bugfix-Release. Die Performance wurde noch nicht viel verbessert. Es gab auch einen großen Nachteil: Sie fehlerlos keine Inline-HTML-Code in der JSF-Seite können. All Plain-Vanilla-HTML-get gemacht vor der JSF-Komponentenbaum. Sie müssen all Plain-Vanilla in <f:verbatim> Tags wickeln, so dass sie in dem JSF-Komponentenbaum enthalten bekommen. Obwohl dies gemäß der Spezifikation war, hat dies viel Kritik erhalten. Siehe auch u.a. JSF / Facelets: warum ist es keine gute Idee, JSF / Facelets mischen mit HTML-Tags

?

JSF 1.2 (Mai 2006)

Dies war die erste Veröffentlichung der neuen JSF-Entwicklungsteam unter Leitung von Ryan Lübke. Das neue Team hat viele großartige Arbeit. Veränderungen gab es auch in der spec. Die wichtigste Änderung war die Verbesserung der Sicht Handhabung. Dies ist nicht nur vollständig abgelöst JSF von JSP, so könnte man eine andere Sicht Technologie als JSP verwenden, aber es auch Entwickler erlaubt, Plain-Vanilla-HTML-Code in der JSF-Seite ohne hassling mit <f:verbatim> Tags inline. Ein weiterer Schwerpunkt des neuen Teams war die Verbesserung der Leistung. Während der Laufzeit der Sun JSF Referenzimplementierung 1.2 (die Codenamen wurde Mojarra seit Build 1.2_08, um 2008), praktisch bekam jeder Build mit (großen) Leistungsverbesserungen verschifft neben die üblichen (minor) Fehlerbehebung .

Der einzige ernsthafte Nachteil von JSF 1.x (einschließlich 1.2) ist das Fehlen eines Bereichs zwischen der Anfrage und Sitzung Rahmen, der so genannten Gespräch Rahmen. Dies zwang den Entwickler zu Ärger mit versteckten Eingabeelementen, unnötigen DB-Abfragen und / oder Missbrauch des Sitzungsbereiches, wenn man die ersten Modelldaten in der nachfolgenden Anforderung, um erfolgreich Prozessvalidierungen, Umwandlungen beibehalten möge, Modelländerungen und Maßnahmen Anrufungen in der mehr komplex Webapplikationen. Der Schmerz kann durch die Annahme eine 3rd-Party-Bibliothek aufgeweicht werden, die die erforderlichen Daten in der nachfolgenden Anforderung behält wie MyFaces Tomahawk <t:saveState> Komponente, JBoss Seam Gespräch Umfang und MyFaces Orchestra Gespräch Rahmen.

Ein weiterer Nachteil für HTML / CSS-Puristen ist, dass JSF den Doppelpunkt : als ID-Trennzeichen verwendet Einzigartigkeit des HTML-Element id im generierten HTML-Ausgabe zu gewährleisten, vor allem, wenn eine Komponente wiederverwendet wird mehr als einmal in der Ansicht (Templat, Iterieren Komponenten, etc). Da dies ein unzulässiges Zeichen in CSS Bezeichner ist, müßten Sie die \ verwenden, um den Doppelpunkt i zu entkommenn CSS-Selektoren, was zu hässlich und seltsam aussehende Selektoren wie #formId\:fieldId {} oder sogar #formId\3A fieldId {}. Siehe auch Wie JSF verwenden generierten HTML-Element-ID mit Doppelpunkt ":" in CSS-Selektoren wenn Sie jedoch kein Purist sind, lesen Sie auch standardmäßig JSF unbrauchbar IDs erzeugt, die mit CSS-Teil nicht kompatibel sind von Web-Standards .

Auch JSF 1.x nicht mit Ajax Einrichtungen aus dem Kasten heraus versenden. Nicht wirklich ein technischer Nachteil, aber aufgrund der Web 2.0 Hype während dieser Zeit wurde es zu einem funktionellen Nachteile. Exadel wurde früh Ajax4jsf einzuführen, die gründlich in den Jahren entwickelt und wurde zum Kernstück der JBoss Richfaces Komponentenbibliothek. Eine weitere Komponente-Bibliotheken wurden mit builtin Ajax Kräfte ausgeliefert als auch, die bekannte ein Wesen ICEfaces .

Nach der Hälfte der JSF 1.2 Lebensdauer, eine neue XML-basierte View-Technologie eingeführt wurde: Verbundkomponenten ). Siehe auch Warum ist Facelets über JSP als view-Definition Sprache bevorzugt von JSF2.0 ab?

Ajax Kräfte wurden in den Geschmack des <f:ajax> Komponente eingeführt, die viel Ähnlichkeit mit Ajax4jsf hat. Anmerkungen und Kongress-over-Konfiguration Verbesserungen wurden an Abtötung der ausführlichen faces-config.xml Datei so viel eingeführt wie möglich. Außerdem wurde der Standardnamenscontainer ID Trennzeichen : konfigurierbar, so HTML / CSS-Puristen erleichtert atmen können. Alles, was Sie tun müssen, ist es, als init-param in web.xml mit dem Namen javax.faces.SEPARATOR_CHAR zu definieren und sicherzustellen, dass Sie sich überall in Client-IDs nicht mit dem Charakter sind, wie -.

Last but not least, ein neuer Bereich eingeführt wurde, die Ansicht Rahmen. Es beseitigt einen weiteren großen JSF 1.x Nachteil wie oben beschrieben. Sie erklären nur die Bohne @ViewScoped das Gespräch Umfang zu ermöglichen, ohne alle Möglichkeiten, das zu Streiten um die Daten in der nachfolgenden (Umgangssprache) Anfragen zu behalten. Eine @ViewScoped Bohne wird so lange leben, wie Sie später sind die Einreichung und zu der gleichen Ansicht Navigation (unabhängig von den geöffneten Browser-Tab / Fenstern!), Entweder synchron oder asynchron (Ajax). Siehe auch Unterschied zwischen Ansicht und Request Umfang in Managed Beans und Wie Sie den richtigen Bohnen Rahmen wählen?

Obwohl praktisch alle Nachteile von JSF 1.x eliminiert wurden, gibt es JSF 2.0 spezifische Fehler, die ein Hemmschuh werden könnte. Die @ViewScoped nicht in Tag-Handler aufgrund eines Henne-Ei-Problems in Teilzustand Einsparung. Dies ist in JSF 2.2 festgelegt und rückportiert in Mojarra 2.1.18. auch Vorbeigehen benutzerdefinierte Attribute wie die HTML5 data-xxx wird nicht unterstützt. Dieser in JSF 2.2 durch neue Pass-Through-Elemente festgelegt ist / Attribute Funktion. Weiterhin ist die JSF Implementierung Mojarra hat seine eigenen Probleme . relativ viele von ihnen auf die manchmal unintuitive Verhalten von <ui:repeat> , die neuer Teilsparzustand Implementierung und die schlecht Flash Umfang implementiert. Die meisten von ihnen sind in einer Mojarra 2.2.x-Version behoben.

Um die JSF 2.0 Zeit PrimeFaces eingeführt wurde, basiert auf jQuery und jQuery UI. Es wurde zum beliebtesten JSF-Komponenten-Bibliothek.

JSF 2.2 (Mai 2013)

Mit der Einführung von JSF 2.2 wurde HTML5 als Schlagwort verwendet, obwohl dies technisch in allen älteren Versionen JSF nur unterstützt wurde. Siehe auch JSF 2.2 und HTML5-Unterstützung, warum XHTML noch verwendet wird. Das wichtigste neue JSF 2.2 Feature ist die Unterstützung für benutzerdefinierte Komponentenattribute, hiermit eine Welt der Möglichkeiten, wie benutzerdefinierte tableless Optionsfeld Gruppen .

Neben der Implementierung spezifischer Fehler und einige „ärgerlichen Kleinigkeiten“ wie Unfähigkeit, eine EJB in einem Prüfer / Konverter (bereits fest in JSF 2.3) zu injizieren, gibt es nicht wirklich große Nachteile in der JSF 2.2-Spezifikation.

Component based vs anfordern MVC basierte MVC

Einige können sich entscheiden, dass der große Nachteil von JSF ist, dass es sehr wenig feinkörnige Kontrolle über den HTML / CSS / JS erzeugt werden kann. Das ist nicht JSF eigene, die gerade ist, weil es ein Komponente basierte MVC-Framework, keine Anfrage (Aktion) auf der Grundlage MVC-Framework. Wenn ein hoher Grad des HTML / CSS Controlling / JS Ihre Hauptanforderung ist, wenn ein MVC-Framework bedenkt, dann sollten Sie bereits an einer Komponente werden nicht auf der Suche basierend MVC-Framework, aber auf Wunsch basierten MVC-Framework wie Spring MVC . Sie müssen nur berücksichtigen, dass Sie sich alle, dass HTML / CSS / JS Text schreiben müssen. Siehe auch Unterschied zwischen Anfrage MVC und Component MVC .

Siehe auch:

• Was ist der Unterschied zwischen JSF, Servlets und JSP? (nur die Grundlagen zu verstehen)
• JSF Mit tableless CSS-Layout zu entwickeln (ein weiterer Mythos über JSF)
• JSF vs einfache HTML / CSS / JS / jQuery (wenn JSF ist die falsche Wahl)
• Entwurfsmuster in Web-Anwendungen (zeigt die Ideologie hinter MVC)

Answer 2

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

Zwei Haupt JSF Nachteile:  

  
1. Große Lernkurve. JSF ist komplex, dass nur wahr ist.   
2. Die Komponente Natur. Komponentenbasierte Rahmen versuchen, die wahre Natur des Web zu verstecken, die mit einer riesigen Menge von Komplikationen und Katastrophen kommen (wie nicht innerhalb von fast 5 Jahren GET in JSF unterstützt).  
   IMHO Versteck HTTP Request / Response vom Entwickler ist ein enormer Fehler. Aus meiner Erfahrung, fügt jede Komponente basiertes Framework Abstraktion auf die Web-Entwicklung, und dass die Abstraktion führt zu unnötigem Aufwand und höherer Komplexität.  

und Moll Nachteile, die mir in den Sinn kommen:  

 
1. Mit dem Standard-ID des Objekts besteht aus seinen Eltern ids, zum Beispiel form1: button1.  
2. Keine einfache Möglichkeit, Kommentar-out falsche Seite des Fragments. Tag <ui:remove> muss syntaktisch korrekten Inhalt, die ohnehin analysiert wird.   
3. Niedrige Qualität 3rd-Party-Komponenten, die z.B. nicht isRendered() innerhalb processXxx() Methode überprüfen, bevor Sie fortfahren.  
4. Incorporating LESS & Sencha ist hart.  
5. Spielt gut nicht mit REST.  
6. Gar nicht so einfach für UX-Designer, weil ready-to-use-Komponenten ihre eigenen CSS-Stile haben, dass Bedarf überschrieben werden.

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

Bitte nehmen Sie sich einen Blick auf die geringe Popularität von Tapestry, Wicket und geringe Begeisterung erfahrener JSF Entwickler (was noch bedeutsamer ist). Und für den Kontrast, werfen Sie einen Blick auf den Erfolg von Rails, Grails, Django, spielen! Rahmen -. Sie alle sind handlungsorientierte und versuchen Sie nicht, sich zu verstecken vom Programmierer true Request / Response und staatenlos Natur der Bahn

Für mich ist es der wichtigste JSF Nachteil. IMHO JSF können Anzüge irgendeine Art von Anwendungen (Intranet, Formen intensiv), aber für real-life Web Anwendung ist es nicht ein guter Weg zu gehen.

Hope es hilft jemand mit seinen / ihren Entscheidungen, der Bezug auf dem Front-End.

Answer 3

Ein paar Nachteile, die den Sinn Pop:

1. JSF ist ein komponentenbasiertes Framework. Dies hat inhärente Beschränkungen, zu tun haben, die mit gehorchen Komponenten-Modell.
2. AFAIK JSF unterstützt nur POST, wenn Sie also eine GET irgendwo möchten Sie ein einfaches Servlet / JSP zu tun.
3. versuchen die meisten Komponenten Abstraktionen über Domains zu schaffen wie Relationale Datenbanken und Front-End JavaScript und viele Zeit, diese Abstraktionen sind „leaky“ und sehr schwer zu debuggen.
4. Diese Abstraktionen könnte ein guter Ausgangspunkt für eine Junior-Entwickler oder jemand nicht wohl mit einer bestimmten Domäne (zB Front-End-JavaScript) sein, sind aber sehr schwer zu optimieren die Leistung, da gibt es mehrere Schichten beteiligt sind, und die meisten Menschen dass die Verwendung sie haben wenig Verständnis dafür, was auf unter der Haube wird.
5. Die Templat-Mechanismen, die in der Regel mit JSF verwendet werden, haben nichts mit dem zu tun, wie man Web desigers Arbeit. Die WYSIWYG-Editoren für JSF sind primitiv und in jedem Fall Ihre Designer Sie geben HTML / CSS, dass Sie verbringen müssen werden Alter konvertieren.
6. Dinge wie EL Ausdrücke sind nicht statisch geprüft und sowohl die Compiler und IDEs sind eine gute Arbeit bei der Suche nach Fehlern nicht zu tun, so dass Sie mit Fehlern am Ende feststellen, dass Sie zu fangen während der Laufzeit haben werden. Dies könnte gut für dynamisch typisierte Sprache wie Ruby oder PHP sein, aber wenn ich das schiere aufblasen des Java-Ökosystems zu widerstehen, ich verlangen Typisierung für meine Vorlagen.

Fazit: Die Zeit, die Sie mit JSF sparen, von Vermeidung der JSP / Servlet / bean vorformulierten Code zu schreiben, werden Sie verbringen es x10 es skalieren zu machen und tut genau das, was Sie will es tun.

Answer 4

Für mich ist der größte Nachteil von JSF 2.0 ist die Lernkurve nicht nur von JSF, aber die Komponentenbibliotheken, die Sie verwenden, um haben, um es nützliche Arbeit zu tun. Betrachten wir die überwältigende Zahl von Spezifikationen und Standards, die Sie haben viel mit wirklich beherrscht werden:

• HTML in den verschiedenen Inkarnationen. Tu nicht so, Sie nicht zu wissen, es brauchen.
• HTTP - wenn Sie nicht herausfinden, was los ist auf Sie Firebug öffnen müssen und sehen. Für, dass Sie dies wissen müssen.
• CSS - Wie es oder nicht. Es ist nicht so schlimm, wirklich und es gibt einige nette Tools gibt, zumindest.
• XML -. JSF wird wahrscheinlich der erste Ort, den Sie Namespaces in diesem Ausmaß verwenden
• Servlet-Spezifikation. Früher oder später werden Sie bekommen in Methoden in diesem Paket aufrufen. Abgesehen davon, dass Sie wissen, wie Ihre Facelets wird in XHTML gedreht oder was auch immer.
• JSP (meist damit Sie wissen, warum Sie brauchen es nicht in JSF)
• JSTL (auch hier meist mit Legacy-Rahmen fertig zu werden)
• Expression Language (EL) in seinen verschiedenen Formen.
• ECMAScript, JavaScript oder was auch immer Sie es nennen wollen.
• JSON -. Sie sollten dies auch wissen, wenn Sie es nicht verwenden
• AJAX. Ich würde sagen, JSF 2.0 hat einen anständigen Job diese von Ihnen zu verstecken, aber Sie müssen noch wissen, was los ist.
• Der DOM. Und wie ein Browser verwendet es. Siehe ECMAScript.
• DOM Event -. Ein Thema ganz von selbst
• Java Persistence Architecture (JPA), das ist, wenn Sie möchten, dass Ihre App alle Back-End-Datenbank haben.
• Java selbst.
• JSEE, während Sie es an.
• Die Kontext Dependency Injection-Spezifikation (CDI) und wie es kollidiert mit und wird verwendet, mit JSF 2.0
• JQuery -. Ich möchte Sie, ohne es auszukommen, um zu sehen

Nun, wenn Sie fertig sind mit, dass Sie mit den proprietären Spezifikationen auskommen können, nämlich die Komponentenbibliotheken und Anbieter Bibliotheken, die Sie auf dem Weg abholen:

• PrimeFaces (meine Komponentenbibliothek der Wahl)
• Richfaces
• MyFaces
• ICEFaces
• Eclipse (mein JPA Provider)
• Ruhezustand
• Weld

Und vergessen Sie nicht, den Behälter! Und all diese Konfigurationsdateien:

• Glassfish (2, 3, usw.)
• JBoss
• Tomcat

So - das ist macht es einfach? Sicher, JSF 2.0 ist „easy“ solange alles, was Sie tun möchten, die grundlegendsten ist Web-Seiten mit den einfachsten Wechselwirkungen.

Einfach ausgedrückt, JSF 2.0 ist die komplizierteste und umständlich Mischmasch von zusammengeklebten Technologien wie heute in dem Software-Universum existiert. Und ich kann nicht an nichts denken, würde ich lieber verwenden.

Answer 5

1. Unerfahrene Entwickler werden in der Regel Anwendungen erstellen, die sehr langsam sind und Code wird wirklich hässlich und schwer zu pflegen. Seine täuschend einfach zu starten, erfordert aber tatsächlich einige Investitionen in das Lernen, wenn Sie gute Programme schreiben wollen.
2. zumindest an den Start werden Sie oft „stecken“ auf einige Problem und wird mehr Zeit mit dem Lesen balusc Beiträge im Internet verbringen, als tatsächlich arbeiten :) Nach einer Weile wird weniger und weniger, aber es kann immer noch lästig sein .
3. Noch ärgerlicher, wenn Sie feststellen, dass das Problem ist nicht wegen dir fehlt an Wissen / Fehler, aber tatsächlich um einen Fehler. Mojarra war (ist?) Ziemlich buggy, und eine andere Schicht der Komponenten bringt noch mehr Probleme. Richfaces war größte Stück Scheiße Software, die jemals geschrieben :) weiß nicht, wie es jetzt auf Version 4. Wir Primefaces haben, die besser ist, aber immer noch werden Sie in Fehler oder Mangel an Features, die insbesondere mit exotischen Komponenten laufen. Und jetzt werden Sie für Primefaces Updates zahlen müssen. Also habe ich seinen Buggy sagen würde, aber seine immer besser fixiert besonders nach Version 2.2 einige Probleme mit spec. Rahmen immer ausgereifter, aber bei weitem noch nicht perfekt (vielleicht MyFaces besser?).
4. Ich finde es nicht besonders flexibel. Oft, wenn Sie etwas brauchen sehr sehr angepasst und es gibt keine Komponenten, die nicht, dass - es wird ein bisschen schmerzhaft sein. Wieder von ich rede durchschnittliche Entwickler Perspektive - die eine mit Fristen, schnelle Lese Tutorials und Stackoverflow Benutzer, wenn stecken zu bleiben, weil keine Zeit zu lernen, wie es wirklich funktioniert :) Oft einige Komponenten scheint „fast“, was Sie brauchen zu haben, aber nicht genau und manchmal möchte man zu viel Zeit aufwenden, um es etwas, was Sie wollen :) Brauchen Sie tut bei der Bewertung vorsichtig zu sein, wenn es besser, Ihre eigenen zu erstellen oder vorhandene Komponente foltern. Eigentlich, wenn Sie etwas wirklich Einzigartiges schaffen würde ich nicht JSF empfehlen.

Also kurz gesagt meine Nachteile seien. Komplexität, nicht sehr glatt Entwicklung Fortschritt, Buggy, unflexibel

Natürlich gibt es Vorteile auch, aber das ist nicht das, was Sie gefragt. Wie auch immer, das ist meine Erfahrung mit Rahmen anderen vielleicht unterschiedliche Meinungen hat, so ist bester Weg, nur um es zu versuchen, für eine Weile, um zu sehen, ob sein für Sie (nur etwas komplexer - nicht naiv Beispiele - JSF wirklich da scheint :) IMHO besten Anwendungsfall für JSF ist Business-Anwendungen, wie CRMs etc ...

Answer 6

"JSF ausgeben wird View-Schicht HTML und JavaScript, dass Sie nicht ohne in Controller-Code steuern oder ändern können."

Eigentlich JSF gibt Ihnen die Flexibilität, können Sie entweder Standard verwenden / Komponenten von Drittanbietern oder eigene erstellen, die Ihnen die volle Kontrolle über das, was gemacht wird. Es ist nur ein xhtml Sie Ihre benutzerdefinierten Komponenten mit JSF 2.0 erstellen müssen.

Answer 7

Wir entwickeln ein Beispielprojekt mit JSF (Es war eine 3 Wochen Forschung, so dass wir einige Dinge zu verlieren haben!)

Wir versuchen Kern JSF zu verwenden, wenn eine Komponente benötigt wird, wir PrimeFaces verwendet.

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

Die Seite hat zwei usecases:

1. Eine Seite mit einem Gitter. Das Gitter wird über Ajax geladen und sollten Art und Paging
Unterstützung
2. Eine Drei-Stufen-Seite des Assistenten. Jede Seite hat Client-seitigen Gültigkeitsprüfung (für einfache Validierungen) und Server-Seite ajax Basis Validierung (für komplexe Validierungen). Jeder Server Ausnahme (von Service-Layer) sollte auf der nächsten Seite, ohne die Navigation auf der gleichen Seite des Assistenten angezeigt werden.

Wir fanden heraus, dass:

1. Sie müssen einige Hacks von omniFaces verwenden die JSF-Ansicht Zustand fixiert zu machen. Der JSF-Zustand wird beschädigt, wenn Sie Seiten über Ajax in miteinander umfassen. Dies scheint ein Fehler in JSF und kann auf der nächsten Versionen behoben werden (nicht in 2.3).
2. Die JSF Fluss ist nicht richtig mit Ajax arbeiten (oder wir könnten nicht damit es funktioniert!) Wir versuchen stattdessen primeface Assistenten Komponente zu verwenden, aber die Client-Validierung scheint nicht unterstützt und bedeuten, während es Standard nicht Standard JSF Flow war.
3. Wenn einige jQuery-Komponenten wie jqGird verwenden, und Sie müssen JSON Ergebnisse laden, dann empfehlen wir Ihnen, reine Servlet zu verwenden, die JSF wird nichts für Sie tun. Also, wenn Sie diese Art von Komponenten verwenden, Ihr Design nicht in JSF passen.
4. Wir versuchen, durch ajaxComplete einig Client-Skripte, wenn Ajax komplett zu tun, und wir fanden heraus, dass die PF 4 ein eigenen Ajax-Ereignisse implementiert hat. Wir hatten einige jQuery-Komponenten, und wir müssen ihren Code ändern.

Wenn Sie die obige Probe auf ein nicht Ajax Projekt ändern (oder zumindest weniger Ajax-Projekt) werden Sie nicht Gesicht viel über Fragen.

Wir fassen unsere Forschung als:

  

JSF ist nicht gut in einer vollständig AJAX Basis Website zu arbeiten.

Natürlich haben wir viele nette Features in JSF finden, die in einigen Projekten sehr hilfreich sein kann, so dass Ihre Projektanforderungen berücksichtigen.

Bitte lesen Sie JSF technischen Unterlagen Überprüfung JSF Vorteile, und meiner Meinung nach der größte Vorteil von JSF, ist die vollständige und große Unterstützung von @BalusC; -)

Answer 8

Ich bin kein Java Server Faces Experte überhaupt. Aber meiner Meinung nach der größte Nachteil ist, dass es der Server-Seite. Ich bin müde von Lernen und unter Verwendung von serverseitigen Web-Präsentationsschicht-Frameworks wie ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, PHP-Frameworks und Ruby on Rails-Frameworks. Ich verabschiedete mich von allen von ihnen, und ich sagte hallo zu AngularJS und Typoskript. Meine Präsentationsschicht läuft auf dem Browser. Ich spielt keine Rolle, wenn es von Windows IIS mit PHP oder ASP.NET serviert wird, oder wenn sie von einem Apache-Webserver unter Linux angeboten. Ich brauche nur nur einen Rahmen zu lernen, die überall funktioniert.

Nur meine zwei Cents.

Answer 9

Für mich ist das größte Manko von JSF ist schlechte Unterstützung für programmatisch (dynamisch) generierten Seiten.
Wenn Sie Ihre Seite erstellen möchten (Seite Komponentenmodell erstellen) dynamisch von Java-Code. Zum Beispiel, wenn Sie arbeiten an WYSIWYG Web-Seite Konstruktor. Eine angemessene Dokumentation dieser Anwendungsfall in der Regel nicht zur Verfügung. Es gibt viele Punkte, an denen Sie zu experimentieren und Entwicklung ist ruhig langsam. Viele Dinge funktionieren einfach nicht, wie man erwarten würde. Aber in der Regel seinen möglichen Hack es irgendwie.
Gute Sache ist, dass es nicht Problem in der Philosophie oder Architektur von JSF. Es ist einfach nicht genug ausgearbeitet (soweit ich weiß).

JSF 2 gebracht Composite Components, die leicht Komponentenentwicklung machen sollten, aber ihre Unterstützung für dynamische (programmatische) Konstruktion ist sehr schlecht. Wenn Sie ruhig komplizierte und fast ohne Papiere Prozess der dynamischen Composite Component Konstruktion überwinden, werden Sie feststellen, dass, wenn Sie Nest wenig Composite-Komponenten wenig tiefer, sie aufhören zu arbeiten, einige Ausnahmen zu werfen.

Aber es scheint, dass JSF-Gemeinschaft ist dieser Mangel bewusst. Sie arbeiten daran, wie Sie von diesen beiden Bugs sehen
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

sollte Situation besser mit JSF 2.2 zumindest, wenn wir über Spezifikation sprechen.

Answer 10

Kommentar zu meinen letzten paar Monaten Primefaces / JSF Erfahrung:

• Wenn Sie Komponenten „von der Stange“ nutzen können, ich denke, es ist nicht schrecklich ist.
• Es ist jedoch spielt nicht gut, sobald Sie außerhalb und brauchen individuelle UIs Schritt. - Zum Beispiel mussten wir Twitters Bootstrap für unser Projekt verwenden. (Nicht primefaces Bootstrap).
  • Geben Sie nun unsere Seiten arbeiten folgt als:
    • Seite Lasten.
    • Benutzer interagiert mit einem Primefaces, die Ajax-Funktionalität
    • Bootstrap ist Javascript Bindungen Pause
    • Wir betreiben zusätzliche Javascript rebind alles

Das Versprechen von JSF zu vermeiden, Javascript zu schreiben verwandelte sich in mehr Javascript zu schreiben, als wir es haben würde, wenn nicht Primefaces mit -. Und dass Javascript ist fix, was Primefaces Pausen

Es ist eine Zeit sink - es sei denn, Sie wieder verwenden „von der Stange“ stuff. Auch wirklich hässlich (Primefaces), wenn sie die Arbeit mit Selen mit. Es kann alles getan werden - aber auch hier -. Es gibt nur so viel Zeit

Auf jeden Fall dies vermeiden, wenn Sie mit einem UX / Design-Team und müssen arbeiten auf der Benutzeroberfläche schnell Iterierte - Sie können Zeit sparen jquery Lernen / gerade das Schreiben von HTML - oder suchen Sie in react / eckig.

Answer 11

JSF hat viele Vorteile, Frage auf Nachteil sein lassen Sie mich hinzufügen paar Punkte auf sie.

In einem praktischen Szenario ein Webprojekt mit in einem Zeitrahmen der Umsetzung müssen Sie ein Auge auf den folgenden Faktoren halten.

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

• Haben Sie die Bandbreite haben die anfängliche Lernkurve aufzunehmen?

• Haben Sie genügend Know-how in Ihrem Team haben, die die JSF
  überprüfen können Sachen produziert von den Entwicklern?

Wenn Ihre Antwort ‚Nein‘ für die Fragen ist, können Sie in einer nicht wartbar Code-Basis können am Ende.

Answer 12

JSF hat nur einen Nachteil:. Vor "JSF" Entwicklung beginnen Sie klar Web-Entwicklung verstehen sollte, Core Java und Front-End-Architektur

Heute „neues“ JavaScript-Frameworks nur versuchen, kopieren / einfügen „JSF“ komponentenbasierten Modell.

Answer 13

Unter all dem „Mainstream“ Frameworks wie Spring MVC, Wicket, Tapisserie, usw., die JSF von Java EE mit seinen Verbundkomponenten ist die erarbeitete Präsentationsschicht und bauteilorientierte Technologie. Es ist ein wenig umständlich und unvollständig im Vergleich zu Lösungen von HybridJava zur Verfügung gestellt.