JSF Verwirrung: JSF und generiertes HTML sieht 'cryptisch' aus

[JayGabriel]

Hallo,

da JSF ja ein Framework ist und die HTML Seiten aus den Facelets generiert werden, sieht danach die Seite nun natürlich nicht so aus, wie man es mit purem Einhämmern von HTML Tags erreichen würde. Das hat mich bisher auch nicht weiter gestört, doch nun meinten andere Programmierer (die sich seit kurzem mit JSF beschäftigen) in meiner Gruppe, das wäre unschön und nicht akzeptabel.

Um ehrlich zu sein, bin ich nun etwas verwirrt, weil ich bisher noch nie darauf geachtet habe. ???:L
Ist es wirklich essenziell, dass zum Schluss wunderschöner HTML Code entsteht? Worin besteht der Vorteil, außer in der guten Lesbarkeit für den Menschen? Nach Meinung einer Kollegin würde das in PHP + Zendframework oder Wicket kein Problem sein.
Direkt haben sie sich über die vielen Form Tags und das HiddenField mit dem ellenlangen 'Rattenschwanz' (<- vorallem deswegen) auf jeder Seite beschwert. (Frage nebenbei: wozu genau ist eigentlich dieses HiddenField mit dem Namen "javax.faces.ViewState"? Dient es nur, um den ViewState der Seite anzugeben?)

Wie könnte ich das umgehen? Ich weiß, dass JSF immer ein FormTag um die Komponenten haben muss, so habe ich zumindest die Seiten soweit angepast, dass ich diese immer nur ein Mal pro Seite habe, auch wenn ich diese mit Tiles (Templating) zusammensetze. Vorher waren sie natürlich nicht geschachtelt, aber die Tiles alle in einem seperaten FormTag. Trotzdem sind es noch zu viele und sie arbeiten nun mit HTML Tags (divs und co), um die FormTags zu umgehen.

Und bei dem HiddenField komme ich nicht weiter. Kann ich das irgendwie verkürzen?
Auch wenn ich einen Anhang von

value="C7uZHAehxeVC6TtF5ulYJBFu0kVk2IuvHUzb6q7IuMUavveD0p3vHtkRWr1J9nGpZeb0LZs9+8pVCr/WxgMkzVjzzf0upAOMHH8JsnqrE8HLvTJHw9Gh2O6IsFjHY3ODRYaRlcgeXUhAIMtwKpYeCosI6uY="

nicht gerade besonders schlimm finde, stört es die andren.
Ich bin mir nicht ganz sicher, aber ich habe im Hinterkopf, dass dieses HiddenField auftauchte, als ich den ContextParameter "State_Saving_Methode" auf "client" gesetzt hatte, um den "ViewExpired" Exceptions vorzubeugen. Was könnte ich da vielleicht umstellen/umprogrammieren?

Gibt es noch andere ContextParameter, die ich setzen könnte, damit der HTML Code zum Schluss 'schicker' wird? SKIP_COMMENTS und PRETTY_HTML habe ich beides schon auf "true".

Zur Zeit verwenden wir noch JSF 1.2 (MyFaces), würde eine Umstellung auf JSF 2.0 schon etwas bringen?

Ich habe auch mal gelesen, dass HTML Tags und JSF Tags nicht gemischt werden sollten. Was ist da dran? Ich selbst arbeitete bisher immer nur mit JSF Tags, doch die anderen in meiner Gruppe fingen nun an HTML Tags einzupuzzlen und JSF Tags gegen entsprechende HTML Tags auszutauschen, wo ihnen etwas nicht gefiel.

Ich hoffe, jemand von euch hier kann mir da unter die Arme greifen und etwas Ordnung in meine Verwirrung bringen. Ich möchte ja nichts schlechtes abliefern, doch auf den generierten HTML Code habe ich bisher noch nie so extrem geachtet, außer er war jetzt deutlich anders/falsch/aufgebläht, als ich es von der dargestellten Seite erwarten würde.

Viele Grüße,
Jay

 

[JanHH]

