2010-07-17 8 views
10

Kürzlich hat sich meine Firma entschieden, ein Unternehmensportal neu aufzubauen, das von Menschen auf der ganzen Welt verwendet werden wird, um das Produkt für die erweiterte Garantie zu behalten. Sie haben J2EE (Spring MVC) und Oracle als Technologie-Stack für die Business-Schicht entwickelt und entschieden, JSF (Java Server Faces) zu verwenden, um das Frontend (User Interface) zu entwerfen, das ich als Frontend Engineer haben möchte appose JSF, da es mir weniger Kontrolle über das erzeugte Markup geben wird, wird JSF auch unnötiges Markup in die Seite injizieren/generieren, was als ungesundes Essen für den Browser dienen wird. Außerdem wird es schwierig, die Browser-Kompatibilität zu erreichen, da ich keine Kontrolle über das generierte Markup habe. Es ist schwierig, korrektes CSS-Verhalten anzuwenden. Es ist auch nicht möglich, ein Konzept wie ein flüssiges Layout oder ein tabellenloses Layout zu verwenden. All dies führt zu einer schlechten Benutzererfahrung. Meine Idee ist eine entwickelte Benutzeroberfläche mit handcodiertem HTML, die diese HTML-Dateien in JSPs konvertiert und diese JSPs in die Spring MVC-Architektur einfügt.JSF vs HTML (JSP) für Enterprise-Portale UI-Ebene. Welchen zu wählen? und warum?

Nachdem all dies gesagt wurde, muss ich einen Vorschlag präsentieren, der den Ersatz von JSF durch HTML für UI-Layer rechtfertigen wird, Ihre Eingaben/Gedanken und Vorschläge werden wertvoll sein, bitte schreiben Sie zurück.

Auch glaube ich nicht XHTML als andere Option, es muss HTML sein? Lass mich wissen, was denkst du und was lässt dich so denken?

Danke, für einen Zwischenstopp. Ich entschuldige mich, wenn das Lesen all das viel Zeit gekostet hat.

+5

JSF bringt nur mehr Ärger als es löst. Durchsuchen Sie diese Website und sehen Sie sich die Probleme der Leute mit JSF an. In jedem Fall sollte die Entscheidung dem Frontend-Team überlassen werden, da Sie die Werkzeuge auswählen, mit denen Sie am besten zurechtkommen. Du solltest JSF so gut wie möglich ablehnen, denn bald werden sie dich bitten, die Seiten so aussehen zu lassen, dass JSF sie nicht so einfach handhaben kann. Wenn du sagst, dass es schwierig ist, werden die Manager dich nur für dumm halten. Wenn Sie gezwungen sind, JSF zu nutzen, dann genießen Sie es, zumindest ist es etwas Neues in Ihrem Lebenslauf. – irreputable

+0

Ja, dass ein weiteres Akronym mit drei Buchstaben auf Lebenslauf das angenehmste Ergebnis von JSF sein kann ... Wenn Sie immer noch die 3LA –

+3

@irreputable, @Miro A sammeln - das ist nicht wahr. JSF, vor allem 2.0 ist eine ziemlich nette Technologie, die ich nicht zögern würde zu wählen. Ich habe oft Leute gesehen, die sich über JSF beschweren, einfach weil sie nicht verstehen, wie es funktioniert und dass Dinge auf andere Weise damit erreicht werden. – Bozho

Antwort

6

JSF bietet Ihnen viele vordefinierte, reichhaltige Steuerelemente, die die Funktionalität sonst manuell implementieren müsste. Der Preis dafür gibt in gewissem Maße die Kontrolle darüber, wie der Benutzer mit der Anwendung interagiert und wie HTML generiert wird. Es kann auch der Integration mit JS-Bibliotheken im Wege stehen.

Debugging und Tests sind mit JSP und speziell mit Spring wesentlich einfacher.

Es hängt wirklich von Feature-Set von Ihrer Website, Fähigkeiten bei der Umsetzung Team (und Support-Team), Zeitdruck zu liefern usw.

Ich persönlich einfachere Technologien bevorzugen, die mehr Kontrolle in die Entwickler geben (JSP mit Spring MVC) nur für die interne Eleganz des Frameworks, aber das ist nie entscheidend Faktor ....

+0

@irreputable Vielen Dank für Ihre wertvollen Kommentare. –

+0

Je nach Situation können "einfachere" Technologien das Ganze komplizierter machen. Wir haben in der Vergangenheit einfache JSPs verwendet, aber unsere Migration zu JSF hat die Dinge stark vereinfacht. Es ist * sehr * einfach, Markup in eine Composite-Komponente zu gruppieren und diese überall wiederzuverwenden. Sicher, JSP hatte die .tag-Dateien, aber ein Mangel an irgendeiner Komponentendefinition bedeutete, dass es im Grunde ein Einschluss und nichts mehr war. In JSF können wir zum Beispiel einen h: inputText, der an ein Datumsfeld gebunden ist, durch einen rich: -Kalender ersetzen und alles funktioniert wie erwartet. –

