Programmering

Introduksjon av portletspesifikasjonen, del 1

Med fremveksten av et økende antall bedriftsportaler, har forskjellige leverandører opprettet forskjellige APIer for portalkomponenter, kalt portleter. Denne variasjonen av inkompatible grensesnitt genererer problemer for leverandører av applikasjoner, portalkunder og portalserverleverandører. For å overvinne disse problemene ble JSR (Java Specification Request) 168, Portlet Specification, startet for å gi interoperabilitet mellom portlets og portaler.

JSR 168 definerer portleter som Java-baserte webkomponenter, administrert av en portlettbeholder, som behandler forespørsler og genererer dynamisk innhold. Portaler bruker portleter som pluggbare brukergrensesnittkomponenter som gir informasjonssystemer et presentasjonslag.

JSR 168s mål er følgende:

  • Definer kjøretidsmiljøet, eller portletbeholderen, for portleter
  • Definer API mellom portlettbeholder og portleter
  • Gi mekanismer for å lagre forbigående og vedvarende data for portleter
  • Gi en mekanisme som gjør det mulig for portleter å inkludere servlets og JSP (JavaServer Pages)
  • Definer en emballasje av portletter for å muliggjøre enkel distribusjon
  • Tillat portabilitet med binær portlet blant JSR 168-portaler
  • Kjør JSR 168-portletter som eksterne portleter ved hjelp av WSRP-protokollen (Web Services for Remote Portlets)

IT-bransjen har bredt akseptert JSR 168. Alle større selskaper i portalområdet er en del av ekspertgruppen JSR 168: Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle , SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO og Vignette. Listen over offisielle støttespillere er enda lengre.

For øyeblikket er JSR 168 i offentlig gjennomgang, og den endelige versjonen er planlagt i september 2003.

I denne artikkelen definerer vi først portaler og portlets, og deretter forklarer konseptene JSR 168 introduserer, inkludert API-elementene. Deretter dykker vi inn i JSRs mer avanserte funksjoner, for eksempel brukerinformasjon, lokalisering og caching. Deretter dekker vi utvidelsespunktene som lar portalleverandører utvide den nåværende definerte funksjonaliteten i portletspesifikasjonen. Artikkelen avsluttes med beskrivelsen av portlet-applikasjonspakking og distribusjon.

Les hele serien på portletspesifikasjonen:

  • Del 1: Få føttene våte med spesifikasjonens underliggende begreper og konsepter
  • Del 2: Portlet APIs referanseimplementering avslører dens hemmeligheter

Grunnleggende definisjoner

I denne delen forklarer vi de grunnleggende definisjonene som brukes i portletspesifikasjonen, inkludert portals grunnleggende arkitektur, portletbeholderen og en portalside.

Portal

EN portal er et nettbasert program som gir personalisering, enkelt pålogging og innholdsaggregering fra forskjellige kilder, og som er vert for presentasjonslaget for informasjonssystemer. Aggregasjon er prosessen med å integrere innhold fra forskjellige kilder på en webside. En portal kan ha sofistikerte personaliseringsfunksjoner for å gi tilpasset innhold til brukerne. Portalsider kan ha forskjellige sett med portlets som skaper innhold for forskjellige brukere.

Figur 1 viser en portals grunnleggende arkitektur. Portal-webapplikasjonen behandler klientforespørselen, henter portlettene på brukerens nåværende side, og kaller deretter portlettbeholderen for å hente inn hver portlettens innhold. Portletbeholderen gir kjøretidsmiljøet for portlettene og kaller portlettene via Portlet API. Portletbeholderen blir ringt opp fra portalen via Portlet Invoker API; beholderen henter informasjon om portalen ved hjelp av Portlet Provider SPI (Service Provider Interface).

Side

Figur 2 viser de grunnleggende portalsidekomponentene. Selve portalsiden representerer et komplett markupdokument og samler flere portletvinduer. I tillegg til portletene kan siden også bestå av navigasjonsområder og bannere. Et portletvindu består av en tittellinje med portlettens tittel, dekorasjoner og innholdet produsert av portletten. Dekorasjonene kan inneholde knapper for å endre portletens vindusstatus og modus (vi forklarer disse konseptene senere).

Portlet

Som nevnt ovenfor er en portlet en Java-basert webkomponent som behandler forespørsler og genererer dynamisk innhold. Innholdet som genereres av en portlet kalles a fragment, et stykke markering (f.eks. HTML, XHTML eller WML (Wireless Markup Language)) som følger visse regler. Et fragment kan aggregeres med andre fragmenter for å danne et komplett dokument, som vist i figur 3. En portlets innhold aggregeres normalt med innholdet i andre portlets for å danne portalsiden. En portlettbeholder administrerer en portlets livssyklus.