Hm also entweder man benutzt und JSF und arbeitet damit dann halt so, wie es gedacht ist, und lässt sich darauf ein, und das bedeutet dann halt, dass der generierte HTML-Code nicht so schick ist (was aber in der Tat völlig egal ist) und dass man nicht direkt mit HTML-Tasg arbeiten solllte, oder, wenn man zu diesen "Zugeständnissen" nicht bereit ist, ist man evtl. mit JSF auch nicht gut bedient.

Ich würde vermuten, das "Problem" ist eher ein psychologisches bei den Kollegen, die vielleicht nicht tolerant oder motiviert sind, sich auf JSF einzulassen, und lieber ihre von HTML und php gewohnte Arbeitsweise beibeihalten wollen. Das wird dann natürlich nix.

HTML-Tags funktionieren teilweise, werden aber nicht unbedingt immer sauber in den JSF-View-Tree eingebaut. Beispiel:

<hanelGrid columns="1">
<b>Hallo JSF</b>
</hanelGrid>

Das erzeugt drei Tabellenzeilen/-zellen, eine mit dem <b>, eine mit "Hallo JSF" und eine mit </b>. Führt in einigen Browsern zu Fehlermeldungen und ist natürlich murks. Daran dürfte das Problem klar werden.

Eigentlich ist die einzige Stelle, wo man direkt Zugriff auf den HTML-Code braucht, die IDs einiger Komponenten, wenn man diese mit selbst gebautem javascript beeinflussen will. Aber dafür sieht JSF ja Möglichkeiten vor.

Ein weiterer Punkt ist das etwas unsinnige Credo "niemals tabellen für Layout verwenden!", da wird bei JSF ja fleissig gegen verstossen (siehe hanelGrid).

Es ist immer schwierig, Leute dazu zu bringen, sich auf neue/andere Technologien als die gewohnten einzulassen, sie werden immer was finden, was ihnen nicht passt. Und gerade JSF ist da ja ein beliebtes Feindbild (weil es zugegebenermassen bis einschliesslich version "1.2 ohne seam" in der tat diverse gravierende Mängel hatte).

 

[Andgalf]

Ein weiterer Punkt ist das etwas unsinnige Credo "niemals tabellen für Layout verwenden!"

Sorry, aber dieses Credo ist überhaupt nicht unsinnig! Eine Tabelle ist nun mal kein Layout Element. Und wer sich mal mit Barrierefreiheit beschäftigt hat, weiß auch warum man keine Tabellen zum "layouten" nimmt.

Ein Screen-Reader zum Beispiel versteht den Unterschied zwischen einer "Layout-Tabelle" und einer wirklichen Tabelle einfach nicht.

Und man kann auch mit JSF arbeiten, ohne Tabellen zum layouten zu missbrauchen.

 

[JanHH]

Das ist genau das was ich meinte ;-).

Übrigens ist eine Tabelle sehr wohl ein Layout-Element, denn was macht sie anderes, als Inhalte tabellarisch DARZUSTELLEN? Aber ich werd mich nun garantiert nicht an dieser Stelle auf diese Diskussion einlassen. Da soll jeder glauben was er will.

Erinnert mich an die Geschichte von der Hummel, die eigentlich fliegen können dürfte.. kümmert sie aber nicht, und tut es einfach trotzdem.

 

[maki]

Ach, JSF 1.x hat noch ganz andere Probleme als unschönes Markup... trotzdem ist es natürlich richtig, dass man zum Layouten <div> verwenden sollte anstatt Tabellen.

Hat imho weniger mit der Hummel zu tun als damit, dass man auch ein Bügeleisen nehmen könnte um Nägel in die Wand zu hauen...

 

[mvitz]

Das ist genau das was ich meinte ;-).

Übrigens ist eine Tabelle sehr wohl ein Layout-Element, denn was macht sie anderes, als Inhalte tabellarisch DARZUSTELLEN? Aber ich werd mich nun garantiert nicht an dieser Stelle auf diese Diskussion einlassen. Da soll jeder glauben was er will.