+0

Ja, Kalender ist einer dieser Bereiche, die Schmerzen sind, wenn Sie sie umsonst haben können. Du hast einen gültigen Punkt. Auf der anderen Seite, wenn Sie Front-End-Technologie zu einem bestehenden Framework (z. B. Commerce-Site mit ATG) wählen, kann einfach mehr Arbeit aber Erfolg bedeuten, wo reicher Technologie JSF so beugen kann, wie es nie verwendet und geben sollte am Ende. –

24

Was Sie sagen, ist wahr, wenn Sie Vintage JSF 1.0/1.1 API mit "reinen" JSF-Komponenten verwenden . Es gab keine eingebaute Komponente, mit der Sie ein HTML <div> Element darstellen können (damit Sie das allgemeine Seitenlayout auf eine semantische Art und Weise durchführen können). Auch die Einbettung von "normalem" HTML in eine JSF-Seite war ein Problem, da es außerhalb des JSF-Komponentenbaums und vor gerendert wurde. Sie müssen plain HTML in <f:verbatim> Tags überall platzieren. Die Puristen und die Unwissenheit werden weniger oder mehr dazu gezwungen, <h:panelGrid> zu verwenden (was einen <table> rendert), um die Elemente auf der Seite zu positionieren.

Abgesehen davon wurde Netbeans in den frühen JSF-Zeiten mit einem integrierten visuellen JSF-Editor ausgeliefert, mit dem Sie JSF-Komponenten per Drag & Drop ziehen und binden können, ohne eine Codezeile schreiben zu müssen. Dies erzeugt offensichtlich einen auf den ersten Blick unnötigen und nicht mehr wartbaren Code und die pixelgenaue Positionierung der Elemente wurde "hinter den Kulissen" mit einer <h:panelGrid> erreicht. Diese Art von JSF-Anwendungen sind im Hinblick auf Wartbarkeit und Web-Semantizität ein totales Desaster.

Die meisten der negativen Geschichten, die Sie über JSF in Bezug auf Front-End-Entwicklung hören werden, hängen damit zusammen.Die meisten JSF-Benutzer/Beobachter/Ranters von damals konzentrieren sich derzeit noch blind auf das, weil sie schlechte Erfahrungen gemacht haben und/oder sie denken, dass JSF heutzutage immer noch das Gleiche ist und/oder sie den visuellen Editor als Teil von JSF sehen es ist "nur" ein anderes (schlechtes) Werkzeug. Auch die meisten, die "JSF saugt" sagen, sind normalerweise diejenigen, die es mit einem visuellen/Drag'n'Drop-Editor benutzen, ohne fundiertes Hintergrundwissen darüber zu haben, was unter den Hauben passiert (besonders Servlet API!).

Da JSF 1.2 (die vor Freigabe btw bereits vor mehr als 4 Jahren), die <h:panelGroup> Komponente ein zusätzliches Attribut bekam: layout="block" die es ein fullworthy HTML <div> Element (endlich) machen lassen, so dass Sie eine semantische Layout bringen nur JSF-Komponenten verwenden. Aber es ist nicht nur das, JSF 1.2 kommt auch mit einem verbesserten View-Handler, der das Einbetten von einfachem HTML in andere JSF-Komponenten ermöglicht, ohne sich mit <f:verbatim> Tags zu beschäftigen. Sie können <div> Elemente um, wo Sie wollen, ohne mehr Ausführlichkeit hinzufügen.

Obwohl dies eine wesentliche Verbesserung war, gab es immer noch zwei andere große (jedoch nicht direkt UI bezogene) Probleme mit der Standard-JSF-Implementierung: 1) die Zustandsverwaltung unter Anfragen ist schwierig, ohne den Sitzungsumfang zu erfassen gleiche Daten in Tabellen und Dropdown-Listen und die Bedingungen von zB rendered Attribut); 2) alles geht durch POST und Sie können JSFish-Aktionen nicht über GET aufrufen.

Seit JSF 2.0, das fast schon 1 Jahr alt ist, wurden diese Probleme durch einen neuen Bereich, den Ansichtsbereich und eine neue Gruppe von Komponenten für GET-Aktionen abgedeckt. Außerdem wird JSP durch Facelets als Standardansichtstechnologie ersetzt. Facelets erleichtern die Erstellung von Templates und die Erstellung von Composite-Komponenten, ohne auf Java-Code und/oder benutzerdefinierte Komponenten/Renderer zurückgreifen zu müssen. Obwohl es XHTML-basiert ist, kann es ein HTML5 mit nur <!DOCTYPE html> einwandfrei wiedergeben. Das XHTML ist nur da, weil Facelets unter den Hauben ist, die ein XML basiertes Werkzeug benutzen, um die (X) HTML Ausgabe zu erzeugen. Das XHTML-basierte Templating impliziert keineswegs, dass es nur XHTML/XML ausgeben kann.

