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:

107 maggio
, anno 2006

Cocoon: una piattaforma di pubblicazione di dati XML

II parte: esempi di utilizzo

Avatar

Angelo Stefani

Angelo Stefani, nato a Vetralla (VT) il 30/03/1978. Dal 1992 al 1997 frequenta l‘ ITIS Leonardo da Vinci di Viterbo dove consegue il Diploma di Perito Industriale Capotecnico spec. Informatica. Attualmente iscritto al corso di laurea in Ingegneria Informatica della facoltà di Ingegneria presso l‘ Università degli studi di Roma "La Sapienza", sta lavorando alla tesi di laurea "Adattamento di contenuti su dispositivi eterogenei" avente come argomento principale Cocoon.
Informazioni più aggiornate sono disponibili su http://angelostefani.blogspot.com/

MokaByte

Cocoon: una piattaforma di pubblicazione di dati XML

II parte: esempi di utilizzo

Angelo Stefani

Angelo Stefani

  • Questo articolo parla di: Architetture dei sistemi, Frameworks & Tools, Java

Ecco la seconda parte della serie sulla piattaforma di pubblicazione dinamica dei contenuti XML. Analizzeremo la struttura della Web Application e presenteramo alcuni esempi pratici di utilizzo, analizzando anche le “infrastrutture” necessarie al suo funzionamento.

Introduzione

Nel precedente articolo è stata descritta l‘architettura di Cocoon. In questo vedremo degli esempi pratici di utilizzo.
Cocoon è una Java Web Application, quindi, necessita di un Java Servlet engine. Nel seguente esempio utilizzeremo Tomcat, ma è possibile utilizzare anche altri Java Servlet engine.

Struttura della Web Application:

	omcat...webappscocoon.warcocoon...esempiositemap.xmapindex.xml
esourcesimageslogo.jpgstylesheetsxml2html.xslxml2wml.xslcontenutihelp.xmlFAQssitemap.xmapfaqs.xml	utorialssitemap.xmaptutorial01.xmltutorial02.xml

Il main sitemap

Andiamo a vedere il listato del main sitemap, ovvero del file sitemap.xmap contenuto all‘interno della cartella esempio, tenendo bene in mente i seguenti concetti fondamentali:

Il sitemap è il punto centrale di gestione di un sito Web realizzato con Cocoon, infatti, è il punto dove vengono definite le pipelines.

Una pipeline è una sequenza di procedure che consentono a Cocoon di sapere cosa fare quando un documento viene richiesto.

La funzione principale del matcher è quella di consentire ai documenti richiesti di essere gestiti all‘interno di una pipeline. Se un matcher intercetta una richiesta, Cocoon passa la richiesta da gestire alla rispettiva pipeline. Se un matcher non intercetta la richiesta, Cocoon prova con il prossimo matcher della pipeline, finchà© non viene raggiunta la fine.

Per effettuare una trasformazione sono necessari almeno i seguenti tre componenti: un generator per leggere il documento XML, un transformer per effettuare la trasformazione, ed un serializer per restituire il risultato.

Analizziamo in dettaglio una porzione del listato del main sitemap:

Per prima cosa viene dichiarato un pattern all‘interno di un match. Questo pattern consente di intercettare tutte le richieste riguardanti files in formato HTML.
Successivamente è stato aggiunto un generator per leggere il documento XML (avente lo stesso nome del file HTML richiesto) all‘interno della directory contenuti.
E‘ stato quindi aggiunto un transformer per effettuare la trasformazione del documento XML utilizzando uno specifico stylesheet.
Infine, utilizzando un serializer, è stato possibile restituire il risultato in formato HTML al richiedente.

Strutturare gerarchicamente la Web Application

Lo sviluppo di Web Application di grandi dimensioni può essere agevolato mediante il concetto di subsitemaps. Mediante i subsitemaps è possibile organizzare l‘intero sito mediante una struttura ad albero. Un subsitemap deve essere montato all‘interno del main sitemap.
Analizziamo ora la seguente porzione del listato del main sitemap:

L‘attributo src definisce la locazione del subsitemap. Se il valore assegnato a questo attributo termina con uno slash, per trovare il sitemap viene aggiunto automaticamente sitemap.xmap. Altrimenti, Cocoon assume che l‘attributo src si riferisca direttamente al file contenente il subsitemap.
così come il main sitemap, i subsitemaps possono essere configurati anche per quello che riguarda il reloading. L‘attributo check-reload, il cui valore di default è true, definisce come devono essere gestite eventuali modifiche ai subsitemaps. Nel caso in cui il valore venga impostato su false, gli effetti delle modifiche saranno visibili soltanto al riavvio del servlet engine.
L‘ultimo attributo è uri-prefix ; Quando una richiesta arriva a Cocoon, viene analizzato il root sitemap utilizzando l‘URI della richiesta. Ora, se all‘interno del sitemap viene raggiunto un mount point relativo ad un subsitemap, il subsitemap viene analizzato utilizzando lo stesso URI.

XSP

XML Server Pages (XSP) è una tecnologia di Cocoon 2 che consente la generazione dinamica di sorgenti dati XML per le pipelines.
XSP ha molte cose in comune con JSP. Entrambe le tecnologie:

  • Sono costituite da una combinazione di markup e codice programma
  • Vengono compilate in forma binaria per l‘esecuzione
  • Consentono la creazione di librerie di tag personalizzati

Le differenze principali tra XSP e JSP sono due:

  • XSP offre un framework per miscelare codice scritto in Java ma anche in altri linguaggi di programmazione (ad esempio Perl) con markup XML. JSP, invece, è una tecnologia puramente Java.
  • XSP genera dinamicamente dati XML per le pipelines di Cocoon, le quali poi consentono di ottenere il formato di presentazione desiderato. JSP, invece, è una presentation layer technology utilizzata per produrre HTML o XML, tipicamente alla fine di una serie di elaborazioni.