Nettklienter samhandler med portleter via et forespørsel / svarparadigme implementert av portalen. Vanligvis samhandler brukere med innhold produsert av portleter ved for eksempel å følge lenker eller sende inn skjemaer, noe som resulterer i at portletthandlinger mottas av portalen, som deretter videresendes til portlettene som er målrettet av brukerens interaksjoner.

Innholdet som genereres av en portlet, kan variere fra bruker til bruker, avhengig av portlettens brukerkonfigurasjon.

Portletbeholder

EN portletbeholder kjører portleter og gir dem det nødvendige kjøretidsmiljøet. En portletbeholder inneholder portleter og administrerer livssyklusen deres. Det gir også vedvarende lagringsmekanismer for portlettpreferansene. En portlettbeholder mottar forespørsler fra portalen om å utføre forespørsler på portlettene som er vert for den. En portletbeholder er ikke ansvarlig for å samle innholdet produsert av portlettene; selve portalen håndterer aggregering.

En portal og en portletbeholder kan bygges sammen som en enkelt komponent i en applikasjonssuite eller som to separate komponenter i en portalapplikasjon.

Begreper

Denne delen forklarer de grunnleggende programmeringskonseptene i JSR 168, for eksempel en portlets livssyklus, grensesnitt og moduser og vindustilstander, samt økttilgang, vedvarende lagringstilgang, og hvordan du inkluderer servlets og JSP-sider.

Portlets livssyklus

Den grunnleggende livssyklusen til en JSR 168-portlet er:

  • I det: initialiser portletten og sett portletten i bruk
  • Håndter forespørsler: behandle forskjellige typer handlings- og gjengivelsesforespørsler
  • Ødelegge: sette portletten ut av drift

Portletbeholderen administrerer portlets livssyklus og kaller de tilsvarende metodene på portletgrensesnittet.

Portletgrensesnitt

Hver portlet må implementere portletgrensesnittet, eller utvide en klasse som implementerer portletgrensesnittet. Portletgrensesnittet består av følgende metoder:

  • init (PortletConfig config): for å initialisere portletten. Denne metoden kalles bare én gang etter at portleten er startet. Denne metoden kan brukes til å lage dyre objekter / ressurser som brukes av portletten.
  • processAction (ActionRequest-forespørsel, ActionResponse-svar): for å varsle portletten om at brukeren har utløst en handling på denne portletten. Bare én handling per klientforespørsel utløses. I en handling kan en portlet utstede en omdirigering, endre portletmodus eller vindustatus, endre den vedvarende tilstanden eller angi gjengivelsesparametere.
  • gjengi (RenderRequest-forespørsel, RenderResponse-svar): for å generere markeringen. For hver portlet på den gjeldende siden kalles gjengivelsesmetoden, og portletten kan produsere markering som kan avhenge av portletmodus eller vindustilstand, gjengivelsesparametere, forespørselsattributter, vedvarende tilstand, øktdata eller backend-data.
  • ødelegge(): for å indikere livssyklusen til portletten. Denne metoden lar portletten frigjøre ressurser og oppdatere vedvarende data som tilhører denne portletten.

Portletmodus

En portletmodus indikerer funksjonen en portlet utfører. Vanligvis utfører portleter forskjellige oppgaver og lager forskjellig innhold avhengig av funksjonene de for øyeblikket utfører. En portletmodus anbefaler portletten hvilken oppgave den skal utføre og hvilket innhold den skal generere. Når du påkaller en portlet, gir portlettbeholderen den nåværende portlettmodusen til portletten. Portletter kan programmatisk endre modus når de behandler en handlingsforespørsel.

JSR 168 deler portletmodus i tre kategorier:

  1. Nødvendige moduser: Hver portal må støtte modusene Rediger, Hjelp og Vis. En portlet må i det minste støtte visningsmodusen som brukes til å gjengi markering for en side. Redigeringsmodus brukes til å endre innstillinger per bruker for å tilpasse portletmarkeringen, og hjelpemodus brukes til å vise et hjelpeskjermbilde.
  2. Valgfrie tilpassede moduser: Dette er moduser som en portal kan støtte; mens du er i valgfri modus, kalles det kanskje ikke til en portlet. De valgfrie modusene inkluderer Om-modus for å vise en "om" -melding; Config-modus for å la administratorer konfigurere portletten; Edit_defaults-modus for å la en administrator forhåndsinnstille redigeringsmodusens verdier; forhåndsvisningsmodus for å vise portletens forhåndsvisning; og utskriftsmodus for å gjengi en visning som lett kan skrives ut.
  3. Portalselgerspesifikke moduser: Disse modusene er ikke definert i spesifikasjonen og er derfor leverandørspesifikke.

