JSF Lifecycle

1. JSF Lifecycle

2. JSF-livscyklus • JSF-livscyklus • De 4 request-response scenarier • De 6 faser i livscyklusen • PhaseListeners

3. JSF-livscyklus • JSF benytter sig af en veldefineret procedure – en såkaldt livscyklus – til at analysere et request, bearbejde sine komponenter og den underliggende model, og sende et response tilbage. • Livscyklen består af seks veldefinerede delprocesser. • Hver gang en bruger sender et request til en webapplikation, som benytter sig af JSF, vil der være mulighed for at en eller flere af disse delprocesser vil blive afviklet. • Vi som programmører har dog via JSF-API’et en vis indflydelse på hvilke trin der afvikles – hvis vi ønsker det.

4. Faserne i JSF-livscyklus responsecomplete responsecomplete Facesrequest RestoreView Apply Request Values ProcessEvents ProcessValidation ProcessEvents Non-facesrequest RenderResponse ProcessEvents InvokeApplication ProcessEvents UpdateModelValues Facesresponse responsecomplete responsecomplete

5. JSF-livscyklus • JSF-livscyklus • De 4 request-response scenarier • De 6 faser i livscyklusen • PhaseListeners

6. 4 Scenarier • Non-Faces Request  Non-Faces Response • Non-Faces Request  Faces Response • Faces Request  Non-Faces Response • Faces Request  Faces Response

7. Non-Faces Request  Non-Faces Response • Et kald, som ikke involverer JSF-frameworket på nogen måde. • Er ikke relevant i denne sammenhæng – og vi springer derfor lystigt videre.

8. Non-Faces Request  Faces Response • Et kald som foretages fra en ressource udenfor JSF ind på en side i JSF-frameworket. • Også kaldet Initial request. • Fasen Restore View bliver udført, og sidens komponenttræ bliver opbygget. Da der ikke er sket nogle ændringer i henhold til et tidligere komponenttræ (da dette slet ikke eksisterede), bliver fasen Render Response afviklet direkte herefter og klienten modtager et response. RestoreView Non-facesrequest RenderResponse Facesresponse

9. Faces Request  Non-Faces Response • Et kald som foretages fra en JSF-ressource, men som returnerer et response udenfor JSF-frameworket • Eksempelvis et forward til en ekstern applikation, et særligt response med en PDF eller lign. • Når som helst i de forskellige faser af JSF-livscyklen kan en ressource (komponent, event handler, validator etc.) kalde metoden responseComplete() på FacesContext-objektet. Dette indikerer overfor JSF, at der allerede er blevetsendt et response til klienten, ogframeworket annullerer herved alvidere afvikling i livscyklen. onResponseComplete() responsecomplete ProcessEvents ... ...

10. Faces Request  Faces Response • Et kald fra en side i JSF-frameworket til en anden, eller et postback til samme side. • Denne situation afføder (som udgangspunkt), at hele livscyklen bliver gennemgået.

11. JSF-livscyklus • JSF-livscyklus • De 4 request-response scenarier • De 6 faser i livscyklusen • PhaseListeners

12. Restore View • Et view repræsenterer samtlige komponenter på en side (bundet i et komponenttræ). Det repræsenteres med et objekt af typen UIViewRoot som bindes til den aktive FacesContext. • Det kan enten være gemt på klienten (i et hidden field) eller på serveren (som default). Serveren gemmer viewet i session scope, men kan vælge at serialisere det til disk i tilfælde af hukommelsesmangel eller hvis brugeren ikke har tilgået siden i lang tid. • I fasen Restore View prøver JSF at finde et view for den kaldende side. Hvis det ikke findes ( = brugeren har ikke været inde på siden før), oprettes et nyt view. • Sammen med UI-komponenterne hentes også deres respektive værdier, event listeners, validators og converters. • I denne fase sættes også sprogindstillingerne for view’et. • I tilfælde af et initial view (første gang brugeren går ind på siden) har det oprettede view ingen tilstand, og JSF springer direkte til fasen Render Response. • I tilfælde af et postback (brugeren kommer tilbage til en side) vil der allerede være oprettet et view. JSF benytter det eksisterende views tilstandsoplysninger til at genoprette dets tilstand, og går til fasen Apply Request Values.

