[JSF] Het includen van JSF pagina en render probleem

donderdag 3 januari 2008 23:07

Prutser 1e klasse

Topicstarter

Van IOExceptions heb ik geen last. Alleen lijkt het wel dat JSF eerst de tags rendered en dan pas de HTML die in de include staat.

Misschien maar even tijdelijk de include weglaten en de code in alle jsf pagina's opnemen.

The ships hung in the sky in much the same way that bricks don’t.

Acties:

Nick_S

++?????++ Out of Cheese Error

Dat je van IO excepties geen last hebt klopt, aangezien je hem de extensie jsp en niet jsf gegeven hebt. Hij word dus niet nog een keer geparsed. JSF bouwt inderdaad eerst z'n component tree op en gaat daarna pas andere dingen bekijken.

Ik doelde meer op dit stukje:

You would have thought that including one page in another was a simple thing to do. You would be greatly mistaken if you held this notion for JSF. A number of querks with the way JSF is integrated with JSP make includes supprisingly difficult. Actually that's not strictly true. Includes are quite easy as long as you only want to include verbatim HTML with no JSF tags which I think is fairly unlikely.

edit:
Kijk ook even hier naar: Facelets fits JSF like a glove

Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove.

vv Zie quote.

[ Voor 14% gewijzigd door Nick_S op 03-01-2008 23:16 ]

'Nae King! Nae quin! Nae Laird! Nae master! We willna' be fooled agin!'

donderdag 3 januari 2008 23:14

Acties:

donderdag 3 januari 2008 23:28

Prutser 1e klasse

Topicstarter

Ah, dat stukje had ik net even gemist. Wordt dus toch facelets in de toekomst. Hoe meer ik met JSF bezig, hoe meer JSP begint te zuigen

The ships hung in the sky in much the same way that bricks don’t.

Acties:

Nick_S

++?????++ Out of Cheese Error

Een aantal artikelen die ik erg goed vond over facelets:
Inside Facelets Part 1: An Introduction
Inside Facelets Part 2: Using Facelets
Inside Facelets - Part 3: Templating and Re-Use
Advanced Facelets programming

En kijk eens naar Appfuse voor het opzetten van je JSF/Facelets/Spring/Hibernate project met Maven 2. (Eigenlijk een aantal webfrontends, ook Spring MVC, Tapestry en Struts 2, en backend (Spring, Hibernate) is optioneel).

'Nae King! Nae quin! Nae Laird! Nae master! We willna' be fooled agin!'

vrijdag 4 januari 2008 00:03

Acties:

vrijdag 4 januari 2008 11:05

Prutser 1e klasse

Topicstarter

AppFuse zit er interessant uit. Ga ik binnenkort even proberen!

The ships hung in the sky in much the same way that bricks don’t.

Acties:

woensdag 9 januari 2008 11:45

Design-by-buzzword fanatic

Standeman schreef op vrijdag 04 januari 2008 @ 00:03:
AppFuse zit er interessant uit. Ga ik binnenkort even proberen!

Facelets is idd de moeite waard. Ik heb JSF ongeveer 2 maanden in combinatie met JSP gebruikt toen Facelets voor het eerst uitkwam. Ben meteen overgestapt en wil niet terug. Jammergenoeg moest het afgelopen jaar een keer voor een onderhoudsklusje.

Facelets is de eerste plug-in die ik iedereen aanraad als ze met JSF gaan werken.

Je moet alleen wel een paar dingen in je achterhoofd houden:
- Facelets is geen standaard
- Facelets wordt niet door elke 3th party even goed ondersteund (component libraries, tools)
- IDE support zoals code completion is voor Facelets lastig te implementeren. Dat heeft te maken met de karakteristieken van Facelets. Gevolg, alleen Exadel Studio (heet tegenwoordig JBoss Tools) heeft fatsoenlijke IDE support. Maar dat is XSD gebaseerd, dus zelfs in Exadel Studio is de support beperkt tot de standaard libraries zoals Core, HTML, Tomahawk, Ajax4jsf en nog een paar.