Erinnert mich an die Geschichte von der Hummel, die eigentlich fliegen können dürfte.. kümmert sie aber nicht, und tut es einfach trotzdem.

Da braucht man nicht diskutieren, eine Tabelle hat eine klare semantische Bedeutung und sollte auch nur dann verwendet werden, wenn diese gegeben ist. Die Trennung einer Seite in Header, Footer, Navigation und Content gehört definitiv semantisch NICHT in eine Tabelle

 

[nocturne]

Hallo Jay,

JSF hat nicht die Aufgabe "schickes" HTML zu generieren. JSF bietet gelöste Probleme - wie das umgehen von SessionCookies in Form von Hidden-Felds. Oder das Problem der schnellen Validation von Eingabewerten.

Möglicherweise haben deine Kollegen Vorbehalte gegen Fremdcode, oder Vorbehalte gegen etablierte Problemlösungen von anderen Entwicklern.

Zu deinem Hidden-Field.
Gehen wir einmal davon aus, dass der Benutzer plötzlich die Browser-Cookies deaktiviert. Die Session wäre verloren wenn man nicht einen eindeutigen Anker definier - das ist dein Hidden-Feld.

Gruß

 

[JanHH]

Wenn der User Cookies deaktiviert hat, wird die jsessionid automatisch in die Links und Formulare auf der Seite eingebaut. Damit hat das hidden field nix zu tun. Da gehts, wie schon gesagt, um state-saving-modus "client". Beide Modi haben Vor- und Nachteile (ist mir auch nicht ganz klar, aber server wohl: der generierte HTML-Code ist kürzer, Session muss nicht aus dem Response neu erstellt werden (performance), client: weniger Speicherverbrauch auf dem Server, ausserdem resistent gegen session timeouts, so in etwa...).

Was die Table angeht, wundert es mich (unabhängig von meiner persönlichen Meinung dass gegen eine Table eigentlich nix spricht ausser der Barrierefreiheits-Sache) allerdings, dass die Standard-JSF-Layout-Komponenten (hanelGrid) mit Tables arbeiten, man also zwangsläufig eine Seite hat, wo alles voller Tables zwecks Layout ist. Habe darauf allerdings auch einen Experten im java-Web-Bereich angesprochen und der meinte, dass der Grund dafür u.a. wäre, dass halt das besagte Credo arg übertrieben ist und von vielen Leuten etwas zu verbissen gesehen wird.

Was gibts denn da so für Alternativen?

 

[JanHH]

Wäre doch ansonsten mal eine hübsche Aufgabe, z.b. als Bacherlor-Arbeit.. eine JSF-Taglib, die schönes HTML erzeugt.

 

[Andgalf]

Was gibts denn da so für Alternativen?

ui:fragment

 

[JanHH]

Versteh ich nicht ;-).

Also angenommen, drei Zeilen sollen untereinander ausgegeben werden.

<hanelGrid columns="1">
<hutputText value="Zeile 1"/>
<hutputText value="Zeile 2"/>
<hutputText value="Zeile 3"/>
</hanelGrid>

Das dann ohne <br /> und auch ohne <hanelGrid>? Wie geht das?

 

[Sym]

Mit <div /> und entsprechendem CSS.

 

[JanHH]

OHNE direkt HTML-Code zu benutzen!

(wenn man div benutzt, kann man auch br benutzen)

 

[Sym]

OHNE direkt HTML-Code zu benutzen!

(wenn man div benutzt, kann man auch br benutzen)

Aber ein div zu verwenden ist vollkommen legitim. Es gibt auch genug Frameworks, die ein eigenes div-Tag bereitstellen.

Ein br sollte man nicht verwenden, um die Layouteigenschaft aus dem xhtml-Code heraushalten zu können. Das schließt auch ein tr/td mit sein, sofern es nur einer Layouteigenschaft entspricht.

 

[JanHH]

Naja man kriegt ja auch schon mit <hanelGroup layout="block"> ein div.

Wäre ja ansonsten auch mal eine anspruchsvolle Herausforderung, ein Tag zu programmieren, welches ein <br /> erzeugt.

 

[Sym]