Vindu stater

En vindustilstand angir mengden portalsideplass som tildeles innholdet som genereres av en portlet. Når du påkaller en portlet, gir portletbeholderen portletens nåværende vindustatus. Portletten kan bruke vinduetilstanden til å bestemme hvor mye informasjon den skal gjengi. Portletter kan programmatisk endre vindustatus når de behandler en handlingsforespørsel.

JSR 168 definerer følgende vindustatus:

  • Vanlig: Indikerer at en portlet kan dele siden med andre portleter. Dette er standardvinduetilstanden.
  • Maksimert: Indikerer at en portlett kan være den eneste portletten på portalsiden, eller at portletten har mer plass i forhold til andre portleter på portalsiden, og kan derfor produsere rikere innhold enn i en normal vindustilstand.
  • Minimert: Indikerer at portletten bare skal gi minimal utgang eller slett ingen utdata.

I tillegg til disse vindustilstandene tillater JSR 168 portalen å definere leverandørspesifikke vindustilstander.

En portlet kan kalles i en av disse tre vindustilstandene, men er fri til å produsere den samme markeringen for alle tre tilstandene.

Vedvarende butikk

Portletten kan lagre vedvarende data for en bestemt bruker ved å bruke PortletPreferanser gjenstand. Innstillinger kan leses og skrives i handlingsfasen, og leses i gjengivelsesfasen. Den foretrukne modusen for å skrive innstillinger er Redigeringsmodus, som gir brukeren en tilpasningsskjerm. Innstillingene kan være enten strenger eller strengmatrixverdier tilknyttet en nøkkel av typen streng. Innstillinger kan forhåndsinnstilles med standardverdier i distribusjonsbeskrivelsen.

Innstillinger og portlettens definisjon i distribusjonsbeskrivelsen definerer sammen en portlet, noen ganger kalt a portletenhet.

Økter

JSR 168s øktkonsept er basert på HttpSession definert for webapplikasjoner. Ettersom portletapplikasjoner er webapplikasjoner, bruker de samme økten som servletter. For å tillate portleter å lagre midlertidige data private til en portlett, er standard øktomfang portletten omfang. I dette omfanget kan portletten lagre informasjon som er nødvendig på tvers av brukerforespørsler og spesifikk for en portletenhet. Attributter som er lagret med dette omfanget, er prefikset i økten av portletbeholderen for å unngå at to portleter (eller to enheter med samme portlettdefinisjon) overskriver hverandres innstillinger.

I tillegg til omfanget av portlettøkten, støtter JSR 168 Webapplikasjon øktomfang. I dette omfanget kan alle komponenter i webapplikasjonen få tilgang til informasjonen. Informasjonen kan brukes til å dele forbigående tilstand mellom forskjellige komponenter i samme webapplikasjon (f.eks. Mellom portleter eller mellom en portlett og en servlett).

Inkludert servlets / JSP-sider

For å støtte Model-View-Controller-mønsteret, må portletten kunne inkludere innhold generert fra servlets og JSP-sider. På denne måten kan portletten fungere som kontroller, fylle en bønne med data og inkludere en JSP-side for å gjengi utdataene.

I JSR 168 er inkluderingsmekanismen for servlets og JSP-sider den samme for Servlet API. Via portletkonteksten blir en forespørselssender hentet for en gitt bane; de inkludere() metoden blir deretter kalt på dette forespørselsdistribusjonsobjektet:

 PortletRequestDispatcher rd = getPortletContext (). GetRequestDispatcher (editJSP); rd.include (portletRequest, portletResponse); 

Justering med WSRP

WSRP samler innhold produsert av portlets som kjører på eksterne maskiner som bruker forskjellige programmeringsmiljøer, som J2EE (Java 2 Platform, Enterprise Edition) og .Net. WSRP-tjenester er presentasjonsorienterte, brukervendte webtjenester som plugger og spiller med portaler eller andre applikasjoner. De lar bedrifter tilby innhold eller applikasjoner uten å kreve manuell innholds- eller applikasjonsspesifikk tilpasning ved å konsumere portaler; portaler kan enkelt samle WSRP-tjenester uten programmeringsinnsats.

JSR 168-ekspertgruppen justerte konseptene nøye mellom JSR 168 og WSRP. Følgende liste viser hvor mye hovedkonseptene har blitt justert mellom begge standarder:

$config[zx-auto] not found$config[zx-overlay] not found