AppFuse is dan idd een gemakkelijke manier om je project snel in elkaar te jassen.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

btoek

Verbatim was voor mij wel de oplossing, de code is nu zo:

Java Server Faces:

<f:verbatim><span class="tabactive" ></f:verbatim>
    <f:verbatim>&nbsp;</f:verbatim>
    <h:commandLink 
        id="submitbutton1" 
        action="klantidentificatie" 
        styleClass="tabactive"
        onkeypress="hX.getComponentById('form1:bar1').start('#{msg['label.progressbar']}');" 
        onmousedown="hX.getComponentById('form1:bar1').start('#{msg['label.progressbar']}');">
        <h:outputText value="Klantidentificatie"></h:outputText>
    </h:commandLink>
    <f:verbatim>&nbsp;</f:verbatim>
    <f:verbatim>
    <img src="pictures/hoekie.gif" border="0" style="position:relative; top:-8px; ">
    </f:verbatim>
<f:verbatim></span></f:verbatim>

Zo was de code:

Java Server Faces:

<span class="tabactive" >
    <f:verbatim>&nbsp;</f:verbatim>
    <h:commandLink 
        id="submitbutton1" 
        action="klantidentificatie" 
        styleClass="tabactive"
        onkeypress="hX.getComponentById('form1:bar1').start('#{msg['label.progressbar']}');" 
        onmousedown="hX.getComponentById('form1:bar1').start('#{msg['label.progressbar']}');">
        <h:outputText value="Klantidentificatie"></h:outputText>
    </h:commandLink>
    <f:verbatim>&nbsp;</f:verbatim>
    <img src="pictures/hoekie.gif" border="0" style="position:relative; top:-8px; ">
</span>

Zonder verbatim werden het geheel door elkaar gegooid.

woensdag 9 januari 2008 11:53

Acties:

BalusC

Carpe diem

Upgrade naar JSF 1.2: http://javaserverfaces.dev.java.net

In JSF 1.1 worden rauwe HTML elementen niet opgenomen in de viewroot, tenzij uitdrukkelijk aangegeven door deze met f:verbatim te omsluiten. In JSF 1.2 is deze "beperking" weggenomen.

Die ranzige   dingen zou ik overigens gewoon door CSS margin/padding vervangen. Staat netter. Mocht JSF 1.2 geen optie te zijn, dan kun je ook gewoon <h:grapicImage> ipv <img> gebruiken en <h:panelGroup> ipv <span>.

[ Voor 117% gewijzigd door BalusC op 09-01-2008 11:57 ]

woensdag 9 januari 2008 15:16

Acties:

woensdag 9 januari 2008 15:51

Design-by-buzzword fanatic

BalusC schreef op woensdag 09 januari 2008 @ 11:53:
Upgrade naar JSF 1.2: http://javaserverfaces.dev.java.net

In JSF 1.1 worden rauwe HTML elementen niet opgenomen in de viewroot, tenzij uitdrukkelijk aangegeven door deze met f:verbatim te omsluiten. In JSF 1.2 is deze "beperking" weggenomen.

Die ranzige   dingen zou ik overigens gewoon door CSS margin/padding vervangen. Staat netter. Mocht JSF 1.2 geen optie te zijn, dan kun je ook gewoon <h:grapicImage> ipv <img> gebruiken en <h:panelGroup> ipv <span>.

Of Facelets. Daarin hebben ze al vooruitgelopen op JSF 1.2 en dat werkt ook prima.

Als een upgrade naar JSF 1.2 mogelijk is (let op: afhankelijk van Servlet 2.5 + JSP 2.1) zou ik dat zeker doen. Ik zou dan ook kiezen voor de Sun Reference Implementation, in plaats van MyFaces. Die is stukken volwassener. Aan de MyFaces Core gebeurt weinig meer.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

woensdag 9 januari 2008 23:32

Prutser 1e klasse

Topicstarter

Voorlopig zit ik nog aan Tomcat 5 gebonden dus ook aan Servlet 2.4. Dus is JSF 1.2 nog niet echt een mogelijkheid. Wat dat betreft zie ik facelets een stuk beter zitten.