Alles in allem, Ihre Markup Bedenken sind kein Problem, wenn Sie JSF 1.2 oder neuer verwenden und auch XHTML (Facelets) sollte kein Problem sein, da es HTML5 gültige Markup perfekt rendern kann.

+4

Ich stimme diesem Kommentar so sehr zu. JSF hatte einen etwas problematischen Start, aber die erste Version, die offiziell in Java EE (JSF 1.2) enthalten war, war und ist ziemlich anständig. Mit JSF 2.0, das in der Tat seit einiger Zeit aus ist, sind die meisten der wenigen heiklen Probleme, die JSF 1.2 hatte, vollständig Adressen. Der größte Vorteil von JSF ist, dass es eine erstaunliche Menge an Unterstützung von zahlreichen anderen Projekten hat. RichFaces, IceFaces, OpenFaces, PrimeFaces, Tomahawk, Trinidad ... viele Leute erstellen wiederverwendbare Komponenten und Erweiterungen für JSF. –

+8

+1, müde von Gerüchten gegen JSF "weil JSF 1.Ich war so hart, ich werde Ruby verwenden ";) Die Verwendung einer Technologie erfordert es zu verstehen – Bozho

6

Ich habe eine Zeit als UI Engineer für Barclays, eine globale Bank. Nun, ich werde der Erste sein, der sagt, dass die Finanzindustrie noch einen langen Weg vor sich hat, wenn es um die Benutzerschnittstelle geht, und insbesondere Barclays steht hinter ihrer Technologie. Davon abgesehen wissen sie, wie man Dinge baut, die effektiv und zuverlässig funktionieren, und der UI-Lead ist einer der erstaunlichsten Köpfe, mit denen ich je arbeiten konnte. Als Bank sind sie auch die Nacheiferer.

Wir haben genau die Alternative verwendet, die Sie vorgeschlagen haben, und es hat gut für uns funktioniert. Websites haben Millionen von Benutzern täglich zuverlässig ohne negative Ergebnisse behandelt. Die UI-Arbeit war einfach, und als der Federal Card Act kam, konnte die Firma grundlegende Web-Leute einstellen, um die Cutup/HTML-Arbeit zu erledigen, die die Ingenieure dann in das System einbauen konnten.

Was Ihre XHTML-Frage anbetrifft, entschieden wir uns schlussendlich dafür, HTML 4.01 streng zu gehen, und hier ist der Grund: Erstens hat sich w3 entschieden, die XHTML-Arbeitsgruppe nicht weiterzuentwickeln ... im Wesentlichen ist es auf dem Weg zu einem langsamen Tod. Zweitens ist 4.01 strict dem HTML5-Standard am nächsten und kann ziemlich einfach angepasst werden, sobald sich 5 Unterstützung verbreitet. Eine harte Anforderung für uns war die vollständige Kompatibilität mit IE6, und dies ermöglichte uns, dieses Ziel zu erreichen.

In Ihren Verhandlungen würde ich persönlich argumentieren, dass es entscheidend ist, dass das Endprodukt den aktuellen Webstandards (W3) entspricht, da es am ehesten möglich ist, eine Website zu entwickeln, die mit Browsern kompatibel ist Bin überzeugt, dass Microsoft mit einem Weg findet, irgendwie alles zu brechen, was ich irgendwann baue ... so rollen sie herum) Secondary für deine Seite könnten SEO-Bedenken mit nicht-konformem Code und Behinderungen für die Barrierefreiheit wie Screenreader-Unterstützung sein . Sie können auch versuchen, zwei ähnliche (einfache) Sites mit beiden Technologien auszugeben und eine Leistungsanalyse durchzuführen. Im Fall einer Website, an der ich gearbeitet habe, wurde sie 1 Million Mal pro Tag geschaltet, und Einsparungen von 5k Dateigröße wurden täglich auf 5g Daten umgerechnet.

Viel Glück! Dies ist nur einer von vielen Gründen, warum ich von großen Firmenjobs mit Java und Oracle weggekommen bin.

0

Ich denke, dass jQuery basierte Komponenten mit einem aktionsbasierten Framework gekoppelt sind. Sie erhalten die vollständige Kontrolle über die Seite, sehr wenige Überraschungen, schnelle Entwicklung und letztendlich eine schnellere Seitenleistung. Ich habe Apps mit JSF- und MS ASPX + DevExpress-Komponenten erstellt. Am Ende will ich nur mehr Kontrolle darüber, was auf meiner Seite landet. jQuery ist HUGELY beliebt, daher gibt es keinen Mangel an JS Talent auf dem Markt. Ajax ist fast ein Kinderspiel mit jQuery zu.

Auch für den Aufbau von datenbankgesteuerten wep-Anwendungen in Java schlägt nichts die Geschwindigkeit des Tagger Cat Frameworks. Es kann MVC der alten Schule sein, aber es ist ernsthaft Datenbank fokussiert, und nett, mit zu arbeiten.