13. Apply Request Values • I denne fase beder JSF view’et om at decode det modtagne HTTP-request – altså at hive parameterværdier ud fra HTTP-requestet og overføre dem til UI-komponenterne i træet (IKKE managed beans). • View’et kalder da metoden decode() på sine komponenter. Disse kalder tilsvarende decode() på deres subkomponenter, og så fremdeles. • Den enkelte komponent finder da sit tilsvarende element i requestet ved at sammenligne ID-værdierne, og lægger dennes nye værdi ind i sin tilstand (vha. metoden setSubmittedValue()). • Undervejs konverteres værdien vha. komponentens tilknyttede Converters getAsObject()-metode. Hvis der opstår en fejl under konvertering, springer JSF direkte til Render Response-fasen, og brugeren får besked om at der er sket en fejl. • Validering af input-værdier sker normalt i næste fase (Process Validation). Hvis en input control imidlertid har sat sin property immediate til true, vil denne blive valideret allerede i denne fase. Tilsvarende har controls der definerer knapper og hyperlinks (action sources) også en immediate-property; hvis denne er sat til true, vil disses action events bliver afviklet i denne fase også – i modsætning til Invoke Application-fasen, hvor de normalt køres. Baggrunden for denne funktionalitet er, at det kunne tænkes at man ville kontrollere en enkelt værdis tilstand, og evt. i tilfælde af fejl returnere til siden, inden man fandt det nødvendigt at gå i gang med at kontrollere hele resten af komponenttræet.

14. Process Validations • I denne fase foretages validering af komponenternes nye data. • Igen vil JSF lade view’et bede sine komponenter om at validere sig, og disse vil igen bede sine subkomponenter om at validere sig og så fremdeles. Dette sker med metoden processValidators(). • Den enkelte komponent vil da kalde metoden validate(), som enten benytter intern logik til at validere komponenten med – eller bruger evt. registrerede Validators til formålet. • Hvis en validering fejler, vil JSF gemme fejlbeskeden og gå direkte til fasen Render Response, hvor brugeren vil blive præsenteret for den gamle side, evt. sammen med fejlbeskeden. • Hvis valideringen passerer vil komponentens property valid blive sat til true.

15. Update Model Values • I denne fase opdateres Managed Beans med information fra komponenttræet. • Beans som vha. EL er knyttet til komponenter vil i denne fase automatisk blive opdateret til at afspejle komponenternes værdier. • På dette tidspunkt forventes data i komponenttræet at være konverteret og valideret og derfor i ”korrekt” tilstand. • Metoden processUpdates() køres fra view’et på komponenterne, og herfra på deres subkomponenter, osv.

16. Invoke Application • I denne fase processeres ActionEvents – dvs. logik køres som følge af et tryk på en ActionSource (knapper og links). Dette gælder både den action, som er defineret som modtager på sidens form-element, og eventuelle ActionListeners. • Hvis en ActionSource control har haft sat sin immediate-property til true, så vil denne i stedet være afviklet allerede under Apply Request Values. • Denne fase vil typisk styre hvilken side brugeren skal dirigeres hen til. Dette gøres ved at sammenligne resultatet af action-metoderne med navigation rules i JSF-konfigurationen (typisk faces-config.xml). • Metoden til dette skridt af livscyklen hedder processApplication() og kaldes som de andre tilsvarende metoder på UIViewRoot-objektet.

17. Render Response • I denne fase beder JSF web-containeren om at skabe et nyt response baseret på den side, som Invoke Application-fasen dirigerede hen til. • Komponenterne på siden opdateres fra modellen og bliver renderet på siden baseret på deres respektive Renderers. • Hvis der er sket en fejl under f.eks. konvertering eller validering, vil den oprindelige side blive hentet, og evt. messages med informationer om fejl vil blive stillet til rådighed for <message> / <messages>-tags. • JSF-specifikationen kræver at leverandøren stiller en default view handler til rådighed. Denne er ansvarlig for at generere et response samt at opbygge et view – altså hvad der svarer til faserne Restore View og Render Response. Man kan dog vælge at levere sin egen view handler, hvis man f.eks. ikke ønsker at basere sin JSF-applikation på JSP.

18. Life cycle event handling • I hver af de fire midterste faser i livscyklen (Apply Request Values, Process Validation, Update Model Values og Invoke Application) kan komponenter vælge at affyre en eller flere events. • Disse events (af typen FacesEvent) lægges i kø på komponenten med metoden queueEvent(). Efter hver fase vil JSF kalde metoden broadcast() på komponenten for hver event. Dette kald sørger for at evt. lyttere på komponenten bliver gjort opmærksomme på denne event. Lyttere bliver notificeret i den rækkefølge de har registreret sig på komponenten.

