[J2EE] Cross browser JSF

[JKVA]

Ik ben nu al een tijdje bezig met Java Server Faces. Meestal werkt dit prima, echter de HTML/JS die dat framework uitpoept is werkelijk te lelijk voor woorden. Los van het feit dat er soms ID's worden gegenereerd van 100+ karakters lang, wordt een hyperlink op een hele vreemde manier opgebouwd. (of ik doe iets verkeerd)

Een link in mijn menu: (op server)

Java:

                <h:commandLink action="projectOverview">
                    <f:verbatim>
                        <img ... />
                    </f:verbatim>
                </h:commandLink>

En deze HTML wordt gegenereerd:

HTML:

<a href="#" onclick="clear_navigation();document.forms['navigation'].elements['navigation:_link_hidden_'].value='navigation:_id0';if(document.forms['navigation'].onsubmit){var result=document.forms['navigation'].onsubmit();  if( (typeof result == 'undefined') || result ) {document.forms['navigation'].submit();}}else{document.forms['navigation'].submit();}return false;" id="navigation:_id0">
                        [img]"images/menu/projecten_off.gif"[/img]
                    </a>

Los van het feit dat het nogal lelijk is en niet goed voor het netwerkverkeer, (vind ik al reden genoeg om er iets tegen te doen ) werkt de complete navigatie niet wanneer ik met mijn Firefox Dev Toolbar JavaScript uitzet.

Iemand hier een oplossing voor? Eventueel in de vorm van een andere implementatie, zoals ADF Faces van Oracle, waar ik zelf geen enkele ervaring mee heb.

[Verwijderd]

Al die JavaScript wordt gegenereerd omdat je een commandlink gebruikt. Een commandlink doet een POST op het form, en als link heb je daar wat JS voor nodig. Je zou het kunnen proberen met een image button, even geen idee meer wat het JSF tag daarvoor is.

[JKVA]

Dat is een commandLink tag met een outputImage tag ertussen. Dat gebruik ik nu en werkt niet. Ik vind het alleen zo raar dat hij per se een form wil posten, terwijl dat lang niet altijd nodig is. De meeste links op internet zijn gewoon GET links.

[bloody]

JKVA schreef op dinsdag 28 maart 2006 @ 16:10:

...niet goed voor het netwerkverkeer...

Heb je in de praktijk geen last van

Volgens mij kun je ipv die verbatim en img ook een t:htmlTag gebruiken.

Als je wilt GETten kun je eens kijken naar h:outputLink

[Verwijderd]

JKVA schreef op dinsdag 28 maart 2006 @ 16:10:
Los van het feit dat het nogal lelijk is en niet goed voor het netwerkverkeer, (vind ik al reden genoeg om er iets tegen te doen ) werkt de complete navigatie niet wanneer ik met mijn Firefox Dev Toolbar JavaScript uitzet.

He! Das vreemd. Ik heb zelf ook vaak van dergelijke dingen. Zet ik bijvoorbeeld mijn monitor uit, kan ik mijn desktop niet meer zien. Ook zo raar, zet ik mijn web server uit, kan ik mijn pagina's niet meer op vragen.

Serieus, natuurlijk moet je javascript niet gaan uitzetten. Het is nogal logisch dat het dan niet meer werkt. Er staat geloof ik vrij duidelijk in de JSF spec dat voor de standaard HTML renderkit de client minimaal support voor Javascript moet hebben. Ben jij ook zo iemand die javascript gaat uizetten en dan afvraagt waarom AJAX niet meer werkt?

In de praktijk maakt het eigenlijk alleen voor Google uit: de googlebot kan geen javascript triggered links volgen, dus voor publieke pagina's die je ge-indexeerd wilt hebben moet je hier dus omheen werken (of geen JSF gebruiken, of flink wat extra moeite willen doen).

[JKVA]

Verwijderd schreef op woensdag 29 maart 2006 @ 20:33:
He! Das vreemd. Ik heb zelf ook vaak van dergelijke dingen. Zet ik bijvoorbeeld mijn monitor uit, kan ik mijn desktop niet meer zien. Ook zo raar, zet ik mijn web server uit, kan ik mijn pagina's niet meer op vragen.

Die vergelijking vind ik nogal uit zijn verband gerukt eerlijk gezegd. Het punt wat ik probeerde te maken was dat het nogal omslachtig is om een link met javascript te maken. Je kunt de HTML voor geen meter meer lezen omdat het drie regels ofzo in beslag neemt, bovendien is het nogal lelijke JS naar mijn idee.

Bovendien is die JavaScript voor 9 van de 10 gevallen overbodig, zie 99 van de 100 links op internet. En vooral voor navigatie vind ik dat het wel in elke browser mag werken, anders is het: Daaaag JSF-je daaahaaag daaahaaag, hallo .NET.

@bloody: Die outputlink klinkt vrij aardig, die gaan we eens proberen.

edit:
Hmm, die outputlink werkt niet voor interne links. Op zich wel logisch, want JSF heeft natuurlijk allemaal metadata nodig van de client. Toch jammer.

[ Voor 9% gewijzigd door JKVA op 30-03-2006 09:55 ]

