JSP-maler

Selv om verktøy for nettutvikling utvikler seg raskt, ligger de fortsatt bak de fleste grafiske brukergrensesnitt (GUI) -verktøy som Swing eller VisualWorks Smalltalk. For eksempel gir tradisjonelle GUI-verktøysett layoutadministratorer, i en eller annen form, som tillater layoutalgoritmer å bli innkapslet og gjenbrukt. Denne artikkelen utforsker en malmekanisme for JavaServer Pages (JSP) som, i likhet med layoutadministratorer, innkapsler layout slik at det kan brukes på nytt i stedet for å replikeres.

Fordi layout gjennomgår mange endringer i løpet av utviklingen, er det viktig å kapsle inn funksjonaliteten slik at den kan modifiseres med minimal innvirkning på resten av applikasjonen. Faktisk demonstrerer layoutledere et eksempel på en av prinsippene for objektorientert design: innkapsle konseptet som varierer, som også er et grunnleggende tema for mange designmønstre.

JSP gir ikke direkte støtte for innkapsling av layout, så websider med identiske formater replikerer vanligvis layoutkode; for eksempel viser figur 1 en webside som inneholder seksjoner for topptekst, bunntekst, sidefelt og hovedinnhold.

Oppsettet til siden vist i figur 1 er implementert med HTML-tabellkoder:

Eksempel 1. Inkludert innhold

JSP-maler <%@include file="sidebar.html"%> <%@include file="header.html"%>
<%@include file="introduction.html"%>
<%@include file="footer.html"%>

I eksemplet som er oppført ovenfor, er innhold inkludert i JSP inkludere direktivet, som lar innholdet på siden variere - ved å endre de inkluderte filene - uten å endre selve siden. Men fordi layout er hardkodet, krever layoutendringer endringer på siden. Hvis et nettsted har flere sider med identiske formater, noe som er vanlig, krever selv enkle layoutendringer endringer på alle sidene.

For å minimere virkningen av layoutendringer, trenger vi en mekanisme for å inkludere layout i tillegg til innhold; på den måten kan både layout og innhold variere uten å endre filer som bruker dem. Den mekanismen er JSP-maler.

Bruke maler

Maler er JSP-filer som inkluderer parameterisert innhold. Malene som er diskutert i denne artikkelen er implementert med et sett med tilpassede koder: mal: få, mal: sette, og mal: sett inn. De mal: få tag får tilgang til parameterisert innhold, som illustrert i eksempel 2.a, som produserer websider med formatet vist i figur 1.

Eksempel 2.a. En mal

<mal: få navn = "tittel"/> <mal: få name = "header" />

Eksempel 2.a er nesten identisk med eksempel 1, bortsett fra at vi bruker mal: få i stedet for inkludere direktivet. La oss undersøke hvordan mal: få virker.

mal: få henter en Java-bønne med det angitte navnet fra forespørselens omfang. Bønnen inneholder URI (Uniform Resource Identifier) til en webkomponent som er inkludert i mal: få. For eksempel i malen oppført i eksempel 2.a, mal: få får en URI - header.html - fra en bønne som heter Overskrift i omfanget av forespørselen. I ettertid, mal: få inkluderer header.html.

mal: sette setter bønnene i forespørselsomfang som deretter blir hentet av mal: få. Malen følger med mal: sett inn. Eksempel 2.b illustrerer bruken av sette og sett inn tagger:

Eksempel 2.b. Ved hjelp av malen fra eksempel 2.a

<>sett inn mal = "/ articleTemplate.jsp"><>sette name = "title" content = "Maler" direct = "true" /><>sette name = "header" content = "/ header.html" /><>sette name = "sidebar" content = "/ sidebar.jsp" /><>sette navn = "innhold" innhold = "/ introduksjon.html" /><>sette navn = "bunntekst" content = "/ bunntekst.html" />

De sett inn start tag spesifiserer malen som skal inkluderes, i dette tilfellet malen oppført i eksempel 2.a. Hver sette tag lagrer en bønne i forespørselsomfang og sett inn slutt tag inneholder malen. Malen får deretter tilgang til bønnene som beskrevet ovenfor.

EN direkte attributt kan spesifiseres for mal: sette; hvis direkte er satt til ekte, innholdet som er tilknyttet taggen er ikke inkludert i mal: få, men blir skrevet ut direkte underforstått ute variabel. I eksempel 2.b brukes for eksempel tittelinnholdet - JSP-maler - til vinduetittelen.

Nettsteder som inneholder flere sider med identiske formater, har en mal, som den som er oppført i eksempel 2.a, og mange JSP-sider, som eksempel 2.b, som bruker malen. Hvis formatet endres, er endringene begrenset til malen.

En annen fordel med maler og inkludert innhold generelt er modulær design. For eksempel inkluderer JSP-filen som er oppført i eksempel 2.b til slutt header.html, oppført i eksempel 2.c.

Eksempel 2.c. header.html

Fordi header.html er inkludert innhold, trenger det ikke å replikeres blant sider som viser en overskrift. Også, selv om header.html er en HTML-fil, inneholder den ikke den vanlige innledningen til HTML-koder, for eksempel eller fordi disse kodene er definert av malen. Det vil si fordi malen inkluderer header.html, bør disse kodene ikke gjentas i header.html.