Cocoon 2 fornisce un ServerPagesGenerator component che coordina la compilazione e l‘esecuzione delle pagine XSP.
Il ServerPagesGenerator viene dichiarato nel sitemap nel seguente modo:

E‘ possibile ottenere dati XML utilizzando una pipeline come la seguente:

E‘ possibile inoltre ottenere delle pagine HTML o WML utilizzando una pipeline come la seguente:

Vediamo infine il codice sorgente del file time.xsp che consente di generare dati XML rappresentanti un timestamp:

   SimpleDateFormat format = new SimpleDateFormat("EEE, MMM d, yyyy"); String timestamp = format.format( java.util.Calendar.getInstance().getTime());    timestamp

L‘elemento xsp:page è il root element di ogni documento XSP. Questo elemento deve avere l‘attributo language che identifica il linguaggio di programmazione contenuto nella pagina.
Sebbene siano supportati molti linguaggi di programmazione, la scelta migliore per Cocoon 2 è sicuramente Java.
L‘elemento xsp:logic è utilizzato per aggiungere blocchi di codice Java in XSP.
L‘elemento xsp:expr è utilizzato per contenere una espressione il cui valore può essere aggiunto direttamente al documento di output.
Per consentire alla logica di programmazione di fare uso delle API Java, sia standard che personali, si possono utilizzare gli elementi xsp:structure e xsp:include. Questi due elementi vengono utilizzati insieme, con l‘elemento xsp:structure che raggruppa alcuni elementi xsp:include.

java.util.Calendarjava.text.*

Logicsheets

Le logicsheets sono una tecnologia di Cocoon 2 molto simile alle JSP tag libraries. Una logicsheet è una libreria di elementi personalizzati che possono essere aggiunti alle pagine XSP. Diversamente dalle JSP tag libraries, che sono implementate come classi Java, le logicsheets di Cocoon 2 sono implementate utilizzando trasformazioni XSLT. Uno dei vantaggi delle logicsheets è che il documento originale risulta molto più leggibile, in quanto il codice di programmazione può essere sostituito da elementi XML. Inoltre, gli stessi logicsheets possono essere utilizzati in diversi documenti XSP. Cocoon 2 fornisce molte logicsheets predefinite, le quali offrono funzionalità  senza dover scrivere nessuna linea di codice Java.

Conclusione

Abbiamo visto come, mediante Cocoon, sia possibile realizzare una semplice web application per la pubblicazione dinamica di contenuti XML in vari formati. Abbiamo visto come sia possibile organizzare gerarchicamente la struttura della applicazione in modo tale da agevolarne lo sviluppo e la manutenzione. Infine, abbiamo visto le caratteristiche principali di XSP, una tecnologia di Cocoon 2 che consente la generazione dinamica di sorgenti dati XML per le pipelines..

Bibliografia

[1] Massimo Canducci – “XML”, Apogeo, 2005

[2] Aaron Skonnard, Martin Gudgin, “Essential XML Quick Reference”, Addison-Wesley, 2002

[3] Doug Tidwell, “Mastering XML Transformations”, O‘Reilly, 2003

[4] http://www.w3.org/Style/XSL/

[5] http://cocoon.apache.org/

[6] Matthew Langham, Carsten Ziegeler,”Cocoon: Building XML Applications”, New Riders, 2002

Facebook
Twitter
LinkedIn
Avatar

Angelo Stefani

Angelo Stefani, nato a Vetralla (VT) il 30/03/1978. Dal 1992 al 1997 frequenta l‘ ITIS Leonardo da Vinci di Viterbo dove consegue il Diploma di Perito Industriale Capotecnico spec. Informatica. Attualmente iscritto al corso di laurea in Ingegneria Informatica della facoltà di Ingegneria presso l‘ Università degli studi di Roma "La Sapienza", sta lavorando alla tesi di laurea "Adattamento di contenuti su dispositivi eterogenei" avente come argomento principale Cocoon.
Informazioni più aggiornate sono disponibili su http://angelostefani.blogspot.com/

Angelo Stefani

Angelo Stefani

Angelo Stefani, nato a Vetralla (VT) il 30/03/1978. Dal 1992 al 1997 frequenta l‘ ITIS Leonardo da Vinci di Viterbo dove consegue il Diploma di Perito Industriale Capotecnico spec. Informatica. Attualmente iscritto al corso di laurea in Ingegneria Informatica della facoltà di Ingegneria presso l‘ Università degli studi di Roma "La Sapienza", sta lavorando alla tesi di laurea "Adattamento di contenuti su dispositivi eterogenei" avente come argomento principale Cocoon. Informazioni più aggiornate sono disponibili su http://angelostefani.blogspot.com/
Tutti gli articoli
Nello stesso numero
Loading...

Red Hat appende il cappello in casa JBoss

L‘azienda di Marc Fleury acquistata dal leader Linux

Sviluppare Applicazioni AJAX

I parte: realizzare pagine web con un approccio tutto nuovo

Architetture e tecniche di progettazione EJB

VI parte: alcune considerazioni sulla gestione del mapping difficile in CMP2.0

JasperReports: una libreria Open Source per la reportistica

III parte: utilizzo di iReport per la creazione di layout

SOA: dalla teoria alla pratica

VIII parte: Strategie di adozione

Nella stessa serie
Loading...

Device Independence

Approccio server side mediante Cocoon e DELI

Cocoon: una piattaforma di pubblicazione di dati XML

I parte: introduzione al framework

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