JavaServer Faces (JSF) er Java-standardteknologien til opbygning af komponentbaserede, begivenhedsorienterede webgrænseflader. Ligesom JavaServer Pages (JSP) giver JSF adgang til serversides data og logik. I modsætning til JSP, som i det væsentlige er en HTML-side gennemsyret af serversidesfunktioner, er JSF et XML-dokument, der repræsenterer formelle komponenter i et logisk træ. JSF-komponenter understøttes af Java-objekter, som er uafhængige af HTML og har hele spektret af Java-evner, herunder adgang til eksterne API'er og databaser.
Hovedideen til en ramme som JSF er at indkapsle (eller indpakning) klientside-teknologier som HTML, CSS og JavaScript, der giver udviklere mulighed for at opbygge webgrænseflader uden meget interaktion med disse teknologier.
Denne artikel præsenterer et øjebliksbillede af JSFs tilgang til komponentbaseret UI-udvikling til Java-webapplikationer. Enkle eksempler introducerer JSFs MVC-arkitektur, begivenhedsmodel og komponentbibliotek. Eksempler inkluderer nye funktioner i JSF 2.3, og vi bruger PrimeFaces til vores komponentbibliotek.
Udvikler JSF
Længe populært har JSF for nylig været udsat for konkurrence fra Java-kompatible webrammer, inklusive JavaScript-rammer på klientsiden. Stadig forbliver JavaServer Faces Java-standarden, især til Java-virksomhedsudvikling i stor skala. JSF-specifikationen har også skabt et væld af rammer og biblioteker, der har holdt trit med de seneste forbedringer på klientsiden. En af disse er PrimeFaces, som vi udforsker i denne vejledning.
Mens tidsplanen for fremtidig udvikling er uklar, giver JSF 2.3 udviklere masser at arbejde med, mens vi venter. Udgivet i marts 2017 blev JSF 2.3 bevidst designet til at modernisere JSF. Blandt flere hundrede små reparationer og større opdateringer fratager JSF 2.3 administrerede bønneroteringer til fordel for CDI, som jeg introducerer senere i denne vejledning.
JSF 2.3 i Jakarta EE
I september 2017 annoncerede Oracle sin hensigt om at overføre Java EE til Eclipse Foundation. Java EE er siden blevet omdøbt til Jakarta EE, og JSF 2.3 (Eclipse Mojarra) er blevet vedtaget til fortsættelse. Den næste store frigivelse af JSF-specifikationen vil være Eclipse Mojarra 3.0.
Bygning af komponentbaserede webgrænseflader i JSF
JSFs kerneidee er at indkapsle funktionalitet i genanvendelige komponenter. Dette svarer til de genanvendelige tags, der bruges i JSP, men JSF-komponenter er mere formelle.
Mens du kan bruge JSF-sider inden for JavaServer-sider, er det mere almindeligt at bruge Facelets til at oprette selvstændige JSF-sider. Facetter er XHTML-sider designet til at definere JSF-grænseflader. Med Facelets bruger du XML-tags til at oprette et komponenttræ, der bliver stilladset til en JSF-brugergrænseflade.
Liste 1 viser hoveddelene af en simpel JSF-side skrevet med Facelets. I dette eksempel får vi adgang til Java's serverfunktioner via en bønne, der er placeret i omfanget via CDI. Du kan se mere om CDI senere.
Notering 1. Eksempel på JSF
Hej JavaWorld! # {javaBean.content} I liste 1 ser vi en standard XHTML-side. En facelets-oversigt er bygget oven på XHTML. Ud over XHTML-navneområdet defineres og refereres der til et sekundært navneområde.
Det h biblioteket indeholder standardkomponenter til brug på JSF HTML-sider. Det //xmlns.jcp.org/jsf/html bibliotek definerer en samling af JSF-komponenter, i dette tilfælde en samling af almindelige HTML-elementer. En af disse komponenter er element.
HTML-komponenter i JSF
Med hensyn til syntaks, Listing 1's element henviser til jsf / html bibliotek med h præfiks. Derefter henviser den til den specifikke komponent i biblioteket, som er hoved komponent.
Det komponent udsender HTML-hovedelementet. (Alt denne syntaks kan virke som overkill til et så simpelt formål, men der er god grund til det, som du snart vil se.)
Indlejrende komponenter
Inde i hovedet er der indlejret en standard HTML element. Dette element leveres til komponent sammen med indholdet underordnede elementer indlejret inde i den.
I kropsdokumentet er et JSF-udtryk indeholdt af #{} syntaks. Dette er nøjagtigt analogt med et JSP-udtryk med ${} format: det giver adgang til Java-objekter i omfang og enkle funktioner.
Det grundlæggende mønster for JSF er simpelt: Brug Facelets til at opbygge et XML-træ, der refererer til et komponentbibliotek eller biblioteker, og brug derefter komponenter i biblioteket til at gengive Java-objekter som HTML.
Brug af Java-objekter i JSF
Gå tilbage til liste 1 og bemærk, at inde i JSF-udtrykket ($ {javaBean.content) Det javaBean objektet er i omfang, når denne markering udføres. XHTML of Facelets har adgang til .indhold ejendom på javaBean objekt. Det endelige output er en webgrænseflade, der fletter facelets-visningsstrukturen med Java's server- og data- og logikfunktioner.
Brug af et JSF-udtryk er kun en måde at få adgang til Java-applikationsdata fra en JSF-brugergrænseflade. Til sidst vil du gerne udforske andre måder, en JSF-komponent kan interagere med Java-backend - ting som datalister og gitre og en række inputkontroller. For nu er det nok til at absorbere, hvordan JSF bruger XML-tags (eller annoteringer) til at oprette et træ af komponenter, der udlæser HTML baseret på dataene i Java-objekter.
Kommentarer vs XML
Med JSF 2.3 er det blevet muligt at definere JSF-komponenter med kommentarer, der helt undgår XML-metadata. Det er fuldt muligt at definere og implementere en JSF-app uden at redigere XML.
Struktur af en JSF-applikation
Ligesom JavaServer Pages og Servlet API kræver JavaServer Faces en standard katalogstruktur og metadata. Disse indsættes som .krig filer.
Strukturen i en .war-fil ligner et Servlet- eller JSP-program. Den indeholder en / web-app bibliotek, der indeholder applikationens markeringsfiler (i dette tilfælde HTML, JSP og Facelets) samt en / WEB-INF katalog, der præsenterer metadataene til beskrivelse af applikationen.
Serverer JSF
Mens du kan køre JSF i en Java EE-container som Glassfish, er en simpel servlet-container alt hvad du virkelig har brug for. Tomcat er en populær container til JSF og andre Java-teknologier på serversiden.
JSF 2.3: Specifikationer og implementeringer
En af Java's styrker er, at det er standardbaseret, og at disse standarder styres af en open source-fællesskabsproces. Siden starten har Java Community Process (JCP) overvåget udviklingen af Java-teknologi. Når en specifikation eller specifikationsforbedring er udviklet og godkendt af JCP, er den tilgængelig til implementering af flere parter. Indtil for nylig blev Servlets, JSP og JSF alle udviklet ved hjælp af JCPs open source-specifikationsproces.
Den seneste JSF-specifikation i skrivende stund er JSF 2.3, udgivet som en del af Java EE 8 i 2017. Oracle's (nu Eclipse's) Mojarra er JSF-referenceimplementeringen, og MyFaces og PrimeFaces er populære tredjepartsimplementeringer.
Hver af disse rammer implementerer JSF-kernen, som inkluderer nogle standardkomponenter. Leverandører kan også tilbyde yderligere komponentbiblioteker oven på standarden. Når du vurderer JSF-rammer, er det en god ide at overveje behovene i din applikation, og hvilke komponentbiblioteker der er tilgængelige for at hjælpe dig med at opbygge den. Ideelt set skal din JSF-ramme få dig så tæt som muligt på det, du har brug for, lige ud af kassen.
MVC i JSF 2.3
JSF er en MVC-ramme, implementering af model-view-controller-mønster. I MVC-mønsteret er ideen at adskille de tre bekymringer for et brugergrænseflade i diskrete dele, så de er lettere at administrere. Generelt er det udsigt er ansvarlig for at vise data i modellen og controller er ansvarlig for at opsætte modellen og dirigere brugeren til den korrekte visning.
I en JSF-implementering er visningen siden Facelets med sit sæt XML-tags. Disse definerer layoutet på brugergrænsefladen. Den anden halvdel af at bruge JSF er serversiden, hvor Java klasser disse UI-komponenter tilbage.
Administrerede bønner udfaset i JSF 2.3
Administrerede bønneannoteringer er udfaset i JSF 2.3 og erstattet af CDI (Contexts and Dependency Injection). Med CDI definerer udviklere en kontekst og injicerer objekter til denne kontekst. De, der er fortrolige med forvaltede bønner, finder annotationssyntaxen lidt anderledes, men semantikken forbliver nøjagtig den samme.
Controller bønner
I JSF 2.3 leverer controller bønner den controller del af MVC-ligningen. Normale Java-objekter (ofte kaldet POJO'er eller almindelige gamle Java-objekter) giver modellen.
Med hensyn til procesflow, controller bønner:
- Beslut, hvor brugeranmodninger skal rettes
- Opsæt POJO'er til modellen
- Brug modellen til at gengive facelets-visningen
JSF folder derefter komponenttræet og modellen sammen for at gengive output-HTML.
Liste 2 viser, hvordan du vil definere javaBean objekt fra liste 1 ved hjælp af CDI. Denne liste antager, at applikationen har cdi-api-1.2.jar i sine afhængigheder.
Liste 2. En JavaBean defineret ved hjælp af CDI
import javax.inject.Named; import javax.enterprise.context.SessionScoped; @Named @ViewScoped offentlig klasse JavaBean implementerer Serialiserbar {privat strengindhold = ìVelkommen til JSF! Î // getters / setters} JSF 2.3 med PrimeFaces
I de næste sektioner bruger jeg PrimeFaces til at vise dig, hvordan JSF implementerer MVC-mønsteret, begivenhedsdrevet meddelelse og genanvendelige komponenter. For at starte skal du åbne PrimeFaces Showcase og klikke på Data link i kolonnen til venstre, og vælg Dataliste. Dette trækker DataList-demo-koden til PrimeFaces op.
Figur 1 viser dig, hvor du finder disse prøver.
Matthew Tyson Figur 2 viser output fra en simpel datatabel, som er taget fra PrimeFaces DataList demo.
Matthew Tyson PrimeFaces DataList: Adgang til datamodellen
Listing 3 præsenterer markeringen for dette dataliste Skærm. Hvis du ruller til bunden af PrimeFaces-udstillingsvinduet, kan du se markeringen i dataList.xhtml fanen.
Notering 3. Facelet til PrimeFaces DataList
Grundlæggende nr. {Car.brand}, # {car.year} I Listing 3 skal du bemærke værdi ejendommen til dataliste komponent. Du kan se, at dette refererer til a dataListView objekt og får adgang til .biler1 ejendom på det. Komponenten skal bruge modelobjektet, der returneres af dette felt. JSF-tokens bruger konventionelle accessorer til at referere til objektegenskaber, så .biler1 vil henvise til getCars () getter på objektet.
Bemærk derefter var = "bil" ejendom. Dette fortæller dataliste komponent hvilken variabel, der skal bruges, når den gentager sig over listen over biler, der returneres af værdi Mark. Disse egenskaber er specifikke for dataliste komponent, men værdi ejendom er meget almindelig. Det var attribut er også konventionel for komponenter, der gentages over lister.
I selve komponenten i liste 3 kan du se bil variabel tilgås via JSF-udtryk som # {bil.brand}. Hver iteration af dataListView.cars1 eksempel vil output bil.mærke Mark.
Bemærk, at tag viser evnen til at tilpasse komponenter til, hvordan de vises. I dette tilfælde er overskriften defineret som Grundlæggende.
Du kan se, hvordan Facelets XML vil drive denne output ved at kombinere dataene med markeringen. Lad os nu se på Java-koden bag den.
DataLists serverkomponenter
Liste 4 viser DataListView, Java-klassen, der bruges af markeringen i Listing 3. Du vil snart se, hvordan dataListView forekomst er forbundet med DataListView klasse.
Fortegnelse 4. DataListView-klasse
pakke org.primefaces.showcase.view.data; import java.io.Serializable; importere java.util.List; import javax.annotation.PostConstruct; import javax.inject.Named; // Pre JSF 2.3, dette var: // import javax.faces.bean.ManagedBean; import javax.inject.Inject; import javax.faces.bean.ViewScoped; import org.primefaces.showcase.domæne.Bil; import org.primefaces.showcase.service.CarService; @Named @ViewScoped offentlig klasse DataListView implementerer Serialiserbar {privat liste biler1; privat bil valgtBil; @Inject ("# {carService}") privat CarService-service; @PostConstruct offentlig ugyldig init () {cars1 = service.createCars (10); } offentlig liste getCars1 () {returbiler1; } offentlig ugyldighed setService (CarService-tjeneste) {this.service = service; }} Listing 4 har et par andre vigtige elementer, som vi betragter stykke for stykke.
Afhængighedsindsprøjtning og -kommentarer
Bemærk først, at DataListView klasse er kommenteret med @Som hedder, som du kan se fra importen import javax.inject.Named; er en del af JSF. Det @Som hedder kommentar fortæller JSF, at denne bønne er en del af appen. Det @ViewScoped annotation oplyser JSF om, at bønnen vil leve bare udsigten.
Dernæst skal du observere, at CarService ejendom har @Indsprøjte kommentar (kaldet @ManagedProperty før JSF 2.3). Dette er en anden JSF-funktion, der tillader, at bønner "kobles sammen", en teknik, der er populært af Spring-rammen og andre værktøjer til indsprøjtning af afhængighed. I det væsentlige vil JSF finde bilservice objekt i omfang og knytte det automatisk til service felt på DataListView objekt.