Ein Tag zu programmieren, welches ein <br /> erzeugt, wäre ebenfalls Mist.

In der Regel möchte man das Design aus dem xhtml-code fern halten.

 

[JayGabriel]

Vielen Dank an alle, die hier so fleißig gepostet haben!

Tut mir Leid, dass ich mich erst jetzt wieder melde, aber eure Posts haben mir eindeutig weiter geholfen!

Zum einen bin ich erleichtert, dass ich mich nicht nur blöd angestellt habe, weil ich den HTML Code nicht 'schöner' hinbekommen habe und zum andren, dass das eigentlich nicht zu 'wichtig' ist, solang der Code natürlich nicht zu aufgebläht ist, versteht sich.

trotzdem ist es natürlich richtig, dass man zum Layouten <div> verwenden sollte anstatt Tabellen.

Gut, dass ich das nun auch weiß. Und diese ganze Disskusion über Tabelle als Layoutelement oder nicht ist schon interessant. Um ehrlich zu sein, habe ich von Anfang an immer eher mit Tabellen als mit divs gearbeitet und auch nichts vermisst oder als unschön empfunden. Aber Barrierefreitheit war bei meinen privaten Projekten auch noch nicht weiter so bedeutsam.
Da werde ich mich mal etwas mehr mit noch beschäftigen, irgendwie finde ich das Thema interessant.

Wenn der User Cookies deaktiviert hat, wird die jsessionid automatisch in die Links und Formulare auf der Seite eingebaut. Damit hat das hidden field nix zu tun. Da gehts, wie schon gesagt, um state-saving-modus "client". Beide Modi haben Vor- und Nachteile (ist mir auch nicht ganz klar, aber server wohl: der generierte HTML-Code ist kürzer, Session muss nicht aus dem Response neu erstellt werden (performance), client: weniger Speicherverbrauch auf dem Server, ausserdem resistent gegen session timeouts, so in etwa...).

So ähnlich hatte ich das auch noch im Kopf, also dass ich das damals eingebaut hatte, weil mir immer diese ViewExpiredException um die Ohren geflogen ist, wenn die Session abgelaufen war, war mir nur nicht mehr ganz so sicher.

Aber ein div zu verwenden ist vollkommen legitim.

Naja man kriegt ja auch schon mit <hanelGroup layout="block"> ein div.

Also aus den ganzen Posts um HTML Tags in JSF JA oder NEIN, schließe ich, dass, ich nenn sie mal "Einteilungstags" okay sind, aber Layout Tags nicht so gern gesehen sind. Und wieder bin ich etwas schlauer geworden. Dass

<h:panelGroup layout="block">

auch ein DIV generiert, wusste ich nicht. Da zeigt sich wieder mal, dass ich zuviel mit Tabellen arbeite und ich mich mit dem Layout an sich auch noch nie groß beschäftigt habe. Da besteht noch großer Nachholebedarf bei mir.

JSF 1.x hat noch ganz andere Probleme als unschönes Markup...

Hat JSF 2.x da denn deutlich aufgeholt und sich verbessert? Dann wäre es ja auch eine Überlegung wert, das noch einmal auszuprobieren.

Viele Grüße,
Jay

 

[maki]

Hat JSF 2.x da denn deutlich aufgeholt und sich verbessert? Dann wäre es ja auch eine Überlegung wert, das noch einmal auszuprobieren.

Ja, JSF 2.x ist in vielen Details um einiges besser/sauberer.
Von JSF 1.x würde ich komplett abraten wenn man schon die Wahl zwischen 1.x und 2.x hat...

 

[JayGabriel]

Ja, JSF 2.x ist in vielen Details um einiges besser/sauberer.
Von JSF 1.x würde ich komplett abraten wenn man schon die Wahl zwischen 1.x und 2.x hat...

Vielen Dank für die schnelle Antwort!
Dann werde ich das auch noch einmal vorschlagen und auch selbst ausprobieren, inwieweit was noch angepasst werden muss, um dann auf JSF 2.x umsteigen zu können.

Viele Grüße,
Jay