In questo quarto articolo della serie, affrontiamo un aspetto cruciale per qualsiasi sistema di gestione delle informazioni: quello della trasformazione e della visualizzazione dei contenuti. Vedremo come si effettua il rendering del nostro modello di contenuti e quali sono le interessanti possibilità messe a disposizione da WebCenter Sites.

Introduzione

Abbiamo visto nelle parti precedenti come modellare il contenuto di un sito, usando prevalentemente i Flex Assets, ma anche citando i Basic Asset standard come le Page. Una volta che il modello è pronto, il passo successivo è trasformarlo in un sito vero e proprio, ovvero effettuarne il rendering.

Il rendering viene svolto definendo dei Template. I template sono a loro volta degli asset, con la peculiarità di contenere una Java Server Page e di essere usati non per contenere dati ma codice. Notare che se è vero che una JSP fa parte di un template, non è vero che un template sia semplicemente una JSP. Un template infatti mantiene altre informazioni come il tipo a cui si applica, dei parametri specifici (la cosiddetta mappa di informazioni), informazioni di caching, parametri impliciti, eccetera. Inoltre le JSP dei template fanno riferimento a dei tag custom che hanno senso solo nel contesto specifico in cui il template è invocato. In definitiva un template è una JSP utilizzabile solamente nel contesto specifico del CMS WebCenter Sites.

In questo articolo vedremo come si effettua il rendering di un modello di contenuti, cercando di capire la logica che occorre applicare quando si definiscono i template. La codifica specifica verrà affrontata nel prossimo articolo.

La SitePlan

In generale, un sito WCS è composto da un certo numero di asset. Tuttavia non c’è relazione diretta tra asset e pagine web. Per pagina web intendiamo un file in HTML che corrisponde a uno specifico URL, ottenuto come risultato del rendering di un gruppo di asset. Per ottenere una pagina, la best practice è quella di identificare alcuni asset e utilizzarli come elementi di ingresso per il rendering.

Gli asset che vengono identificati come “punti di ingresso” del sito sono quelli che vengono normalmente messi nella SitePlan. La SitePlan è un tab speciale presente di default nella installazione di WCS. La SitePlan viene composta creando Pages, “piazzandole” (usando la funzione Place) ed editandole inserendo in esse dei “figli”.

Per chiarire ed esemplificare guardate la figura 1 che illustra una SitePlan già composta.

Figura 1 – La struttura di una SitePlan con i diversi elementi che la compongono.

Come si può vedere, abbiamo una SitePlan in gran parte fatta da Page, ma non solo. In effetti, in molti casi i punti di ingresso in un sito (che corrispondono a una completa web page e vengono identificati da un unico URL) sono costituiti da un asset di tipo Page.

Il vero ruolo dell’asset Page

Ma attenzione a non commettere tuttavia un comune fraintendimento: assumere che per ogni punto di ingresso si debba per forza usare un asset Page. È invece possibile (e raccomandato) scrivere i template in grado di effettuare il rendering di una pagina web prendendo come punto di ingresso anche asset di tipo diverso da Page.

Richiedere che siano solo le Page i punti di ingresso porta a dover aggiungere una Page per ogni specifico contenuto che si vuole visualizzare, e questo normalmente è una perdita di tempo per la redazione (oltre che un overhead inutile). WCS usa di fatto le Page per i nodi interni dell’albero della SitePlan mente le foglie sono di tipo diverso da Page.

Notare anche che non è detto che tutti gli asset del sito vengano messi nella SitePlan: invece vengono messi solo quelli che sono utili a rappresentare il punto di ingresso nel sito. Ma ne possono esistere molti altri che vengono comunque renderizzati di solito seguendo associazioni o relazioni partendo da asset che sono stati messi nella SitePlan.

I template

I template in WCS sono asset come gli altri, e si gestiscono allo stesso modo: si creano, si cercano, si editano. Il loro uso è speciale, perche’ sono utilizzati per il rendering. Quando si crea un asset Template, occorre anche inserire del codice JSP (normalmente inserito in una textarea). Questo è codice che viene utilizzato per il rendering dei template. Una volta che si identifica il punto di ingresso di un sito, si identifica l’asset per tipo e per id (usando i parametric standard “c” e “cid“) , poi si invoca un template (normalmente chiamato “/Layout“) che comincia a effettuare il rendering del sito).

Una cosa estremamente importante da capire è che i template sono tipizzati: ovvero per ogni template si deve specificare il tipo di asset a cui si applicano. Per capirsi, certi template si applicano solo a Page, altri solo a specifici flex type. I template possono essere anche Typeless, il che significa in realtà che si applicano a più tipi, perche’ non ne esitono di non applicati ad alcun tipo.

Il più importante template Typeless è proprio il layout, che è normalmente il primo template che viene eseguito quando si inizia il rendering. Il layout va applicato a qualunque tipo di asset rappresenti un punto di ingresso. Come abbiamo detto, nella SitePlan ci possono essere vari tipi di asset e per questo motivo il layout è tipicamente Typeless.

Prima di andare avanti, precisiamo meglio la notazione. Normalmente i template che si applicano a tipi specifici, come la Page hanno un nome che inizia con quel tipo, per esempio Page/Body. I template Typeless omettono il prefisso con il nome del tipo, e quindi di solito cominciano per “/“. Per quando riguarda il layout, per sottolineare che si applica a più tipi di asset, si usa un nome come /Layout.

Il layout

Il layout è il template di ingresso per quando riguarda il rendering. Il compito di questo template è proprio quello di effettuare un rendering del layout generale del sito. In generale si opera un partizionamento della pagina del sito come quello illustrato in figura 2.

Figura 2 – Il partizionamento della pagina per suddividerla secondo precisi principi di architettura dell’informazione.

Ovviamente altri siti possono effettuare partizionamenti differenti ma il partizionamento illustrato in figura è abbastanza comune. Si può riconoscere la navigazione principale (TopNav), la navigazione secondaria (SideNav), un footer che di solito è uguale in tutte le pagine e il detail, ossia la parte centrale della pagina in cui sono riportati i principali contenuti informativi.

Quello che fa il layout è quello di generare l’HTML comune a tutte le pagine del sito (tipicamente l’head della pagina con tutte le inclusioni e i riferimenti ai CSS) e poi chiamare altri template per la visualizzazione dei dettagli. Alcuni template come la SideNav sono anche essi typeless perche’ si applicano a vari tipi di asset (in generale la navigazione va generata in tutte le pagine del sito).

Altri template, come il “dettaglio”, sono invece tipizzati. E qui scatta il meccanismo, molto potente, dei template tipizzati di WCS. Vediamo di capire meglio.

La tipizzazione dei template

Il meccanismo che permette di collegare il modello dei contenuti (fortemente tipizzato) ai template è quello dell’invocazione tipizzata. Anticipando quello che tratteremo più in dettaglio nella prossima parte, cioè la codifica, vediamo che l’invocazione principale dei template è rappresentata dal tag mostrato nella figura 3.

Figura 3 – Il tag render:calltemplate

Il comportamento di questo tag è peculiare, in quanto l’invocazione effettiva del template dipende dal nome del template invocato, ovvero quanto specificato dal parametro tname. Se il tname è il nome di un template typeless (qualcosa come /SideNav per esempio) allora il template viene invocato direttamente. Ma se il template non è typeless, allora viene invocato un template il cui nome è composto dal nome del tipo seguito da una barra e dal nome del template specificato. Per chiarire il concetto, se si specifica come tname “Detail” verrà invocato il template “Page/Detail” se il tipo del template invocato (specificato dal paramentro c) è Page, mentre verrà invocato il template “PressRelease/Detail” se il tipo del template è PressRelease.

Ovviamente i due template non devono necessariamente essere uguali. La cosa importante è che nel layout c’è una chiamata “generica” che invoca un template che però dipende dall’effettivo template che al momento viene renderizzato.

Se si seleziona un template PressRelease il risultato è quello che si vede nella figura 4.

Figura 4 – Il risultato ottenuto selezionando il template PressRelease.

Se invece si vuole renderizzare una Page, che è un contenitore, il risultato sarà piuttosto differente ed è mostrato nella figura 5.

Figura 5 – Ed ecco il risultato del rendering di una Page, che è un contenitore.

Il concetto importante è che siccome la Page è sostanzialmente un contenitore, allora deve fare riferimento ai figli e produrre dei sommari per ciasuno di esso.

In questo caso si usa il content model per seguire una relazione. Dalla Page si prendono i figli che sono stati inseriti nella SitePlan, e si invocano i template appropriati. In questo caso si riutilizza la call template, usando come parametro c (il tipo) quello dei figli (delle PressRelease in figura), e selezionando invece come template da invocare Summary. Il risultato sarà che verrà invocato il template PressRelease/Summary.

Riassumendo

Il meccanismo di fondo di WCS è quello di definire un set di template con nomi standardizzati per ogni tipo di contenuto. Quindi avremo per esempio

• Page/Detail
• Page/Summary
• Page/Link
• PressRelease/Summary
• PressRelease/Detail
• PressRelease/Link

Questi template renderizzano i due tipi di asset come un dettaglio completo, come un sommario o come un link. Al tutto si aggiungono dei template typeless, che invece sono capaci di renderizzare qualunque tipo di template (presumibilmente senza doverne conoscere i dettagli interni di struttura).

Template di questo tipo sono il layout o la navigazione. I vari casi sono riassunti nella figura 6.

Figura 6 – Un esempio riassuntivo con vari tipi di template.

Quando si vuole visualizzare una PressRelease, si invoca il layout che invoca il PressRelease/Detail (e gli altri template per il top, il footer e la navigazione che non abbiamo trattato qui). Quando si vuole visualizzare una Page, si invoca il layout che invoca il Page/Detail, che a sua volta prende tutti gli asset collegati e li visualizza come PressRelease/Summary. A loro volta ciascuno di questi Summary produrrà un link alla pagina complete invocando uno specific PressRelease/Link.

Conclusioni

In questo articolo abbiamo visto il meccanismo generale di rendering degli asset, focalizzandoci sulla tipizzazione dei template. Ciò che abbiamo analizzato è sostanzialmente il modo in cui WCS definisce un set di template con nomi standardizzati per ogni tipo di contenuto. Nel prossimo articolo, invece, entreremo nei dettagli della codifica, illustrando alcuni dei tag disponibili per scrivere le JSP.