The ships hung in the sky in much the same way that bricks don’t.

Acties:

vrijdag 11 januari 2008 08:59

Standeman schreef op woensdag 09 januari 2008 @ 15:51:
Voorlopig zit ik nog aan Tomcat 5 gebonden dus ook aan Servlet 2.4. Dus is JSF 1.2 nog niet echt een mogelijkheid. Wat dat betreft zie ik facelets een stuk beter zitten.

Zoals al dikwijls opgemerkt in dit forum; met Facelets heb je geen Servlet 2.5/JSP 2.1 nodig. Het is een totale vervanging voor JSP.

Dit is overigens geen inherente tekortkoming van JSF. In zoiets als Facelets was expliciet voorzien bij het opstellen van de architectuur van JSF. JSP is binnen java alleen de default templating language. Het feit dat b.v. de pagecontext uit JSP niet binnen JSF beschikbaar is, is expres gedaan omdat alternatieve templating languages niet perse zoiets zouden hoeven te kennen als een pagecontext. Ook diverse types in de API (external context etc) hebben expres geen koppelingen naar dingen uit Servlets of JSP.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

zondag 13 januari 2008 22:16

Prutser 1e klasse

Topicstarter

Ik bedoelde het ook in de context van: Gezien ik geen tijd heb om me nu in facelets te verdiepen en gebonden ben aan Tomcat 5 ben ik min of meer gebonden aan JSF 1.1 i.p.v. 1.2.

Niet dat dat zo'n probleem is, JSF heeft wel meer rare dingen (in mijn ogen).

The ships hung in the sky in much the same way that bricks don’t.

Acties:

maandag 14 januari 2008 07:31

Standeman schreef op vrijdag 11 januari 2008 @ 08:59:
Niet dat dat zo'n probleem is, JSF heeft wel meer rare dingen (in mijn ogen).

Dat klopt, JSF 1.1 heeft een aantal rare dingen. Niet zo verwonderlijk aangezien het in zekere zin gold als een preview versie (preview voor de eerste versie die standaard in Java kwam). De versie nummering is daarbij een beetje verwarrend.

Gelukkig is Java EE 5 met daarin JSF 1.2 in principe voor iedereen te gebruiken

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

maandag 14 januari 2008 09:29

Design-by-buzzword fanatic

flowerp schreef op zondag 13 januari 2008 @ 22:16:
[...]

Dat klopt, JSF 1.1 heeft een aantal rare dingen. Niet zo verwonderlijk aangezien het in zekere zin gold als een preview versie (preview voor de eerste versie die standaard in Java kwam). De versie nummering is daarbij een beetje verwarrend.

Gelukkig is Java EE 5 met daarin JSF 1.2 in principe voor iedereen te gebruiken

Ik denk dat ie meer doelt op rare designkeuzes in het framework (zoals alles stateful, lifecycle, componentenmodel, renderkits...).
Maar goed, dat is met JSF 2.0 ook allemaal opgelost (hoop ik).

Fat Pizza's pizza, they are big and they are cheezy

Acties:

maandag 14 januari 2008 09:53

Prutser 1e klasse

Topicstarter

Een klein voorbeeldje in het component model is bijvoorbeeld het SelectOneMenu. Ik snap niet dat het object niet UIData implementeert i.p.v. UIInput. Dat scheelt weer een aantal backing maps of converters. Wat is nou werkelijk het verschil tussen een SelectOneMenu en DataTable behalve het renderen en dat een SelectOneMenu single column is die je uit kan klappen?

Ook vind ik het vreemd dat UIInput UIOutput extend. Op zich wel een beetje logisch als je kijkt naar functionaliteit, maar "gevoelsmatig" heb ik dan gelijk het idee dat het niet klopt.

The ships hung in the sky in much the same way that bricks don’t.

Acties:

maandag 14 januari 2008 11:19

Design-by-buzzword fanatic

Standeman schreef op maandag 14 januari 2008 @ 09:29:
Een klein voorbeeldje in het component model is bijvoorbeeld het SelectOneMenu. Ik snap niet dat het object niet UIData implementeert i.p.v. UIInput. Dat scheelt weer een aantal backing maps of converters. Wat is nou werkelijk het verschil tussen een SelectOneMenu en DataTable behalve het renderen en dat een SelectOneMenu single column is die je uit kan klappen?

Ook vind ik het vreemd dat UIInput UIOutput extend. Op zich wel een beetje logisch als je kijkt naar functionaliteit, maar "gevoelsmatig" heb ik dan gelijk het idee dat het niet klopt.

Tja, ze zouden het ook UIOutputAndInput kunnen noemen. Dan klopt het met de functionaliteit, maar het klinkt voor geen meter.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

maandag 14 januari 2008 21:37

Prutser 1e klasse

Topicstarter

Dat wel

Maar goed, ik leer er wel mee leven

The ships hung in the sky in much the same way that bricks don’t.

Acties:

maandag 14 januari 2008 22:07

Standeman schreef op maandag 14 januari 2008 @ 09:29:
Een klein voorbeeldje in het component model is bijvoorbeeld het SelectOneMenu. Ik snap niet dat het object niet UIData implementeert i.p.v. UIInput.

Dat is eigenlijk niet het JSF component model zelf, maar een toevallig specifiek component wat in jouw ogen een niet handige manier van werken heeft. Een makkelijke analogie is het Java Class model. Dat schrijft voor wat een Class is, wat de betekenis is van public, protected en nog veel meer. Je zegt dan toch ook niet dat het Java Class model raar is omdat je de concrete class Hashtable niet handig vind?

Zelfs al wordt Hashtable door Sun zelf meegeleverd, dan nog betekend dat niet dat je aan de hand van de werking van die ene class iets kan zeggen over het class model zelf.

Het is bekend dat de meegeleverde standaard components bij core JSF heel erg beperkt zijn. Het zijn er weinig, er zit niets flashy of fancy tussen, en zelfs voor de eenvoudige dingen die deze doen zitten er nog enkele tekortkomingen in (zoals b.v. dataTable die na een click het data model positioneert op basis van rij nummer i.p.v. op key basis).

Echter je moet bedenken dat JSF zelf niet een all-inclusive web framework is, maar een faciliterend platform, de basis voor een heel eco-system van componenten libs en extenties. Na verloop van tijd zal Sun ook wel aan haar eigen standaard library gaan werken. Vergelijk het hier ook weer met de taal Java zelf. De std. library in Java 1.0 was heel klein en beperkt. Velen andere partijen konden gewoon zelf class libraries schrijven voor Java en deden dit ook.

Ook vind ik het vreemd dat UIInput UIOutput extend. Op zich wel een beetje logisch als je kijkt naar functionaliteit, maar "gevoelsmatig" heb ik dan gelijk het idee dat het niet klopt.

Zoals al gezegd, UIInputOutput oid zou misschien raar klinken. Bij een UIInput component is er ook sprake van een bi-directionele binding als je het koppelt aan een bean. De ingevoerde waarde wordt ook weergegeven.

Er zijn wel meer namen waarbij dit speelt. Neem b.v. "renderer". Deze rendert niet alleen maar converteert ook de binnenkomende input. Ook bij een renderer speelt dus het input / output verhaal. De JSF designers waren zich hier overigens wel degelijk van bewust. In het boek "JavaServer Faces, the complete reference" staan een aantal design problemen waar men tegen aanliep en waarom men soms koos voor een naam die eigenlijk net niet helemaal de lading dekt. Het boek noemt b.v. ClientAdapter als alternatief voorgestelde naam voor renderer, die men uiteindelijk liet vallen omdat het toch te raar zou klinken.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

dinsdag 15 januari 2008 09:33

JKVA schreef op maandag 14 januari 2008 @ 07:31:
[...]
Ik denk dat ie meer doelt op rare designkeuzes in het framework (zoals alles stateful, lifecycle, componentenmodel, renderkits...).

Ik snap niet helemaal waarom de dingen die je noemt rare designkeuzes zijn. Alles -hoeft- helemaal niet stateful te zijn. Maar in veel gevallen wil je wel gewoon state, omdat er simpelweg sprake is van state in je applicatie.

Om nogmaals het java Class model erbij te pakken. Je -kunt- classes stateful maken (gebruik maken van instance data). Dat -hoeft- echter niet. Het zou wel vreemd zijn om een gehele Java applicatie te bouwen met alleen maar (statische) methods. Dan heb je een soort C applicatie, waar classes slechts als veredelde namespace gelden. Het is absoluut mogelijk om zo te programmeren (getuige de vele C code in de wereld), maar het is niet noodzakelijkerwijs de beste methode. Op z'n minst kun je stellen dat het niet 'raar' is om instance data te gebruiken.

De lifecycle vind ik eigenlijk ook al niet echt een rare designkeuze. Hij zit zelfs redelijk elegant in elkaar; een vaste serie gebeurtenissen die een aantal zaken afhandelen. Zeer veel andere platformen kennen ook een lifecycle, al dan niet goed gedocumenteerd. Kennis van de lifecycle is niet altijd nodig, maar dikwijls wel zeer handig. Dat is ook zo bij andere platformen. Neem zoiets als de clientside HTML parsing, dom building, event firing. Moet dit alles maar compleet arbitrair gebeuren? Een gedeelte invoke application tijdens de restore view (component tree building)? Niet echt handig als je tree walks wilt doen, maar een gedeelte van je tree is er nog helemaal niet.

Componentmodel is helemaal raar om als rare designkeuze te noemen. Bedoel je nu het feit dat er een componentmodel is? Is het hebben van een component model een rare designkeuze?

JSF is nog zeker geen perfect platform. Veel van de huidige pijnpunten worden (hopelijk) in JSF 2.0 een stuk verzacht. Zo is de one-url-behind problematiek erg vervelend. De workaround met de redirect is dikwijls niet de oplossing. Ook is het ontbreken van een echte conversation scope lastig. Daarnaast is het 'always post' model ook niet altijd wat je wilt (hoewel je aan dit laatste niet echt vastzit; je kunt zeker wel via GET werken in JSF, maar dat is meer handwerk dan je zou willen).

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

woensdag 16 januari 2008 01:00

Design-by-buzzword fanatic

flowerp schreef op maandag 14 januari 2008 @ 22:07:
[...]

Ik snap niet helemaal waarom de dingen die je noemt rare designkeuzes zijn. Alles -hoeft- helemaal niet stateful te zijn. Maar in veel gevallen wil je wel gewoon state, omdat er simpelweg sprake is van state in je applicatie.

Om nogmaals het java Class model erbij te pakken. Je -kunt- classes stateful maken (gebruik maken van instance data). Dat -hoeft- echter niet. Het zou wel vreemd zijn om een gehele Java applicatie te bouwen met alleen maar (statische) methods. Dan heb je een soort C applicatie, waar classes slechts als veredelde namespace gelden. Het is absoluut mogelijk om zo te programmeren (getuige de vele C code in de wereld), maar het is niet noodzakelijkerwijs de beste methode. Op z'n minst kun je stellen dat het niet 'raar' is om instance data te gebruiken.

De lifecycle vind ik eigenlijk ook al niet echt een rare designkeuze. Hij zit zelfs redelijk elegant in elkaar; een vaste serie gebeurtenissen die een aantal zaken afhandelen. Zeer veel andere platformen kennen ook een lifecycle, al dan niet goed gedocumenteerd. Kennis van de lifecycle is niet altijd nodig, maar dikwijls wel zeer handig. Dat is ook zo bij andere platformen. Neem zoiets als de clientside HTML parsing, dom building, event firing. Moet dit alles maar compleet arbitrair gebeuren? Een gedeelte invoke application tijdens de restore view (component tree building)? Niet echt handig als je tree walks wilt doen, maar een gedeelte van je tree is er nog helemaal niet.

Componentmodel is helemaal raar om als rare designkeuze te noemen. Bedoel je nu het feit dat er een componentmodel is? Is het hebben van een component model een rare designkeuze?

JSF is nog zeker geen perfect platform. Veel van de huidige pijnpunten worden (hopelijk) in JSF 2.0 een stuk verzacht. Zo is de one-url-behind problematiek erg vervelend. De workaround met de redirect is dikwijls niet de oplossing. Ook is het ontbreken van een echte conversation scope lastig. Daarnaast is het 'always post' model ook niet altijd wat je wilt (hoewel je aan dit laatste niet echt vastzit; je kunt zeker wel via GET werken in JSF, maar dat is meer handwerk dan je zou willen).

Eigenlijk zeg je hier in wat genuanceerdere woorden precies wat ik bedoel.

Met componentenmodel bedoel ik vooral dat het overdreven complex is. Het is niet voor niets dat alternatieven zoals Facelets of de Ajax4jsf CDK zo populair zijn. Dat komt omdat de API van JSF op dit gebied niet gemakkelijk is.

De JSF EG heeft dit zelf ook onderkend. Zie JSF 2.0, waar het grootste kernpunt "ease of development" is.

De lifecycle zit idd ook prima in elkaar... als je hem eenmaal kent. Als ik kijk bij beginnende JSF-ers, dan zie ik dat de lifecycle toch redelijk abstract in elkaar zit.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

woensdag 16 januari 2008 13:20

JKVA schreef op dinsdag 15 januari 2008 @ 09:33:
Eigenlijk zeg je hier in wat genuanceerdere woorden precies wat ik bedoel.

Met componentenmodel bedoel ik vooral dat het overdreven complex is. Het is niet voor niets dat alternatieven zoals Facelets of de Ajax4jsf CDK zo populair zijn. Dat komt omdat de API van JSF op dit gebied niet gemakkelijk is.

Uhm... Facelets is niet een alternatief voor het component model noch veranderd het iets aan dat component model zelf. Facelets is een view description technology waarin gewoon is voorzien door de designers van JSF. Het hele bestaan van Facelets is NIET zoals tegenstanders graag beweren een bewijs dat JSF 'raar' is of 'overdreven complex' en dat de opensource community te hulp is geschoten door een light-weight, non-bloated en sane alternatief te ontwikkelen.

Verre van dat...

Het feit dat iets als Facelets kan bestaan is JUIST een teken van de uitgekiendheid van JSF. 1 van de extention points in JSF is namelijk het feit dat de view description technology volledig pluggable is. In het design van JSF heeft men heel nauwkeurig er op toe gezien dat er geen JSP dependencies zijn. JSP is welliswaar de default view description, maar absoluut niet vereist voor een JSF applicatie.

De designers van Java wilden zich absoluut niet vastleggen op een enkele view description technology. JSP is genomen als de default omdat dat simpelweg direct voor handen was en bekend bij de meeste Java developers. Er zijn nog veel meer mogelijkheden denkbaar. Zo kun je ook je components gewoon in puur Java aan elkaar knopen. De taghandlers van JSP (en de corresponderende entries in de .tld file) zijn eigenlijk niets meer dan -een- interface voor de components, en die kun je ook gewoon volledig via plain Java benaderen. Daarnaast is de deur ook duidelijk opengezet voor een hele reeks andere alternatieven, zoals XUL of XForms.

Ik snap dat sommige mensen JSF zien als JSP, h:outputText, h:dataTable, etc. Maar dat is niet correct. JSF zelf is vrij elegant 'core' framework. Het echt helemaal standalone leveren zou iets te abstract zijn, vandaar dat er zeg maar voorbeelden bij zitten om er concreet iets mee te doen: JSP als vdt en de h: en f: components als basic setje components.

Net zoals b.v. Spring in het begin moeilijk voor mensen is om te doorgronden: "wat -is- het nu eigenlijk, wat doet het nu feitelijk", zo kan JSF dat ook zijn. De beauty van het geheel wordt pas duidelijk nadat de extenties en component libs waar zo nadrukkelijk op voor is bereid ook daadwerkelijk gemaakt worden. Feitelijk is JSF ook nog steeds jong. Pas sinds 2006 zit het officieel in Java EE. Het hele ecosysteem er op en er om heen begint nu pas op gang te komen.