Merk: JSP gir to måter å inkludere innhold på: statisk, med inkludere direktivet, og dynamisk, med inkludere handling. De inkludere direktivet inkluderer kilden til målsiden ved kompileringstid og tilsvarer C #inkludere eller Java import. De inkludere handling inkluderer målets respons generert ved kjøretid.

Som JSP inkludere handling, inkluderer maler innhold dynamisk. Så selv om JSP-sidene i eksempel 1 og eksempel 2.b er funksjonelt identiske, inkluderer førstnevnte statisk innhold, mens sistnevnte inkluderer det dynamisk.

Valgfritt innhold

Alt malinnhold er valgfritt, noe som gjør en enkelt mal nyttig for flere websider. For eksempel viser figur 2.a og figur 2.b to sider - innlogging og beholdning - som bruker samme mal. Begge sidene har topptekst, bunntekst og hovedinnhold. Inventarsiden har et redigeringspanel (som innloggingssiden mangler) for å gjøre lagerendringer.

Nedenfor finner du malen som deles av påloggings- og beholdningssidene:

 ... 
name = 'editPanel'/>
 ...

Inventarsiden bruker malen oppført ovenfor og spesifiserer innhold for redigeringspanelet:

   ...  ...

På den annen side spesifiserer ikke påloggingssiden innhold for redigeringspanelet:

Fordi påloggingssiden ikke spesifiserer innhold for redigeringspanelet, er den ikke inkludert.

Rollebasert innhold

Nettapplikasjoner diskriminerer ofte innhold basert på brukerens rolle. For eksempel produserer den samme JSP-malen, som bare inkluderer redigeringspanelet når brukerens rolle er kurator, de to sidene vist i figur 3.a og 3.b.

Malen som brukes i figur 3.a og 3.b bruker mal: fås rolle Egenskap:

 ...  ...  ... role = 'kurator'/>
 ...

De få tag inneholder bare innhold hvis brukerens rolle samsvarer med rolle Egenskap. La oss se på hvordan taggbehandleren for mal: få bruker rolle Egenskap:

offentlig klasse GetTag utvider TagSupport {private strengnavn = null, rolle = null; ... public void setRole (String role) {this.role = role; } ... public int doStartTag () kaster JspException {... if (param! = null) {if (roleIsValid ()) { // inkluderer eller skriver ut innhold ... }} ...} privat boolsk roleIsValid ()  }

Implementering av maler

Malene som er diskutert i denne artikkelen er implementert med tre egendefinerte koder:

mal: sett inn
mal: sette
mal: få

De sett inn tag inneholder en mal, men før den gjør det, sette tagger lagrer informasjon - et navn, URI og boolsk verdi som angir om innhold skal inkluderes eller skrives ut direkte - om innholdet malen inneholder. mal: få, som inkluderer (eller skriver ut) det spesifiserte innholdet, får deretter tilgang til informasjonen.

mal: sette lagrer bønner i forespørsel, men ikke direkte fordi hvis to maler bruker de samme innholdsnavnene, kan en nestet mal overskrive innholdet til den vedlagte malen.

For å sikre at hver mal bare har tilgang til sin egen informasjon, mal: sett inn opprettholder en bunke hashtables. Hver sett inn start-tag oppretter en hashtable og skyver den på bunken. Den vedlagte sette koder oppretter bønner og lagrer dem i den nyopprettede hashtabellen. I ettertid, få koder i den medfølgende malen får tilgang til bønnene i hashtabellen. Figur 4 viser hvordan stabelen vedlikeholdes for nestede maler.

Hver mal i figur 4 får tilgang til riktig bunntekst; bunntekst.html for mal_1.jsp og footer_2.html for mal_2.jsp. Hvis bønnene ble lagret direkte i omfanget av forespørselen, vil trinn 5 i figur 4 overskrive bunnbønnen som er spesifisert i trinn 2.

Malimplementeringer

Resten av denne artikkelen undersøker implementeringen av de tre malkodene: sett inn, sette, og få. Vi begynner med sekvensdiagrammer, og starter med figur 5. Den illustrerer hendelsesforløpet for sett inn og sette tagger når en mal brukes.

Hvis en malstabel ikke allerede eksisterer, blir sett inn start-tag oppretter en og plasserer den i forespørselsomfang. En hashtable blir deretter opprettet og dyttet på bunken.

Hver sette start tag skaper en PageParameter bønne, lagret i hashtabellen opprettet av vedlegg sett inn stikkord.

Innlegget slutt tag inneholder malen. Malen bruker få koder for å få tilgang til bønnene opprettet av sette koder. Etter at malen er behandlet, blir hashtabellen opprettet av sett inn start-koden er spratt av bunken.

Figur 6 viser sekvensdiagrammet for mal: få.

Maletikettoppføringer

Taghåndteringsimplementeringer for malkodene viser seg å være greie. Eksempel 3.a lister opp Sett inn merkelapp klasse - taggbehandleren for mal: sett inn.

Eksempel 3.a. InsertTag.java



	name = 'editPanel'/>