19. Render Response/Response Complete • En komponent el.lign. kan på et hvilket som helst tidspunkt i løbet af de fem første faser kalde metoden renderResponse() på den aktive FacesContext. Dette resulterer i at frameworket går direkte til fasen Render Response. • FacesContext har (som før nævnt) også en metode til rådighed, som hedder responseComplete(). Denne terminerer JSF-livscyklen fuldstændig,da frameworket da forventer,at et response allerede erblevet sendt til klientenudenom JSF. ProcessEvents ... ... RenderResponse renderResponse()

20. JSF-livscyklus • JSF-livscyklus • De 4 request-response scenarier • De 6 faser i livscyklusen • PhaseListeners

21. Hvad er PhaseListeners? • PhaseListeners gør det muligt at eksekvere kode i løbet af JSF-livscyklus • PhaseListeners eksekveres enten lige før eller lige efter en fase.

22. Invokering af PhaseListeners beforePhase(...) beforePhase(...) beforePhase(...) afterPhase(...) afterPhase(...) afterPhase(...) Facesrequest RestoreView Apply Request Values ProcessEvents ProcessValidation ProcessEvents Non-facesrequest afterPhase(...) beforePhase(...) beforePhase(...) beforePhase(...) afterPhase(...) afterPhase(...) RenderResponse ProcessEvents InvokeApplication ProcessEvents UpdateModelValues Facesresponse

23. PhaseListeners – til hvad? • Session time out listener: redirect til default side • Support af Get request og bookmarks (i JSF 1.x) • Lifecycle debug log • Håndtere Ajax Request. Se JavaServer Faces – The Complete Reference og http://cagataycivici.wordpress.com/2006/02/10/jsf_phaselisteners_underestimated_from_day • Håndtere Image requests, så servlet ikke skal gøre det (se ovenstående link)

24. PhaseListener (1/3) • Klasser der ønsker at blive informeret om forløbet i livscyklen kan implementere interfacet javax.faces.event.PhaseListener. • Denne PhaseListener-klasse vil da modtage informationer om faseskift wrappet i PhaseEvents. Via PhaseEvent-objektet kan PhaseListeneren få adgang til FacesContext-klassen og dermed (via viewet) komponenttræet. • Dette interface har tre metoder: • void beforePhase(PhaseEvent): Kode der afvikles inden en fase i livscyklen begynder • void afterPhase(PhaseEvent): Kode der afvikles efter en fase i livscyklen afsluttes • PhaseId getPhaseId(): Returnerer den type PhaseId som lytteren er interesseret i at lytte på.

25. PhaseListener (2/3) • JSF bruger PhaseListenerens getPhaseId-metode til at vide, hvilke faser denne lytter på. • getPhaseId() returnerer et objekt af typen PhaseId. Der findes en række statiske objekter i PhaseId-klassen som repræsenterer de forskellige faser. • Hvis man f.eks. ønsker kun at lytte på Apply Request Values, implementerer man metoden som flg.: • Hvis man derimod vil lytte på samtlige faser, implementerer man metoden således: public PhaseId getPhaseId() { return PhaseId.APPLY_REQUEST_VALUES; } public PhaseId getPhaseId() { return PhaseId.ANY_PHASE; }

26. PhaseListener (3/3) • Når PhaseListeneren er skrevet, skal den registeres med JSF. • Dette gøres typisk i faces-config.xml: • PhaseListeners invokeres i konfigurerede orden. <faces-config> <lifecycle> <phase-listener>dk.lundogbendsen.MyListener</phase-listener> </lifecycle> ... </faces-config>

27. Eksempel Læg mærke til: • To eksempler på brug af PhaseListeners. • Debugging ifht. hvad der sker i hvilken fase. • Redirect af brugeren, hvis sessionen er timet ud. JSF-Ex-Lifecycle-Phases JSF-Ex-Lifecycle-SessionTimeOut

28. PhaseListener per side • I JSF 1.2 kan PhaseListener også registreres per side. • <f:view> • <f:phaseListener type=”dk.lundogbendsen.listeners.MyListener”/> • ... • </f:view> Eller ved managed beans... public class MyListenerBean { public void before(PhaseEvent pe) { System.out.println(”before: ”+ pe.getPhaseId()); } ... } <f:view beforeMethod=”#{listener.before}” afterMethod=”#{listener.after}” > ... </f:view> Husk konfiguration i faces-config.xml