De JSF EG heeft dit zelf ook onderkend. Zie JSF 2.0, waar het grootste kernpunt "ease of development" is.

En dat is toch ook alleen maar logisch? Voor het basis, core design van JSF heeft men gewoon heel veel werk moeten verzetten. Aangezien men bij Sun niet oneindig veel resources heeft, heeft men gewoon keuzes moeten maken. Eerst een solide core opbouwen en daarna stap voor stap, met feedback uit de community, de luxere features specificeren. Gebeurd dat niet met feitelijk elk stukje software?

De lifecycle zit idd ook prima in elkaar... als je hem eenmaal kent. Als ik kijk bij beginnende JSF-ers, dan zie ik dat de lifecycle toch redelijk abstract in elkaar zit.

Gelukkig is beginner zijn iets wat zich vanzelf oplost. Iedereen begint ooit, maar per definitie is elke beginner na verloop van tijd geen beginner meer.

Zoals eerder gezegd, met HTML/DOM/Javascript is er toch ook sprake van een lifecycle? Toch gebruikt iedereen wel HTML en Javascript zonder precies te weten hoe deze lifecycle werkt. Bij JSF hoef je ook zeker niet in het begin op de hoogte te zijn ervan. Je kunt heel veel dingen gewoon doen.

Daarnaast volgt de lifecycle eigenlijk ongeveer het geen wat je 'vroeger' handmatig deed als je MVC via Servlets en JSPs implementeerde. Je krijgt een request binnen in een Servlet, daar haal je ruwe values uit, deze converteer en valideer je, als dat lukt roep je business logic aan met de typed values, het resultaat hiervan stop je in je request scope waarna je forward naar een JSP die de boel rendert.

Dat is precies hoe ik het een flinke tijd heb gedaan met plain J2EE, voordat JSF er was. Het probleem hierbij was dat de goede programmeurs zich exact aan deze volgorde hielden, maar de wat slordigere programmeurs nogal vaak de boel niet netjes konden scheiden. Die deden dan wat validatie, daarna wat business logic. Daarna weer wat validatie gevolgd door wat business logic etc. Ging natuurlijk dikwijls fout als er bij de 2de validatie iets niet bleek te kloppen, maar er al wel business logic uitgevoerd was.

De JSF lifecycle biedt nu juist een handvat voor precies deze fases. Hierdoor wordt het door elkaar heen laten lopen van de diverse taken veel minder aantrekkelijk (het kan nog wel als je dat wil).

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

woensdag 16 januari 2008 13:57

Design-by-buzzword fanatic

Om een lang antwoord kort te maken, ik heb niets tegen JSF, maar tegen de API van JSF.

Het feit dat Facelets mogelijk is vind ik prima. Maar het feit dat Facelets populair is, is omdat het zonder Facelets veel te moelijk is om met JSF te werken. Zo is een component bouwen veel te moeilijk (UIComponent, UIComponentTag, tld, faces-config, Renderer, en dan nog je echte code).

Ook wordt standaard JSP meegeleverd als ViewHandler, maar is deze buggy (content-interleaving problemen).

Ten slotte werkt de lifecycle prima, maar is niet gemakkelijk te doorgronden.

Ik zie hier een patroon in (EJB 2.1 --> EJB 3.0). Ze maken eerst een ruwe opzet publiekelijk beschikbaar waar ze zelf niet achter staan (zie blogposts van o.a. Jacob Hookom ergens in 2004 ofzo) en daarna gaan ze onder druk van de community de boel vereenvoudigen.

Naar mijn idee maakt een goed framework de veelvoorkomende zaken gemakkelijk en blijven de minder vaak voorkomende zaken fatsoenlijk mogelijk. JSF doet dit naar mijn idee niet.

Fat Pizza's pizza, they are big and they are cheezy

Acties: