Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

169 gennaio
, anno 2012

WebCenter Sites: Web Experience Management secondo Oracle

V parte: Il rendering del content model

Avatar

Michele Sciabarrà

Michele Sciabarrà, CTO della Sciabarra srl (ma vah!) si occupa di Java da... molto tempo. Per esempio nel 1996 ha scritto il primo articolo su Java, sulla storica rivista Computer Programming, e ha partecipato alla prima conferenza italiana su Java, presentando alcune delle sue applicazioni, tra le prime in Italia realizzate in Java. Strada facendo ha inoltre scritto un paio di libri, è andato a lavorare a Londra dove è stato anche dipendente di Fatwire Software. Dopo mille peripezie si occupa attualmente (che strano) di Fatwire... ops Oracle WebCenter Site e scrive sul suo sito http://www.sciabarra.com/ uno dei più apprezzati blog sull

MokaByte

WebCenter Sites: Web Experience Management secondo Oracle

V parte: Il rendering del content model

Michele Sciabarrà

Michele Sciabarrà

  • Questo articolo parla di: Programmazione & Linguaggi, UX design & Grafica

Nei precedenti articoli si è visto come modellare I contenuti, in astratto, secondo un preciso content model. Una volta che il modello dei contenuti sia stato definito, è ora possibile passare al rendering del content model e vedere un po’ di codice.

Introduzione

Nelle precedenti puntate abbiamo visto in astratto come modellare i contenuti. Assumendo che un modello di contenuti adesso sia stato ragionevolmente definito, in questo articolo vedremo finalmente un po’ di codice, quello che un programmatore Java si aspetterebbe fin dal principio e che invece in questo caso è stato semplicemente rimandato fino a qui.

Non mi stancherò mai di ripetere, anche se purtroppo è un errore commesso molto frequentemente, che WCS non è un generico ambiente di esecuzione di JSP, ma ha delle regole precise che vanno rispettate. In particolare i template sono generalmente cachizzati: chiamando un template non è detto che venga eseguito del codice; invece è probabile che venga estratto dalla cache codice HTML preventivamente calcolato. Quindi non è possibile scrivere del codice assumendo che ogni template venga eseguito ogni volta che la pagina viene invocata.

Il modello dei contenuti non è in generale semplicissimo. Ci sono vari casi da esaminare in base a come è strutturato il modello. Come abbiamo visto, possiamo avere parent, content, basic e flex asset e altre problematiche come la definizione di associazioni (per i basic asset) o di attribute che puntano ad un altro asset (per il flex).

Iniziamo quindi a vedere alcuni dei  casi principali.

L’ambiente “ics”

Innanzitutto i template hanno un ambiente (chiamato ics per Interface to Content Server) che contiene degli “oggetti” (nel senso Java vero e proprio). Gli oggetti contenuti nell’ambiente sono di vario tipo, ma due tipi sono importanti per lo sviluppatore WCS: liste e  variabili.

Nel listato seguente sono riassunti i tag utilizzabili per leggere questi oggetti:

Extract Data (tag)
Var

 
List

 
List & Var

 

Le variabili vengono valorizzate nei parametri della URL,  nelle chiamate dei template oppure direttamente nella definizione del template. Quindi se si chiama un template specificando cid=123456 la variabile cid sarà stata valorizzata e potrà essere visualizzata. Il tag ics:getvar non fa altro che leggere la variabile e scriverla nell’output.

Sono molto importanti anche le liste, che in realtà non vanno pensate come liste di valori, ma come liste di record (o se volete, come liste di mappe). Il caso di lista semplice con un valore solo è implementato con una lista che contiene una mappa iul cui valore è accessibile con la chiave value.

Le liste sono iterabili utilizzando il tag listloop. L’uso tipico di una lista è il ciclo per estrarne e visualizzarne i valori.

    

Questo ciclo per ogni elemento della lista genera in output il valore associato con la mappa corrispondente. O, in parole più semplici, se si pensa che una lista di record è una tabella, visualizza una colonna della tabella.

Vedremo più avanti che le tabelle sono spesso ottenute quando si estraggono valori di attributi (che possono essere multipli,  e per questo sono delle liste e non delle semplici variabili).

Utilizzare i tag ics:get e ics:listget non è il solo modo di estrarre i valori da variabili e liste. Le JSP prevedono anche un’altra sintassi riassunta di seguito:

Extract/Check Values
GetVar
    <%=ics.GetVar("var") %>
    <%=ics.GetVar("var") != null %>
 