[pjonk]

JKVA schreef op donderdag 30 maart 2006 @ 09:46:
[...]
Bovendien is die JavaScript voor 9 van de 10 gevallen overbodig, zie 99 van de 100 links op internet. En vooral voor navigatie vind ik dat het wel in elke browser mag werken, anders is het: Daaaag JSF-je daaahaaag daaahaaag, hallo .NET.

Maak je niet teveel ilusies. ASP.NET heeft ook zo zijn problemen met compliant HTML rendering, semantische correcte HTML en accessibility. Ik ben het ook met je eens dat JavaScript moet worden vermeden als het ook zonder kan. Ik moet je wel zeggen dat ik nog met ASP.NET 1.1 heb gewerkt. Het schijnt dat in ASP.NET 2.0 een hoop verbeterd is.

Ben geen Java expert, maar misschien is het ook een optie om met Velocity te gaan werken? Een hoop frameworks maken gebruik van deze engine waarmee je wel volledige controle hebt over je HTML output.

[ Voor 16% gewijzigd door pjonk op 30-03-2006 10:03 ]

[JKVA]

pjonk schreef op donderdag 30 maart 2006 @ 10:00:
[...]
Ben geen Java expert, maar misschien is het ook een optie om met Velocity te gaan werken? Een hoop frameworks maken gebruik van deze engine waarmee je wel volledige controle hebt over je HTML output.

Helaas, we zitten middenin een JSF project en dat overstappen is geen optie.

Het schijnt trouwens dat Oracle's ADF Faces wel cross browser HTML genereert. Ben benieuwd of dat ook cross-browser-zonder-javascript is.

[Verwijderd]

JKVA schreef op donderdag 30 maart 2006 @ 09:46:
Bovendien is die JavaScript voor 9 van de 10 gevallen overbodig, zie 99 van de 100 links op internet. En vooral voor navigatie vind ik dat het wel in elke browser mag werken,

Javascript werkt gewoon in elke browser hoor!? Als jij Netscape 1 compliant wil zijn is natuurlijk je goed recht, maar dat betekend niet perse dat JSF daarom slecht is. Natuurlijk kan het altijd beter, en vergeet bovendien niet dat de huidige JSF spec eigenlijk een soort preview is. Bruikbaar, dat zeker, maar met veel kleine tekortkomingen (content interweaving, EL, etc).

De gewone hyperlinks in HTML zijn eigenlijk nooit bedoeld om remote applications mee te bouwen. Hyperlinks zijn bedoeld om hypertext te browsen, niets meer en niets minder. Wil je remote applications binnen een HTML browser draaien die de richness van een desktop applicatie benaderen dan zul je moeten begrijpen dat je ook echt een applicatie bouwt en niet een statische informatie bron. Dingen als een 'naked link' maar ook bookmarks en de back-button worden dan opeens wat minder vanzelfsprekend. Kijk bijvoorbeeld maar eens naar GMail.

Het punt is dat frameworks als JSF een statefull GUI moeten zien te emuleren binnen een stateless protocol (HTTP). Als jij alleen een pure link neerzet, dan is er veel informatie van de huidige state van je GUI die niet meegezonden kan worden, waardoor het hele principe van een statefull GUI dus niet meer kan werken.

Je kunt dus niet zomaar zeggen, ik zet Javascript uit en hey, dat stomme JSF werkt dan niet meer, omdat Javascript juist een essentieel onderdeel van het systeem is. Je kunt dan wel weer zeggen dat je dan een ander framework pakt die je WEL de controlle geeft over de HTML output, maar dan snap je JSF (en ASP.NET!) niet. Beiden proberen juist te abstraheren van die low-level concepten.

In zekere zin kun je JSF en ASP.NET als een soort van dynamische compilers zien. Je werkt zelf met een high-level taal waaruit een lagere level taal gegenereerd wordt (HTML + Javascript) die door de machine (=de browser) wordt uitgevoerd. Vergelijk dit met de weerstand om assembly op te geven bij de oude C programmeurs. Hedentendage wordt programmeren in assembly als totaal onzinnig gezien voor (grote) business aplicaties. Alleen kleine embedded dingen of (stukjes van) drivers worden nog in assembly, niemand, maar dan ook echt helemaal niemand gaat een complete business applicatie nog geheel in assembly schrijven.

Net zoals C nog heel erg dicht tegen de machine aanlag, C++ al minder, en Java + C# nog minder, zo zal programmeren voor het web een zelfde soort evolutie ondergaan. Momenteel zitten veel mensen nog in assembly te programmeren: puur JSP of PHP met direct code en HTML door elkaar. JSF en ASP.NET zitten meer in de C fase. Je abstraheert van HTML, maar je zet op een JSF pagina nog wel af en toe direct HTML constructies (vergelijk: inline asm in C) en af en toe MOET je nog direct het request object gebruiken (vergelijk: gebruik maken van machine call conventions in C).

anders is het: Daaaag JSF-je daaahaaag daaahaaag, hallo .NET.

Tsja, .NET is zeker een hele mooie techniek. Maar vergis je niet hoor, .NET lijkt *heel* erg op JSF.