GetList
    <%=ics.GetList("List").getValue("value") %>
    <%=ics.GetList("List") !=null && ics.GetList("List").hasData() %>

Questa sintassi è decisamente più brutta, ma purtroppo è l’unica utilizzabile quando il valore che vogliamo utilizzare deve essere usato come attributo di un tag. Questo è molto importante quando si invocano altri template utilizzando la fondamentale chiamata calltemplate, che andiamo a vedere.

La calltemplate

Di seguito è sintetizzata la calltemplate, che è assolutamente vitale quando si effettua il rendering di un modello di contenuti:

render:calltemplate
<render:calltemplate
    tid="<%=ics.GetVar("tid") %>"
    site="<%=ics.GetVar("site") %>"
    c="<%=ics.GetVar("c") %>"
    cid="<%=ics.GetVar("cid") %>"
    slotname="Detail"
    tnmame="Detail">
        <render:argument
          name="p"
         value= "<%=ics.GetVar("p")%>"/>

Prima di entrare nei dettagli dei parametri del tag, ricordo come si effettua il rendering di un modello di contenuti secondo le line guida standard di WCS:

  1. viene selezionato un asset, identificandolo per id e per tipo;
  2. vengono estratti i valori specifici dell’asset (è  spiegato nei prossimi paragrafi);
  3. il risultato sono delle liste e delle variabili, come spiegato prima; questi valori vengono visualizzati;
  4. se si incontrano altri asset durante il rendering (per esempio figli, o attributi che sono riferimenti ad altri asset), si deve selezionare l’altro asset e invocare una diversa calltemplate per renderizzare lo specifico asset.

Questo in pratica si traduce nel chiamare una diversa calltemplate ogni volta che si incontra un altro asset.

La calltemplate è piuttosto verbosa in quanto richiede una considerevole quantità di paramentri. Per fortuna, site e tid normalmente non cambiano (sono impostati implicitamente dal sistema), e quindi vengono passati così  come sono. Invece c e cid rappresentano l’asset corrente. Tradizionalment il parameter c contiene il tipo dell’asset mentre il cid contiene l’id, come si intuisce. Applicando le regole descritte prima, c e cid dovrebbero sempre avere un valore facile da identificare: o sono i valori passati nell’URL, o sono i valori estratti da attributo o da una associazione.

Rimane sostanzialmente da specificare caso per caso tname, che segue una semplice regola: se il nome inizia con ‘/‘ il template invocato si considera “senza tipo”, mentre se non comincia con ‘/’ si considera “tipizzato”. Questo in pratica significa the se il tname è qualcosa come ‘/Layout‘, allora verrà invocato il template che si chiama proprio /Layout. Altrimenti se il tname è “relativo”, il realtà verrà invocato un template il cui nome è uguale a

"ics.GetVar("c")+"/"+ics.GetVar("tname")

Tradotto in pratica, se invoco il template tname=’Body’ e il c corrente è Page, il template effettivamente invocato sarà Page/Body, mentre se il c è Article verrà invocato Article/Body.

Questo meccanismo è utilissimo per implementare il sistema di templating modulare e tipizzato che è stato descritto nelle precedenti puntate.

Rendering di un basic asset

Completiamo il quadro adesso illustrando come si estraggono i dati da un asset. Sono possibili sostanzialmente due casi: Basic Asset e Flex Asset. Di seguito sono sintetizzati i tag che servono per estrarre i dati da un basic asset.

Get Basic Asset Data
<asset:load
 name="currentPage"
 type="Page"
 objectid="<%=ics.GetVar("cid") %>"/>
<asset:get
 name="currentPage"
 field="description"
 output="description"/>

La modalità è abbastanza simile a quella dell’estrazione dei dati con un JavaBean in una applicazione Java che fa uso di ORM: viene caricato il record in un bean e poi vengono letti i singoli campi del record come proprietà del bean. La chiamata asset:load legge l’asset, nell’esempio di tipo Page e di id cid (in questo caso passato nella variabile cid). A questo punto nell’ambiente c’è un oggetto chiamato currentPage.

Come dicevo prima, nell’ambiente non si hanno solo liste e variabili ma anche generic POJO Java. I POJO generati sono però generalmente opachi allo sviluppatore, eccetto per la lettura di campi che viene fatta con la asset:get. Finalmente, dopo questa chiamata, il valore del campo dell’asset è posto in una variabile (specificata da output in asset:get) e può essere visualizzato.

Rendering degli attributi di un flex asset

Nell’esempio precedente abbiamo visto come fare ad estrarre i dati da un Basic Asset, ma nella maggior parte dei casi WCS utilizza i Flex Asset. I Flex Asset hanno una struttura un po’ più complessa: sono infatti memorizzati come un asset principale, il “padre”, e una serie di attributi correlati, i “figli”. Qui di seguito possiamo vedere come estrarre il valore di un attributo:

Get Flex Asset Data
<assetset:setasset
  type=‘<%=ics.GetVar("c") %>'
  id=‘<%=ics.GetVar("cid") %>'
  name="myAssetSet"/>
<assetset:getattributevalues
  name="myAssetSet"
  attribute="Attr"
  listvarname="Attr"
  typename="Content_A" />

Nel primo passo, si utilizza la chiamata assetset:setasset. Questa chiamata crea un POJO speciale di tipo myAssetSet che è in pratica il padre degli attributi. A questo punto è possibile utilizzarlo con il tag assetset:getattributevalues che ha la capacità di produrre una lista (la lista Attr) di tutti i valori dell’attributo che appartengono all’asset selezionato. Ricordiamo che in generale un attributo può avere valori multipli quindi il tag ritorna sempre una lista , e ogni record della lista ha un solo campo, che si chiama value.

Un importante trucco: siccome le liste sono sempre posizionate al primo record, è possibile utilizzare il tag listget senza doverlo inserire in un listloop. Quindi se sappiamo che vogliamo estrarre un attributo con un valore singolo, possiamo scrivere direttamente


per ottenere il valore senza cicli. Questo rende i flex attribute quasi tanto semplici da usare anche se è riconosciuto che i flex sono in generale più complicati da usare.

Conclusioni

Abbiamo visto come fare a renderizzare il modello almeno nei casi principali. In realtà la libreria di tag offerta da WCS è ben più ampia di così e offre una grande quantità di servizi, inclusi blog, ricerche, invio di email, workflow e molto altro, che non possono essere coperti in questo breve spazio. Invitiamo a consultare la documentazione allegata in WCS per i dettagli.

 

 

 

Facebook
Twitter
LinkedIn
Avatar

Michele Sciabarrà

Michele Sciabarrà, CTO della Sciabarra srl (ma vah!) si occupa di Java da... molto tempo. Per esempio nel 1996 ha scritto il primo articolo su Java, sulla storica rivista Computer Programming, e ha partecipato alla prima conferenza italiana su Java, presentando alcune delle sue applicazioni, tra le prime in Italia realizzate in Java. Strada facendo ha inoltre scritto un paio di libri, è andato a lavorare a Londra dove è stato anche dipendente di Fatwire Software. Dopo mille peripezie si occupa attualmente (che strano) di Fatwire... ops Oracle WebCenter Site e scrive sul suo sito http://www.sciabarra.com/ uno dei più apprezzati blog sull

Michele Sciabarrà

Michele Sciabarrà

Michele Sciabarrà, CTO della Sciabarra srl (ma vah!) si occupa di Java da... molto tempo. Per esempio nel 1996 ha scritto il primo articolo su Java, sulla storica rivista Computer Programming, e ha partecipato alla prima conferenza italiana su Java, presentando alcune delle sue applicazioni, tra le prime in Italia realizzate in Java. Strada facendo ha inoltre scritto un paio di libri, è andato a lavorare a Londra dove è stato anche dipendente di Fatwire Software. Dopo mille peripezie si occupa attualmente (che strano) di Fatwire... ops Oracle WebCenter Site e scrive sul suo sito http://www.sciabarra.com/ uno dei più apprezzati blog sull
Tutti gli articoli
Nello stesso numero
Loading...

Project management e conoscenza collaborativa

I parte: Dalla creazione di una wiki community, alla sua cura e al suo mantenimento

Architetture REST: un modello di maturità

II parte: I pro e i contro delle architetture REST

Liferay 6.1

Uno sguardo alle novità

Viaggio a El Dorado: alla scoperta della robotica spaziale in Giappone

XI parte: Apparenza e realtà

Nella stessa serie
Loading...

WebCenter Sites: Web Experience Management secondo Oracle

VI parte: Una panoramica su prodotti 'simili'

WebCenter Sites: Web Experience Management secondo Oracle

IV parte: Il rendering di un modello di contenuti

WebCenter Sites: Web Experience Management secondo Oracle

III parte: Il modello dei contenuti

WebCenter Sites: Web Experience Management secondo Oracle

II parte: L'architettura interna di WCS

WebCenter Sites: Web Experience Management secondo Oracle

I parte: Conosciamo WebCenter

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte