Blog e web

Collegamenti utili gratuiti

Introduzione

I Blog, o Web Log, costituiscono probabilmente uno dei fenomeni più importanti che Internet ha prodotto negli ultimi anni, un nuovo sistema che permette a chiunque di pubblicare qualsiasi tipo di testo e contenuto e dove l’utente può esprimere il proprio pensiero in uno spazio auto gestito e dalla struttura semplice ma dal modello vincente.

Questo permette a chiunque, individui o gruppi di persone, di pubblicare informazioni anche senza avere accesso a mezzi di comunicazione tradizionali; prodotti senza condizionamenti i blog si concentrano su qualunque argomento interessi il loro gestore: politica, sport, musica o semplicemente eventi quotidiani.

Se Internet è stato sempre il territorio privilegiato del confronto (attraverso strumenti quali forum, posta elettronica e newsgroup) i blog hanno mutato sostanzialmente gli equilibri in quanto alle potenzialità di relazione implicite della Rete si sono aggiunte la facilità di accesso, la possibilità di fare ricerche tipica del Web e, soprattutto, la possibilità di raggruppare i contributi per persona fornendo così uno strumento di identificazione fortissimo.

Il Blog finisce per diventare una sorta di ‘storia intellettuale dell’individuo’ e costituisce l’alter ego della persona sulla rete fino a diventare un nodo nella rete sociale costituita dall’insieme dei Blog e dalle loro interconnessioni.

Se è vero che nel concetto stesso di Blog non vi è nulla di nuovo, quello che può essere fatto per ampliarne la fruibilità è estenderne l’utilizzo al di fuori del Web, ambiente in cui è nato e nel quale tuttora trova la sua naturale espressione, attraverso strumenti e software che vanno al di là del semplice browser.

La possibilità, per esempio, di aggiornare il proprio Web Log semplicemente spedendo un messaggio di posta elettronica ad un indirizzo predefinito amplifica in maniera esponenziale le potenzialità del Blog come strumento di informazione di prima mano. Dimostrazioni tangibili di queste peculiarità si sono avute nei recenti e tragici momenti successivi agli attentati di Londra del luglio 2005 [MOB05] quando persone dotate di cellulari con foto camera poterono documentare quei terribili momenti scattando foto ed inviandole direttamente alle loro piattaforme di Blog.

Al di là degli aspetti sociologici del fenomeno, l’obiettivo della tesi è la realizzazione di una piattaforma software in grado di realizzare Blog e di permetterne la gestione attraverso il maggior numero possibile di interfacce.

L’applicazione prima di tutto deve essere dotata di tutte le funzionalità tipiche di un software di questo tipo e che saranno descritte in dettaglio. Deve poi implementare un sistema che ne permetta la localizzazione in qualsiasi lingua disponibile e garantire la massima flessibilità in termini di sistema per il salvataggio dei dati che potrà avvenire indifferentemente su database o file XML.

L’obiettivo primario è però quello di permettere di accedere ai dati dell’applicazione attraverso il maggior numero possibile di interfacce con lo scopo di incrementare la flessibilità e la rapidità di aggiornamento delle informazioni all’interno del proprio blog.

Scelte di questo tipo hanno ovviamente reso ancora più importanti decisioni quale quella della separazione del contenuto dalla sua presentazione; un numero elevato di modalità di fruizione di un qualsiasi contenuto, infatti, non può prescindere da una corretta gestione delle problematiche legate alla separazione fra ciò che è definibile come contenuto e quella che invece è la modalità con qui viene visualizzato all’utente.

Le interfacce che si è deciso di implementare permettono di interagire con il blog attraverso tre tipologie di software che si aggiungono alla classica modalità attraverso il Web:

Instant Messaging: una funzionalità di questo tipo permette di utilizzare il proprio client per la messaggistica, che può girare sul proprio computer come sul proprio palmare, per interrogare ed aggiornare il Web Log e, grazie alla principale caratteristica dei sistemi di messaggistica di questo tipo che è la comunicazione in tempo reale, è anche possibile avvertire il gestore del blog immediatamente non appena un lettore lascia dei commenti sul Blog.
Applicazioni desktop: permettono di gestire il proprio Web Log senza l’obbligo della connessione ad Internet in quanto è possibile gestire i propri dati direttamente tramite un’applicazione che è in esecuzione sul proprio computer che si connette al blog solo per l’aggiornamento dei dati e che dispone di un’interfaccia più comoda e tipica delle applicazioni desktop.
Posta elettronica: la semplicità e l’ubiquità di questo mezzo ne fanno un candidato ideale come strumento per aggiornare un Blog vista anche la possibilità di essere utilizzato da telefoni cellulari.

La scelta dell’utilizzo di uno strumento di Instant Messaging come interfaccia e le problematiche relative all’implementazione della stessa costituiscono sicuramente il fattore più innovativo di questo lavoro di tesi in quanto non risultano al momento presenti sul mercato soluzioni di questo tipo.

Il seguito della tesi è così organizzato:

Il Capitolo 2 è dedicato all’introduzione dei concetti legati al mondo del Blog. Vedremo cosa significa Content Management System e come un Web Log ne sia un rappresentante, analizzeremo inoltre il concetto di Social Software e vedremo come sia i Wiki, tipologia di software che descriveremo in maniera sommaria, che i Blog appartengano di diritto a questa categoria. A questo punto ci concentreremo esclusivamente sui Web Log e ne analizzeremo in dettaglio la struttura soffermandoci sugli strumenti che permettono lo scambio di informazioni fra blog ed infine faremo una breve disamina delle principali piattaforme esistenti.
Nel Capitolo 3 sono introdotti gli obiettivi che ci siamo dati nella realizzazione della nostra applicazione ed introdurremo e giustificheremo le scelte tecnologiche fatte concentrandoci su tre aspetti principali. Il primo è quello legato alla scelta della tecnologia lato server utilizzata per realizzare l’applicazione; è ovviamente la scelta più importante in quanto in base ad essa sarà possibile valutare la mole di lavoro necessaria per sviluppare il progetto. Dopodiché analizzeremo le scelte fatte per quanto riguarda lo storage dei dati da parte del nostro blog e vedremo come la soluzione adottata permetterà di utilizzare in maniera trasparente per l’utente sia database relazionali che file XML su filesystem. Infine vedremo le tecnologie scelte per la gestione della parte di presentazione soffermandoci sulla descrizione di XML-RPC ed RSS, le due tecnologie chiave per la comunicazione con altre piattaforme.
Il capitolo 4 prevede la descrizione della progettazione delle caratteristiche dell’applicazione realizzata e delle sue funzionalità. Dopo una disamina breve ma dettagliata delle opzioni disponibili sia al lettore del Blog che all’autore dello stesso sono illustrati alcuni esempi delle potenzialità di accesso multimodale previsti dal software realizzato.
Nel capitolo 5 è illustrata l’applicazione sviluppata nel maggior dettaglio possibile. Le funzionalità sono tali e tante che non è stato ovviamente possibile inserire una descrizione completa dell’applicazione. Dopo una breve introduzione ad alcuni dei concetti chiave di Coldfusion, il prodotto che è stato scelto per sviluppare il nostro software, è analizzata in dettaglio la struttura a livello di filesystem dell’applicazione con la descrizione dello scopo e del funzionamento di ogni file e di ogni cartella. Successivamente viene posta l’attenzione sulle parti di codice più significative riguardanti le funzionalità che caratterizzano maggiormente la nostra applicazione con un’ovvia attenzione alle possibilità di accesso multimodale che sono state previste.
Infine il Capitolo 6 riporta le conclusioni e gli sviluppi futuri di questo lavoro di tesi.

Blog, contenuti ed informazione

In questo capitolo verranno introdotti i concetti di contenuto, CMS e Blog e si illustrerà come questi siano alla base del Web così come lo conosciamo ora.

Introduzione

La natura decentralizzata di Internet e del Web è parte determinante del suo successo, ma è anche la principale responsabile delle problematiche che affliggono oggi chiunque abbia intenzione di utilizzarlo in maniera proficua.

Come cercare le informazioni e come fornirle sono due aspetti distinti dello stesso problema in quanto entrambi si scontrano con l’immane quantità di nozioni e dati presenti sul Web dove non esiste nessun tipo di vincolo riguardo ai contenuti che vi si possono trovare.

Se allora i motori di ricerca (e le loro evoluzioni) si occupano di recuperare le informazioni è però ovvio che il punto centrale del problema è come creare e rendere disponibili contenuti sul Web ed è su questo aspetto che ci concentreremo analizzando i concetti di contenuto e di informazione e cercando di definire una serie di condizioni che un applicativo deve soddisfare per poter essere definito un Content Management System(CMS), e quindi in grado di aiutare chi vuole realizzare contenuti e renderli disponibili sul Web ma anche su altri media [BOI02].

Content Management System

Dati, informazioni e contenuti

Le informazioni diventano contenuto nel momento in cui vengono presentate ed organizzate in una forma fruibile e per un determinato scopo, dal nostro punto di vista creare contenuto partendo da una o più informazioni significa aggiungere all’informazione stessa un layer di dati (metadati) per cercare di descriverla.

L’esempio classico è quello di un articolo o di una news; l’informazione in sé è il contenuto della stessa, ma questa diventa contenuto nel momento in cui aggiungo altre informazioni (metadati) per poterne, per esempio, gestire lo stato (pubblicata, non pubblicata) o collego ad essa altri dati come l’autore, la data di creazione, le eventuali categorie.

Quindi il contenuto può essere visto come un tentativo di conservare aspetti dell’informazione (almeno quelli che interessano) una volta che il tutto viene trasformato in dati gestibili dai computer.

Un domani grazie ai progressi nei campi dell’intelligenza artificiale e nel riconoscimento del linguaggio naturale si potranno forse gestire direttamente le informazioni, evitando quindi il processo di semplificazione (con l’ovvio rischio di perdere aspetti importanti) che si ha nella trasformazione in contenuto [BOI02].

Formattazione del contenuto

Fra i metadati di un contenuto l’insieme delle informazioni che riguardano il formato dei dati inseriti e la formattazione degli stessi al momento della presentazione all’utente sono quelli più importanti.

Questo implica che un’applicazione per gestire contenuti deve essere in grado di trattare formati eterogenei (documenti Word come immagini Jpeg), ma soprattutto deve permettere di visualizzare in un formato consistente i contenuti all’utilizzatore.

E’ a questo livello che uno degli aspetti più importanti nella realizzazione di una soluzione per la gestione dei contenuti, la separazione della presentazione di un contenuto dal contenuto stesso, assume tutto il suo peso; è vero che ogni contenuto in quanto tale viene percepito dall’utente in base a come viene visualizzato, ma è altrettanto vero che se lo stesso contenuto (un articolo per esempio) viene visualizzato su due media differenti (sito Web e quotidiano) non è pensabile che il software che lo gestisce contenga due copie del testo quando questo è identico indipendentemente dalle modalità con le quali l’utente fruisce del contenuto [BOI02].

Struttura dei contenuti

Ancora più importante della presentazione del contenuto è la sua struttura; si tratta di un aspetto fondamentale e critico in quanto errori in fase di definizione della struttura possono poi ripercuotersi con gravi conseguenze in tempi futuri.

Un sistema per gestire contenuti dovrebbe fornire un grado di flessibilità tale da permettere variazioni nel tempo della struttura di un contenuto, ma non sempre tali variazioni possono essere gestite in maniera indolore [BOI02].

CMS, definizione e requisiti

I CMS identificano una categoria di software che si occupano di gestire le problematiche relative alla creazione, modifica e pubblicazione dei contenuti.

Se definire il concetto di ‘contenuto’ è arduo in quanto esso racchiude un’insieme eterogeneo di possibilità, altrettanto difficile è cercare di catalogare i diversi sistemi CMS oggi disponibili. Esiste una molteplicità di prodotti assolutamente incredibile; annoverati fra i sistemi di Content Management ci sono prodotti complessi e di fascia alta ed altri semplici che altro non sono che sistemi realizzati ad hoc e che permettono inserimento, modifica e cancellazione di contenuti che nella maggior parte dei casi coincidono con informazioni visualizzate su siti Web pubblici.

E', infatti, questo l’ambito sul quale la maggior parte dei CMS limita il suo raggio d’azione, se come detto in precedenza contenuto può indicare un enorme varietà di prodotti digitali (nell’accezione più ampia probabilmente tutti) in realtà oggi i CMS vengono usati principalmente per gestire i contenuti di siti Web, intranet ed extranet.

Vediamo ora quali sono le caratteristiche principali che un sistema di CMS deve possedere per venire incontro alle necessità dell’organizzazione che lo implementa.

Gestione centralizzata

Requisito fondamentale è quello di avere un unico repository per tutti i contenuti gestiti; i vantaggi risiedono principalmente in una più semplice organizzazione della struttura che si occupa dell’installazione e della manutenzione del CMS installato. Un ulteriore vantaggio è dato anche dal maggiore controllo possibile sui contenuti non essendo questi replicati in altri punti del sistema [JEN02].

Se questo requisito può sembrare scontato per piccoli sistemi di CMS in realtà non lo è affatto, quando si gestiscono siti di grandi e grandissime dimensioni, in questi casi le problematiche legate all’enorme mole di dati da gestire assumono la rilevanza maggiore.

Separazione dei contenuti dalla presentazione.

Osservando la situazione attuale più che un requisito potrebbe sembrare un desiderio; sono poche le soluzioni, anche fra quelle sofisticate e costosissime, che riescono ad ottenere un’efficace separazione della parte di presentazione di un contenuto dal resto dei suoi dati.

L’obiettivo è quello di rendere indipendenti gli autori dei contenuti; la separazione del contenuto dalla modalità con la quale è visualizzato permette di ottimizzarne il processo di redazione [JEN02].

Workflow

Per Workflow intendiamo l’insieme degli stati che un contenuto può avere durante la sua vita ed un motore di Workflow è necessario per poter controllare e seguire il contenuto dalla sua redazione alla sua pubblicazione; l’utilizzo di permessi di accesso basati sui ruoli consente di ottimizzare il processo che porta dalla redazione del contenuto alla sua pubblicazione permettendo solo a chi ne ha il diritto la possibilità di modificarlo, pubblicarlo ed in generale di modificarne lo stato [JEN02].

Condivisione e riutilizzo dei contenuti

La disponibilità di un repository centrale dei contenuti e la facilità con cui è possibile utilizzarli permette di evitare la duplicazione di documenti e contenuti tipica delle organizzazioni aziendali [JEN02].

Pubblicazione su mezzi eterogenei

La separazione dei contenuti dalla presentazione deve portare anche alla possibilità di pubblicare il contenuto su più mezzi; in altre parole il contenuto va redatto una sola volta, per poi essere riutilizzato e pubblicato su media diversi, quali Internet, CD-ROM, la carta stampata [JEN02].

CMS e Social Software

Come abbiamo visto la categoria dei software di CMS comprende un numero elevatissimo di soluzioni; ogni sito Web che dispone di strumenti per l’inserimento, la modifica e la gestione dei propri contenuti appartiene alla categoria ed ognuno di questi potrebbe avere peculiarità e funzionalità differenti.

Esistono sottocategorie che identificano sistemi CMS nati per soddisfare determinate esigenze e che si distinguono fra loro per la diversa tipologia di contenuto che intendono gestire fermo restando il rispetto dei principi precedentemente elencati [BOI02].

Ci concentriamo ora su due tipologie peculiari di CMS che negli ultimi anni hanno profondamente cambiato il Web grazie alla loro enorme diffusione. Si tratta, in entrambi i casi, di CMS semplici, dove il contenuto è composto di pochi dati e possiede una struttura semplice e lineare.

Entrambi sono sempi di Social Software, software che permette alle persone di incontrarsi, interagire o collaborare attraverso comunicazioni effettuate tramite computer e di formare community online [SHI03].

In un’interpretazione estensiva del termine è possibile far rientrare nel Social Software vecchi strumenti come le mailing list ed i newsgroup ma molti tendono a restringere l’ambito a tipologie di software più recenti come i Blog ed I Wiki. Altri invece preferiscono utilizzare il termine non per riferirsi ad una tipologia di software, ma piuttosto ai diversi tipi di comunicazione che è possibile instaurare online; da questo punto di vista le persone possono formare community tramite comunicazioni di tipo uno a uno (email, Instant Messaging), uno a molti (pagine Web e Blog) o molti a molti (wiki) [WIK06a].

Dalla definizione risulta chiaro che non tutte le applicazioni che caratterizzano il Social Software sono CMS (potrebbe essere vero il contrario utilizzando l’interpretazione estensiva data sopra) lo sono, però, sicuramente le due tipologie che analizziamo ora.

I Wiki

Prendiamo proprio dal più eclatante esempio di Wiki, Wikipedia [WIK06b], la definizione:

“Un wiki è un sito Web (o altrimenti una collezione di documenti ipertestuali) che permette ad ogni utilizzatore di aggiungere contenuti, come in un forum, ma anche di modificare i contenuti esistenti inseriti da altri utilizzatori.”.

Wikipedia è un’enciclopedia Web completamente gratuita, disponibile in svariate lingue, che oramai conta più di due milioni e mezzo di articoli; la sua caratteristica peculiare sta nel fatto che se si trova un'informazione che non sembra corretta, o se non la si trova affatto, è possibile correggere o aggiungere con un singolo click, senza bisogno di alcun tipo di registrazione. È quello che abbiamo fatto nel momento in cui abbiamo verificato che il termine Social Software non è presente nella versione italiana; abbiamo quindi proposto la nostra traduzione a Wikipedia che è stata pubblicata ed immediatamente resa disponibile.

Da un punto di vista tecnico quindi un Wiki altro non è che un CMS nel quale il contenuto è costituito essenzialmente da una struttura di due elementi, il soggetto ed il testo e dove l’enfasi viene posta nella parte del Workflow e nel numero dei redattori che teoricamente (anche praticamente in certi casi, per esempio nelle intranet) può essere equivalente al numero dei lettori.

Il termine Wiki in hawaiano significa veloce ed è coniato da Cunningham, il padre dei Wiki, dopo la sua visita a Honolulu durante la quale il primo termine nella lingua locale che imparò fu Wiki-wiki [WIK06c].

Campi di applicazione

I Wiki possono essere utilizzati nei più vari campi, di seguito un elenco, che non vuole né può essere esaustivo, di alcuni degli utilizzi più diffusi.

Documentazione di software [ADO06a] .
Progetti collaborativi, come CPDL (la Choral Public Domain Library) [CHO06].
Enciclopedie, sia generali come Wikipedia o settoriali come Websemantique.org [Web06].
Wiki comunitarie, come WikiMedia Commons [WIK06d] o Wiki Ubuntu [WIK06e] o Melug [MEL06].
Wiki personali per piccoli gruppi di utenti oppure utilizzati impropriamente come normale CMS (quando un solo utente può inserire e modificare i contenuti) [STA06].

Caratteristiche principali

Uno degli aspetti fondamentali dei wiki è la facilità con cui le pagine possono essere create e modificate; di solito inoltre non vengono messe barriere preventive alla pubblicazione di informazioni tanto che, in molti casi, nemmeno la registrazione viene richiesta (Wikipedia per esempio).

I Wiki realizzano pienamente il concetto di ipertesto, con una struttura di navigazione non lineare dove ogni pagina (o pagina wiki) contiene un gran numero di link ad altre pagine; è possibile che in alcuni Wiki si affianchi una struttura gerarchica (specialmente in quelli con molte pagine), ma questa non è necessaria al fine della fruizione dei contenuti [WIK06a].

I link vengono creati utilizzando una particolare sintassi, la cosiddetta link pattern, una regola che il nome della pagina wiki deve seguire per poter essere linkata automaticamente da un’altra pagina wiki, e fra questi il più usato è il modello CamelCase che consiste nel mettere in maiuscolo la lettera iniziale di ogni parola contenuta in una frase ed eliminando gli spazi. Il nome CamelCase deriva dal fatto che le stringhe prodotte hanno solitamente due maiuscole (le gobbe del cammello, in inglese camel) [CAM06].

In realtà non esiste solo CamelCase, sono nati altri link pattern tutti comunque con lo scopo di rendere ogni pagina wiki immediatamente identificabile con una stringa e potere quindi collegare le diverse pagine fra di loro semplicemente inserendo il linkpattern all’interno del testo.

Data la loro natura aperta i wiki devono obbligatoriamente fornire strumenti di controllo per verificare la validità degli aggiornamenti ed il più importante di tutti è sicuramente la pagina delle ultime modifiche (recent changes) che può mostrare un numero specifico di modifiche come l’elenco delle stesse avvenute in un determinato lasso di tempo.

Altrettanto importante è lo strumento che mette a disposizione la cronologia delle revisioni che tiene traccia di tutte le modifiche che vengono fatte ad una pagina wiki e permette di recuperare versioni precedenti, o parti di esse, in caso di cancellazioni (volontarie o meno) o di manomissioni.

Esistono altri meccanismi che i diversi software Wiki mettono a disposizione per poter meglio controllare il flusso di creazione e pubblicazione delle pagine; non è però raro constatare come questi software con l’aumentare della loro complessità diventano virtualmente indistinguibili da un CMS di tipo tradizionale.

Esistono innumerevoli soluzioni Wiki già pronte, un elenco piuttosto completo si può trovare a questo indirizzoWikiEngines [WIK06f].

I Blog

Un altro esponente nella famiglia dei Social Software è il Blog, o Web Log, che ha dato vita ad uno dei fenomeni più sbalorditivi nella storia, breve ma intensa, del Web. Nei successivi capitoli analizzeremo le caratteristiche principali di un Blog fino a realizzare una piattaforma fra le più complete oggi esistenti; ora invece vorremmo soffermarci sul fenomeno in sé e sugli impatti che ha avuto.

Fino a tutto il 1997 con il termine Web Log ci si riferiva (e ci si può riferire tuttora) esclusivamente ai file di testo generati dai Web server e sui quali venivano registrati i dati sugli accessi alle pagine servite dai software in questione e che venivano salvati in ordine cronologico inverso. Verso la fine di quell’anno, però, Jorn Barger [BAR06] annunciò su alcuni newsgroup di volere iniziare a tenere un log pubblico delle sue navigazioni sul Web ed annotando commenti sui siti che avrebbe visitato; con non poca lungimiranza ma anche con una certa dose di presunzione affermò inoltre che questa nuova modalità di organizzazione alla quale diede il nome di Web Log, si sarebbe rivelata vincente [MAI04].

Nell’aprile del 1999 Peter Merholz, uno dei primi Weblogger (colui che cura un proprio Web Log), propose di pronunciare il termine in una nuova maniera, “wee-blog” e lo fece inserendo nella side-bar del suo sito la frase “per quello che può valere, ho deciso di pronunciare le parole Web Log come wee blog, o blog in breve” [DOV03].

Non ci volle molto tempo affinché il nuovo termine prendesse piede e quando nell’Agosto dello stesso anno Pyra Labs® (ora acquisita da Google®) rilasciò un software per permettere a chiunque di creare un Web Log ed a tale software diede il nome di Blogger si ebbe così la consacrazione definitiva del nuovo termine [BLO06a].

Ma se all’origine il termine indicava semplicemente una serie di annotazioni riguardanti siti visitati ben presto queste annotazioni si trasformarono in pensieri, commenti, articoli riguardanti ogni branca del pensiero ed i Blog si sono trasformati in una sorta di diari online.

Per meglio capire le dimensioni del fenomeno il migliore punto di partenza è sicuramente Technorati®, il motore di ricerca dedicato ai Blog che più di ogni altro è oggi in grado di fornire dati riguardo alle dimensioni raggiunte dalla cosiddetta Blogosfera [QUI01] costituita dall’insieme di tutti Blog e dei contributi dei loro lettori. In un recentissimo rapporto [SIF06] (datato 6 febbraio 2006) David Sifry, fondatore ed amministratore delegato di Technorati, fornisce alcune cifre impressionanti:

Technorati indicizza 27,2 milioni di Blog ed il periodo di raddoppio delle dimensioni della blogosfera è di 5,5 mesi (figura 1).
La blogosfera è 60 volte più grande rispetto a solo 3 anni fa.
Ogni giorno sono indicizzati 75.000 nuovi blog (figura 2).
13,7 milioni di bloggers continuano a scrivere sui loro blog tre mesi dopo la creazione
2,7 milioni di blogges aggiornano il loro blog con cadenza almeno settimanale
Un sofisticato sistema anti spam elimina circa il 10% dei nuovi blog in quanto risultano essere generati automaticamente per scopi di spam.

tesina blog e web

Figura 1 - Dimensioni della blogosfera indicizzata da Technorati [SIF06].

Figura 2 – Nuovi blog registrati da Technorati su base giornaliera [SIF06].

I dati sono sicuramente impressionanti e rendono l’idea delle dimensioni che il fenomeno ha raggiunto, ma vediamo di capire quali sono i motivi di tale successo.

Similmente al Wiki, anche il Blog, visto come un CMS, dà al contenuto una struttura semplice; il contenuto in questo caso viene chiamato post ed identifica articoli e o annotazioni in cui oltre al titolo ed al testo vero e proprio primaria importanza assume la data e l’ora nella quale questo viene pubblicato [MAI04].

In fondo un Blog è sempre e comunque scrittura e quindi non può sfuggire alle regole della comunicazione scritta, nemmeno quindi alla necessità di avere un lettore per potersi definire compiuto come processo comunicativo. Oltre a questo va considerato che quasi ogni post di un blog contiene riferimenti ad altri post di altri Web Log e comunque in ognuno è spesso presente un insieme di link diretti (blogroll) ad altri Web Log che l’autore reputa interessanti e/o pertinenti con il suo. Se quindi osserviamo la blogosfera dal punto di vista del lettore, che difficilmente legge un solo blog, è facile capire come in realtà ogni blog sia un nodo di un sistema di contenuti e da questo punto di vista l’appartenenza ai Social Software appare ovvia [MAI04].

Ma se è vero che, essendo scrittura, un blog si completa solo con la lettura e quindi con la cattura dell’attenzione del lettore ci si trova di fronte ad una problematica tipica di tutti i prodotti editoriali, digitali e non, che è quella di trovare pubblico che fruisca dei propri contenuti.

Dove il Blog risulta vincente nel catturare l’attenzione è nella modalità con cui, essendo un nodo di un sistema, permette di veicolare informazioni e contenuti il cui interesse è direttamente proporzionale al numero dei blog che ne riportano la presenza [BAL05].

Se un blogger legge un post interessante non esita a sua volta a segnalarlo ai suoi lettori e citandone fonte e link indirizza il visitatore fuori del suo sito. In un sistema competitivo un simile comportamento è suicida, nella Blogosfera [QUI01] invece si ripercuote in un vantaggio per tutti:

Vantaggio per l’autore del post perché riceve maggiore attenzione rispetto a quella che avrebbe solo dai lettori abituali.
Vantaggio per l’autore del post che cita un altro post perché ha fornito informazioni interessanti al suo lettore.
Vantaggio per il lettore perché vede crescere notevolmente le probabilità di trovare contenuti che lui ritiene interessanti.

La Blogosfera non ha centri ma milioni di relazioni che cambiano in ogni momento in base a quello che i blogger scrivono. Con il Web Log l’autore ha la possibilità di costruirsi una reputazione presso i propri lettori, tuttavia è probabile che questa reputazione sia solida quando si scrive di argomenti pertinenti con l’attività del blogger e lo sia molto meno quando invece scrive di altro.

“Si crea così un meccanismo simile a quello che Michael H. Goldhaber [GOL97] chiama Star System, esistono alcuni blog che sono punti di riferimento in determinati ambienti, divenendo cioè Star, mentre sono semplicemente fan in altri ambienti. E per le stesse regole di funzionamento del sistema non ci sono barriere o blocchi di nessun tipo, né privilegi o sconti. Solo la capacità di interessare i lettori determina la nostra posizione in un ambiente o in un altro, in base all’attenzione che riscuote ciò che scriviamo” [GRA03].

Tutto questo è possibile perché nei blog per la prima volta i contenuti sono stati raccolti per persona dando a quest’ultima la possibilità di far conoscere la propria individualità e facilitando quindi le relazioni fra soggetti.

Come afferma Paolo Valdemarin [VAL06], uno dei più noti blogger italiani, è spesso più facile conoscere a fondo un blogger che si legge tutti i giorni che un collega di lavoro.

Questo accade perché nei blog l’autore mette tutto sé stesso e ha modo di esprimersi con tutta la libertà che la scrittura gli consente. Col tempo quindi il blogger crea una traccia dei suoi pensieri e delle sue esternazioni e questa traccia diviene la rappresentazione della sua individualità sulla rete.

Il fatto che questa traccia sia pubblica sottopone l’autore al giudizio del pubblico e che tale giudizio può essere pubblico anch’esso (requisito fondamentale per un Blog è che i lettori possano lasciare commenti ai suoi post) permette di consolidare il senso di appartenenza ad una comunità dove il confronto costituisce la regola.

Concludiamo con una citazione di Peter Kaminsky [KAM02], fondatore di SocialText® [SOC06] (leader per soluzioni di tipo wiki per le grandi imprese) e guru per quanto riguarda il social software:

“Un blog è un’applicazione del social network e rappresenta al suo interno l’unità base del sistema: la persona” e aggiunge che “senza un blog, sei solo un lurker sulla rete”; i lurker sono le persone che leggono discussioni su newsgroup, chat, forum ed in generale su strumenti interattivi senza però parteciparvi attivamente.

I blog

Abbiamo finora parlato dei blog come fenomeno da un punto di vista più sociale che prettamente informatico; vediamo invece ora di capire nel dettaglio come è fatto un blog e quali sono le caratteristiche principali che un’applicazione deve soddisfare per poter essere considerata un blog. Introdurremo successivamente una veloce disamina dei principali servizi online e delle principali piattaforme oggi disponibili per aprire un blog.

Anatomia di un blog tradizionale sul Web

La struttura è uno degli elementi caratterizzanti dei blog; la grande parte dei Web Log si affida a piattaforme già disponibili e questo porta ad un’inevitabile standardizzazione delle caratteristiche tanto che alla fine esse stesse finiscono per diventare requisiti per identificare un blog.

Va sottolineato però come questa struttura sia strettamente legata al mezzo con il quale viene visualizzata; il mezzo d’elezione per consultare questi strumenti è oggi il Web e quindi il browser costituisce il mezzo con il quale visualizzare l’interfaccia dell’applicazione.

Utilizzando strumenti diversi per fruire dei contenuti di un blog porta ovviamente ad avere interfacce che possono anche essere sostanzialmente differenti (pensiamo alla consultazione via email od utilizzando un software di IM).

Per il momento concentriamoci sul Web e vediamo come la struttura dell’interfaccia utilizzando un browser sia relativamente semplice (figura 3); solitamente vi sono due macro aree, una centrale e preponderante nella quale sono visualizzati i contenuti inseriti dagli autori (post), l’altra laterale e più stretta nella quale invece sono inseriti il calendario (se presente), il motore di ricerca, le categorie e tutti i servizi accessori dei quali il blog è dotato.

tesina blog e web

Figura 3 – la struttura di un blog.

Quasi sempre è anche presente una testata con il logo del blog ed è questa che di solito identifica univocamente un blog; in questo caso non sono pochi quelli che, contravvenendo ad una buona regola del design di siti di contenuti, utilizzano testate di grandi dimensioni per meglio caratterizzare il proprio Web Log (un esempio lampante in questo caso è dato dal blog di Beppe Grillo [BEP06]) contando comunque sul fatto che lo sviluppo in verticale dei contenuti in un blog è sempre molto più esteso rispetto alla parte visualizzata sul browser.

Il post

Il post è il contenuto gestito dal Blog visto come CMS; possiede una struttura semplice composta di pochi elementi:

Titolo: contiene il titolo del post.
Descrizione: contiene il testo del post, questo può essere di lunghezza variabile e spesso può contenere oltre che a testo anche immagini e codice html per poterne utilizzare le caratteristiche possibilità di formattazione.
Id: codice che identifica univocamente il post.
Data di pubblicazione: di fondamentale importanza per un blog dove l’ordine cronologico e l’aggiornamento costituiscono due elementi chiave.
Categorie: contiene le categorie alle quali il post afferisce; si tratta di un aspetto che sta assumendo sempre maggior importanza in quanto l’utilizzo delle categorie è alla base del fenomeno della folksonomy che vedremo in seguito.

Il post, una volta pubblicato, è visualizzato nella parte centrale dell’interfaccia; data e ora di pubblicazione definiscono l’ordine con il quale i diversi post vengono visualizzati uno di seguito all’altro; l’importanza di questo aspetto deriva dalla percezione del blog come di un qualcosa che è aggiornato spesso e da consultare quindi frequentemente.

Ovviamente non tutti i post possono essere visualizzati nella homepage del nostro Web Log, solitamente vengono mostrati gli n post più recenti; per poter recuperare con facilità i vecchi post e per permettere ad altri bloggers ed altri siti di identificarli univocamente sono nati i permanent link, o permalink [PER06].

Si tratta di url con una struttura del tipo:

http:// indirizzoblog / anno / mese / giorno / titolo del post

che permette di raggiungere direttamente il post e di visualizzarlo anche se questo non è più in home page.

Le categorie

La possibilità di creare delle categorie e di assegnarle ai vari post è una delle caratteristiche più importanti di un blog; permette, infatti, di catalogare i post anche per argomento oltre che per data e rende quindi molto più semplice ai lettori l’individuazione dei post più interessanti.

Oltre alla possibilità di definire le categorie è sempre presente nella parte laterale un elenco delle stesse (e spesso viene indicato al loro fianco il numero di post relativo alla categoria stessa), tale elenco è costituito da un insieme di link che permette di visualizzare per ogni categoria i post relativi.

La possibilità di assegnare un post ad una categoria (tagging), ma più in generale assegnare parole chiave a qualche tipo di dato, unita all’esistenza di milioni di blog e di motori di ricerca loro dedicati ha dato vita al fenomeno della Folksonomy.

Si tratta di un termine coniato nel 2004 da Thomas Vander Wal combinando le parole folk (dall’inglese arcaico folc che significa gente) e taxonomy (tassonomia); in italiano si potrebbe tradurre tassonomia popolare ed indica essenzialmente la classificazione per parole chiave (tag) [VAN06].

Tale fenomeno è alla base del successo di siti quali Flickr [FLI06] (dove gli utenti possono inserire le proprie foto ed assegnare tag ad ognuna di esse) o Del.icio.us [DEL06] (dove gli utenti in questo caso assegnano parole chiave ai siti che preferiscono dando vita ad una sorta di segnalibro globale) e di Technorati stesso.

Per ogni blog che supporta le categorie è possibile segnalare a Technorati non solo l’esistenza di un post per poterlo indicizzare, ma anche e soprattutto a quali categorie appartiene dando così vita ad un nuovo modo di ricercare post fra i milioni presenti [TAG06].

Sono così nate le tag clouds (figura 4) che interpretano da un punto di vista visivo i tag utilizzati all’interno di un determinato insieme di contenuti (un solo blog come tutta la blogosfera nel caso di Technorati) e li visualizzano con dimensioni diverse a seconda della rilevanza che essi hanno rispetto ai contenuti stessi.

tesina blog e web

Figura 4 – Tag cloud delle 11.28 del 08/02/2006 di Technorati [TAG06].

Nella figura vediamo come i tag più utilizzati nei post inseriti nell’ultima ora del giorno indicato abbiano dimensioni differenti; a tag più grandi e visibili corrisponde un numero maggiore di post; l’attualità nel caso specifico è ben presente in quanto è possibile verificare come in quella data all’ordine del giorno ci fossero le proteste degli islamici contro la pubblicazione di vignette satiriche su Maometto da parte di giornali danesi. Si nota chiaramente come il tag più evidente di tutti sia Islam e come sia presente il tag Denmark che solitamente non compare nella tag-cloud principale di Technorati.

Il calendario

Fino a non molto tempo fa quasi tutti i blog erano dotati di un piccolo calendario nella parte laterale nel quale i giorni nei quali erano stati fatti dei post erano dei link che permettevano di portare direttamente alla visualizzazione dei post di quel giorno.

Oggi l’utilizzo del calendario è molto meno diffuso che in passato in quanto il suo utilizzo come strumento di ricerca dei post ha perso di significato rispetto, per esempio, alla navigazione per categorie o tramite un normale motore di ricerca interno, e si è rilevato alla fine essere solo un mero indicatore della frequenza di aggiornamento di un sito.

I commenti

I commenti sono il primo sistema di feedback implementato dai Blog. Ogni lettore di un post ha la possibilità, se lo desidera, di lasciare un commento all’autore per dire la sua sull’argomento del post. Spesso poi l’autore utilizza egli stesso i commenti per rispondere al lettore e nascono così discussioni anche complesse.

In fondo ad ogni post è sempre indicato il numero dei commenti che ha ricevuto ed inoltre, per facilitare la discussione ed evitare che un lettore debba per forza visitare il blog per verificare se l’autore ha risposto, è possibile richiedere di ricevere via email tutti i commenti di un post.

La possibilità di inserire commenti ha invero generato un fastidioso fenomeno di spam in quanto esistono sistemi automatici che si occupano di generare commenti che contengono link pubblicitari di ogni tipo. Per ovviare al problema quasi tutti i software per i blog permettono di moderare i commenti, questo permette all’autore di pubblicare solo quelli pertinenti.

Questa soluzione però se da un lato evita la pubblicazione di informazioni non volute non riesce comunque ad impedire la compilazione automatica dei form per l’inserimento dei commenti.

E’ quindi previsto un ulteriore livello di difesa, fornito dalle cosiddette immagini Captcha (acronimo di “completely automated public Turing test to tell computers and humans apart” per indicare un sistema per verificare che o meno su l’utente sia un essere umano) [CAP05], che prevede l’inserimento da parte dell’utente di una stringa alfanumerica presente all’interno di un’immagine generata dinamicamente dall’applicazione (figura 5).

tesina blog e web

Figura 5 – Inserimento di un commento con un'immagine di tipo Captcha.

Nonostante esistano tentativi di forzare la lettura di queste immagini da parte di queste procedure automatiche al momento la difesa fornita dalle Captcha Images è reale, anche se viene pagata al prezzo di rendere l’inserimento dei commenti non accessibile ai sensi delle regole sull’accessibilità dei siti Web.

I trackback

L’utilizzo dei commenti non si è però rilevato pratico in alcuni casi in quanto non è affatto raro che un lettore di un blog sia a sua volta un blogger e preferisca commentare un post di un altro autore direttamente scrivendo un articolo sul suo blog invece che lasciare un commento nel sito originario.

Gli svantaggi di un approccio di questo tipo sono l’ovvia frammentazione delle informazioni che si ha in questo caso in quanto un argomento potenzialmente interessante per un lettore finisce per essere spezzettato fra più blog senza nessun tipo di legame fra loro.

Potrebbe essere sempre possibile inserire link manuali ai post dai quali si prende spunto (ed è quello che era fatto in realtà, ma il meccanismo dei trackback [TRA02] implementato oramai nella maggior parte delle piattaforme esistenti permette di risolvere questa tipologia di problemi.

Il meccanismo è relativamente semplice, tutti i blog che supportano questo sistema sono in grado di accettare ‘risposte’ ai propri post, ai quali forniscono un identificativo unico chiamato URL di trackback, provenienti da blog esterni.

Un utente che voglia citare nel proprio blog un post presente su un blog diverso indicherà che il proprio post è legato al trackback URL del post del blog esterno.

Il risultato dell’utilizzo di questo particolare url è avvisare il blog originale che la discussione continua su un Web Log diverso e questo permette ai lettori, che sono visivamente informati della presenza di trackback ai propri post, di seguire il filo della discussione, anche se questa si dipana fra Web Log differenti.

Gli archivi

Presenti nei blog fin dall’inizio, sono un elenco di link, uno per ogni mese in cui il blogger ha pubblicato almeno un posto, che permettono di visualizzare tutti i post effettuati nell’arco del mese sul quale si è cliccato.

Il Blogroll

Ogni blog permette di gestire una serie di link a risorse esterne; quando questi link fanno riferimento a Blog che l’autore legge si parla di blogroll.

L’utilità del blogroll è quella di rendere espliciti i legami sociali esistenti tra i Weblogger in quanto si presuppone che i Web Log presenti nell’elenco siano consultati molto frequentemente dall’autore.

Syndication RSS/ATOM

Uno dei problemi più grandi che si trova davanti un utente che segue tanti blog è la perdita di tempo che implica il cambiare indirizzo, il doversi abituare ad interfacce sempre diverse (pur tutte con la stessa struttura) ed il non potere poi raggruppare per aree di interesse post di blog differenti.

Per risolvere questi problemi sono nati i cosiddetti blog aggregator, software che sfruttano le possibilità di distribuzione dei contenuti, o syndication, offerte dai blog per prelevarne i contenuti e permettere di raggrupparli attraverso un’interfaccia coerente.

Tali possibilità si concretizzano nel supporto di due fra i più diffusi formati di distribuzione dei contenuti sul Web, Real Simple Syndication (RSS) [RSS02] e ATOM [ATO05], entrambi dialetti XML [XML06] ed il cui formato vedremo nel dettaglio in seguito.

Ogni blog mette a disposizione un indirizzo ad un documento (feed), generalmente un file XML [XML06] in uno dei formati precedenti, che contiene i propri post e, eventualmente, i loro commenti e qualsiasi programma in grado di leggere documenti in questi formati può essere utilizzato per consultare i contenuti del Web Log bypassando quindi completamente l’interfaccia Web.

Il numero di interfacce quindi con le quali è possibile visualizzare post di un blog è virtualmente enorme, sono tantissimi gli strumenti oggi disponibili per visualizzare ed aggregare feed diversi; si va dai servizi online (uno su tutti, Google Reader [GOO96]) a software freeware ed ognuno prevede una modalità di visualizzazione differente.

Da non trascurare poi il vantaggio che l’utilizzo di questi software può dare grazie alla possibilità di consultare i contenuti off-line.

Superare il Web

Grazie alle possibilità offerte dalla syndication è effettivamente possibile accedere ai contenuti di un blog utilizzando interfacce e device diversi dal Web e dai computer; pensiamo ai telefonini con il loro display inadatto ad ospitare il formato dei siti Web tradizionali come ai palmari.

È però possibile spingersi oltre e tentare di rendere i contenuti di un blog accessibili da strumenti quali i software di IM e le email.

Già oggi molti blog prevedono la possibilità di sottoscrivere una forma di abbonamento in modo da ricevere via mail un avviso ad ogni aggiornamento; la nostra idea è però quella di rendere il blog completamente fruibile utilizzando uno scambio di mail, o di SMS o di messaggi in un IM.

L’utilità di un software quale Google Talk [TAL05] (l’IM che supporteremo nella nostra piattaforma) diventa evidente se pensiamo a funzionalità che possiamo attivare per il nostro blog ed impossibili utilizzando un’interfaccia Web di tipo tradizionale:

Possibilità per l’autore di essere avvisato in tempo reale se un nuovo commento è inserito da un lettore.
Possibilità per l’autore di inserire, modificare e cancellare i propri post utilizzando esclusivamente l’interfaccia testuale del programma di IM.
Possibilità per il lettore di consultare il blog direttamente con il programma di IM.
Possibilità per il lettore di essere avvisato in tempo reale di una risposta ad un suo commento o dell’arrivo di un nuovo post.

Anche la possibilità di interagire con il proprio Blog utilizzando appositi client di tipo desktop (quindi applicazioni desktop a tutti gli effetti) permette è un plus che alcune piattaforme di blog permettono, esiste una serie di API [API06] standard (o che perlomeno dovrebbero esserlo) che analizzeremo in seguito e che permettono ad applicazioni desktop di interagire con i blog che le supportano.

Nell’applicazione che realizzeremo questo aspetto assumerà particolare rilevanza in quanto uno dei nostri obiettivi sarà proprio quello di rendere il nostro blog aggiornabile dal maggior numero possibile di applicazioni e/o device differenti.

Le soluzioni

Elencare tutte le soluzioni oggi disponibili per chi vuole aprire un blog è semplicemente impossibile, tanto ampia e vasta è la scelta da questo punto di vista. Ci limiteremo quindi ad alcuni servizi e piattaforme fra i più rappresentativi, in particolare ci concentreremo su Wordpress [WOR06], applicazione oggi annoverata fra le migliori nell’ambito del blog publishing.

Soluzioni online

In questo ambito annoveriamo tutti quei servizi online che permettono l’apertura e la manutenzione di un blog senza la necessità di nessuna ulteriore operazione da parte dell’utente.

Vi sono sia servizi a pagamento che gratuiti che sono in grado di soddisfare tutte le esigenze per l’utente che vuole entrare nel mondo dei blog.

Elenchiamo velocemente i principali di questi servizi:

Blogger [BLO06b]: lo abbiamo già citato, è il più famoso ed il più grande dei servizi di questo tipo, è stato acquistato da Google e fa ora parte del network dei servizi forniti dal grande portale; dalla sua ha una notevole facilità d’uso (a parte la necessità di nozioni di CSS [CSS99] se si vuole personalizzare l’interfaccia); da notare che bloggers ora utilizza esclusivamente feed di tipo ATOM [ATO05].
MSN Spaces [MSN06a]: un servizio abbastanza semplice, ha il vantaggio di integrarsi direttamente con il software di IM di Microsoft, MSN Messenger.
Anche Virgilio [VIR06], Fiscali TIS06], Excite [EXC06] e Libero [LIB06] forniscono ognuno un servizio di questo tipo, le caratteristiche sono più o meno similil (maggiore la possibilità di personalizzazione offerta da Virgilio).
Splinder [SPL06]: uno dei più completi servizi online e prevede oltre all’apertura gratuita anche livelli di servizio più sofisticato, e senza pubblicità, a pagamento. Probabilmente uno dei posti migliori per il neofita che desidera aprire un blog grazie anche all’ottima guida all’uso fornita.
LiveJournal: [LIV06]: una delle più longeve e più grandi comunità di Blogger online, oltre 9 milioni di blog registrati; la traduzione approssimata in italiano e l’aspetto spartano però non depongono a favore di LiveJournal come scelta primaria per cominciare a muovere i primi passi nel mondo del Web.
TypePad [TYP06]: servizio esclusivamente a pagamento ma fra i più completi, offre una serie completa di strumenti ed è probabilmente una delle migliori scelte per chi vuole aprire un blog.

Piattaforme fai-da-te

I vantaggi dei servizi sopra citati sono tanti, comodità, semplicità e rapidità di registrazione; ma se un utente vuole qualcosa di più personalizzabile e desidera il pieno controllo del blog allora non rimane che affidarsi ad una piattaforma blog da installare sul suo server oppure, in alternativa, creare la propria soluzione come abbiamo deciso di fare noi.

Fra le applicazioni al momento disponibili le migliori sono sicuramente:

WordPress [WOR06]: realizzato in PHP [PHP06], una tecnologia di scripting lato server che permette di realizzare applicazioni Web, è sicuramente tra i più diffusi ed apprezzati software per la realizzazione di blog; funzionalmente completo e semplice da personalizzare è probabilmente la scelta migliore per chi conosce già PHP [PHP06] e vuole aprire un blog; da non molto tempo è offerto anche un servizio online all’indirizzo.
Movable Type [MOV06]: soluzione realizzata in Perl, è una delle più vecchie applicazioni di questo tipo; disponibile sia in versione gratuita (senza pubblicità) che a pagamento offre una serie completa di funzionalità, però l’installazione non è delle più agevoli e richiede comunque una discreta competenza.

Esistono poi innumerevoli altre applicazioni per realizzare blog, non esiste tecnologia lato server che non preveda almeno un paio di applicazioni di questo tipo e non è raro trovare soluzioni ad hoc realizzate ed utilizzate per un singolo blog; in fin dei conti realizzare un’applicazione per fare Web Log semplici e senza particolari funzionalità non è particolarmente complesso.

Le tecnologie utilizzate

Introduzione

In questo capitolo saranno prima individuati gli obiettivi che ci siamo prefissati per la realizzazione della nostra piattaforma Blog e successivamente introdurremo le tecnologie utilizzate e discuteremo brevemente le scelte che hanno portato all’utilizzo delle stesse.

Gli obiettivi

Il principale obiettivo che abbiamo voluto raggiungere nella realizzazione della nostra piattaforma è la possibilità di accedere ai contenuti del blog, sia dal punto di vista del lettore che da quello dell’amministratore, con il maggior numero possibile di strumenti quali l’email, l’Instant Messaging (IM) [IME06] e client desktop, un software di tipo tradizionale che permette di effettuare operazioni sul blog offline e di connettersi solo in un secondo momento ad Internet per l’aggiornamento.

Un sistema di IM o messaggistica istantanea è un sistema di comunicazione client-server (in alcuni casi peer-to-peer) che consente di scambiare in tempo reale, fra utenti di due computer connessi in rete, frasi e brevi testi.

La tempestività dell’aggiornamento di un Web Log è, infatti, uno degli elementi che ne determinano il successo e la possibilità di aggiornare il proprio Blog utilizzando sistemi differenti dal browser (l’email, per esempio, è accessibile anche da qualsiasi cellulare) costituisce sicuramente un vantaggio da questo punto di vista.

Elenchiamo brevemente gli altri obiettivi che ci siamo posti:

Realizzare un’applicazione che possa coniugare semplicità d’uso e potenziamento della fruibilità di un blog.
Realizzare una struttura flessibile e facilmente espandibile.
Realizzare un’interfaccia Web aderente agli standard.
Rendere compatibile l’applicazione con le API delle piattaforme blog più diffuse quali Blogger® [BLO06b] e/o Movable Type® [MOV06]. Per API, acronimo di Application Program(ming) Interface, si intende un insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito [API06].
Rendere la più vasta possibile la scelta a disposizione degli utenti su quale strumento di storage dei dati utilizzare (perciò oltre ai DataBase relazionali la possibilità di utilizzare documenti XML su filesystem).
Realizzare un’applicazione che permetta un’effettiva implementazione del supporto multi linguaggio per gestire idiomi di qualsiasi tipo.
Realizzare un’applicazione multi piattaforma in grado di girare sui principali sistemi operativi, in questo caso sistemi Windows® [WIN06], Linux® [LIN06] e MAC OSx® [MAC06a].

Le scelte

Le scelte da noi fatte sono state per alcuni versi obbligate dal desiderio di realizzare una piattaforma quanto il più possibile aderente agli standard più recenti (in particolar modo per la parte di presentazione dei dati) e per altri invece dalla naturale predisposizione di alcune tecnologie all’utilizzo nella realizzazione di applicazioni Web.

Quale tecnologia lato server utilizzare è sicuramente la decisione più impegnativa di tutte in quanto le alternative sono molteplici. Vanno perciò valutati approfonditamente vantaggi e svantaggi di ognuna di queste ovviamente tenendo sempre ben presenti quali sono gli obiettivi che ci vogliamo prefiggere nella realizzazione della nostra applicazione:

La disamina seguirà uno schema diviso per sezioni per raggruppare i tre principali aspetti che si devono affrontare nella realizzazione di un’applicazione Web:

Tecnologia lato server utilizzata.
Modalità per la memorizzazione (o storage) dei dati.
Modalità di presentazione dei dati.

Tecnologia lato server

Per tecnologia lato server intendiamo una soluzione, detta Application Server, che, installata su di un computer insieme ad un Web Server, permetta di superare le limitazioni di quest’ultimo per quanto riguarda la possibilità di distribuire esclusivamente contenuti di tipo statico e di realizzare quindi il concetto di applicazione Web.

Un Application Server tipicamente permette ad uno sviluppatore di creare applicazioni Web utilizzando comuni linguaggi di programmazione. Fornisce anche una serie di servizi oltre alle capacità intrinseche del linguaggio, come la possibilità di usare modelli predefiniti (template), un modello coerente per la sicurezza, la persistenza dei dati, le sessioni e altre funzionalità.

La scelta da questo punto di vista è stata relativamente semplice nonostante le possibili alternative fossero innumerevoli. Scartate a priori soluzioni come ASP.NET [ASP06], un insieme di tecnologie di sviluppo di software per il Web commercializzate dalla Microsoft, in quanto non rispondeva al requisito dell’essere multi piattaforma e Ruby, in quanto tecnologia relativamente giovane e con ancora uno scarso numero di risorse online rimanevano comunque a disposizione un discreto numero di tecnologie che avrebbero potuto fare al caso nostro:

PHP [PHP06].
Python [PYT06].
Perl [PER06].
Java (tipicamente servelt e Jsp) [JAV06].
Coldfusion [COL06].

Diciamo subito che la scelta è caduta sull’ultima in elenco; Coldfusion [COL06] è una tecnologia di Adobe® [ADO06b] che consiste in un application server ed in un insieme di servizi già pronti e di uso comune nel mondo delle applicazioni Web.

Dal punto di vista degli obiettivi che ci eravamo prefissi Java [JAV06], Python [PYT06], Perl [PER06] e PHP [PHP06] (in ordine decrescente) soffrivano di una certa complessità; per ognuna di queste tecnologie realizzare cose anche semplici come spedire una mail comporta comunque il dovere eseguire operazioni aggiuntive (come l’installazione di componenti su di un server o scrivere un maggior numero di righe di codice) rispetto a quanto offerto nativamente da Coldfusion [COL06].

D’altro canto Java [JAV06] e PHP [PHP06] avevano (ed hanno) un vantaggio notevole dato dalla loro elevatissima diffusione e dalla presenza di un enorme numero di sviluppatori che formano community eterogenee ed indubbiamente forniscono un ottima risorsa cui attingere in caso di difficoltà.

La scelta migliore potrebbe sembrare PHP [PHP06], in quanto soddisfa gran parte dei requisiti richiesti e rispetto a Java [JAV06] presenta una maggiore semplicità nell’utilizzo, e lo sarebbe sicuramente stata se il nostro obiettivo non fosse stato realizzare un’applicazione da zero ma cercare di migliorare e/o modificare applicazioni già esistenti in quanto esiste un buon numero di piattaforme Blog molto valide realizzate in PHP [PHP06].

Ma la nostra scelta è stata quella di realizzare un software completamente nuovo e l’unica soluzione lato server che soddisfaceva i requisiti richiesti e che avrebbe permesso di raggiungere gli obiettivi che ci eravamo prefissati in tempi relativamente brevi è Coldfusion [COL06].

Coldfusion

Si tratta di una soluzione che mette a disposizione un application server corredato da una serie di strumenti e da un linguaggio il coldfusion markup language (CFML) [CFM06] che invece non è proprietario, finalizzati alla realizzazione di applicazioni Web.

Esistono sul mercato diverse soluzioni che permettono di eseguire applicazioni realizzate in cfml e che permettono di abbassare drasticamente, fino ad azzerarlo in alcuni casi, il costo della piattaforma. Il nostro obiettivo è quello di realizzare una piattaforma che possa girare su tutti gli engine sul mercato che sono compatibili con Coldfusion [COL06] ed in particolare:

Adobe Coldfusion MX® [COL06].
New Atlanta BlueDragon® [BLU06].
Railo® [RAI06].

Il primo è il prodotto di riferimento; è Adobe® [ADO06] (che recentemente ha acquisito Macromedia® [MAC06b] che produceva, fra le altre cose, Coldfusion [COL06]) che decide come il linguaggio evolve nelle successive release e sono gli altri engine che poi si adeguano nel tempo alle nuove specifiche.

Vediamo ora nel dettaglio quali sono gli aspetti principali di Coldfusion [COL06] che giustificano la nostra scelta.

Coldfusion e Java

Coldfusion [COL06] è basato su Java [JAV06], fondamentalmente è semplicemente un compilatore che trasforma script realizzati con il linguaggio proprietario in applicazioni Java [JAV06] a tutti gli effetti. Questo permette di avere tutti i vantaggi che Java [JAV06] mette a disposizione senza però per questo doverne adottare la complessità.

La compatibilità con gli application server J2EE [J2E06] è totale ed è perciò possibile far girare Coldfusion [COL06] sia su prodotti commerciali e blasonati quali IBM Websphere® [IBM06] e BEA Weblogic® [BEA06] che su prodotti opensource come TomCat [TOM06] o Jetty [JET06].

Il linguaggio

Il linguaggio di scripting utilizzato da Coldfusion [COL06] è il CFML e, similmente all’HyperText Markup Language (HTML) [HTM06], è un linguaggio a marcatori. Il CFML si basa su tag (figura 6) che rappresentano le istruzioni che Coldfusion [COL06] interpreta lato server per generare pagine dinamiche; è un vero e proprio linguaggio di programmazione la cui sintassi richiama palesemente quella dell'HTML [HTM06].

Questo aspetto è il principale responsabile della semplicità e della potenza di Coldfusion [COL06], pochi tag sono in grado di svolgere compiti che con altre soluzioni richiederebbero una maggiore quantità di codice con ovvie conseguenze sull’affidabilità di quanto prodotto.

Un tag CFML è sempre preceduto dal prefisso CF e può necessitare di un tag di chiusura o meno, nel secondo caso comunque è possibile utilizzare il simbolo ‘/’ per rendere il codice generato XML [XML04] compatibile.

Come nell'HTML [HTM06], alcuni tag possiedono degli attributi, che possono essere obbligatori o opzionali; Coldfusion [COL06] possiede oltre 80 differenti tag, ognuno dei quali ha un ruolo ben preciso ed il cui nome è auto esplicativo, per cui, ad esempio, <CFMAIL> viene utilizzato per inviare e-mail, <CFIF> si occupa di definire i processi condizionali, <CFOUTPUT> si occuperà della visualizzazione, <CFQUERY> dell'interrogazione al database.

Per quanto riguarda la produzione di codice HTML o XHTML [XHT02] per la presentazione dei dati Coldfusion [COL06] si rivela il candidato ideale in quanto è possibile mischiare marcatori dei linguaggi sopra citati insieme a quelli in CFML e questo permette di realizzare in maniera rapida interfacce Web anche complesse.

tesina blog e web

Figura 6 – Il linguaggio cfml [BEL03]

Il CFML è case insensitive, significa che non è sensibile alle maiuscole o alle minuscole. Scrivere il nome di una funzione, di una variabile o di un tag in maiuscolo o minuscolo è la stessa cosa ai fini della programmazione. La sintassi, inoltre, non è in genere suscettibile agli spazi né alle andate a capo che possiamo introdurre tranquillamente nel codice per rendere più semplice e ordinata la lettura.

Supporto dei Componenti

La possibilità di realizzare componenti (detti Coldfusion Components o CFC) che sfruttano concetti propri della programmazione orientata agli oggetti (OOP, Object Oriented Programming) [OOP95] quali l’ereditarietà permette di realizzare applicazioni anche sofisticate basate su design-pattern, modelli per risolvere problemi ricorrenti e comuni di disegno del software ObjectOriented, collaudati ed universalmente accettati nell’ambito della programmazione Web quali Model View Control (MVC) [MVC02], pattern che si occupa di separare il più possibile tra loro le parti dell'applicazione adibite al controllo, all'accesso ai dati e alla presentazione, ed al quale ci siamo ispirati nella realizzazione della nostra applicazione e che abbiamo scelto in quanto permette di separare in maniera elegante la logica delle applicazioni dalla loro presentazione.

Funzionalità native XML

XML è un formato di testo derivato da Standard Generalized Markup Language (SGML) [SGM04], un linguaggio a marcatori nato negli anni ’60, il cui ruolo nello scambio di dati fra piattaforme eterogenee, non solo su Internet, è oggigiorno fondamentale.

Documenti XML [XML04] sono costituiti da entità, che contengono marcatori e dati; i marcatori codificano la struttura dei dati; tale struttura non è definita a priori, ma può essere sottoposta a vincoli utilizzando sistemi quali Document Type Definition (DTD) [DTD06] e XML Schema [SCH00].

Xml fu sviluppato da XML Working Group costituito dal World Wide Web Consortium (W3C) nel 1996 e gli obiettivi che il gruppo di lavoro voleva perseguire nella definizione di XML [XML04] sono:

XML dovrebbe essere semplice da utilizzare direttamente su Internet.
XML dovrebbe essere utilizzabile da una varietà di applicazioni.
XML dovrebbe essere compatibile con SGML [SGM04].
Dovrebbe essere relativamente semplice costruire applicazioni in grado di processare documenti XML.
Il numero di caratteristiche opzionali definite in XML dovrebbe essere il più basso possibile, tendenzialmente uguale a zero.
I documenti XML dovrebbero essere leggibili dagli esseri umani e ragionevolmente chiari.
Dovrebbe essere possibile progettare in XML in maniera rapida.
Il progetto di XML doveva essere il più formale e conciso possibile.
I documenti XML dovrebbero poter essere realizzati facilmente.
La concisione nella definizione dei marcatori non è richiesta.

Affinché i dati XML siano utili, la loro struttura deve essere definita, ossia tutti gli elementi e gli attributi usati in un particolare tipo di documento XML devono essere ufficialmente impostati; in caso contrario i dispositivi che accedono alle informazioni non sapranno come interpretare quegli elementi. I due modi più noti per definire la struttura di un documento sono il ricorso ai DTD [DTD06] e agli Schema XML [SCH00].

Il DTD è un’applicazione di un sistema di convalida SGML [SGM04], ne esiste uno per ogni versione di HTML [HTM06] ed in origine l’intento era che il riferimento ai DTD dovesse essere effettuato direttamente da parte del browser, sotto forma di documenti leggibili da parte della macchina.

Tuttavia nessun produttore di browser ha seguito questo percorso, preferendo la soluzione di prefissare direttamente nel browser le informazioni sul modo di interpretare ogni elemento definito in qualunque DTD HTML. Questo è il motivo per cui i browser più datati presentano seri problemi con le versioni più recenti di HTML [HTM06].

Non possiedono i tag nuovi codificati nel programma né nessun altro modo per fare riferimento il DTD vero e proprio.

I DTD presentano alcuni limiti: per esempio sono molto complicati da scrivere ed ogni elemento ha determinate dipendenze. Il funzionamento degli elementi dipende dall’ordine in cui appaiono nel DTD. I DTD sono utili per la convalida dei nomi di elementi ed attributi e per il controllo della molteplicità (quante volte un elemento può apparire).

Tuttavia non possono essere impiegati per effettuare una convalida avanzata, come una verifica di intervallo o di tipo, e non supportano i namespace che sono pure parte integrante dei linguaggi basati su XML.

L’altro modo per definire la struttura di un documento XML è l’XML Schema [SCH00], un tipo di descrizione di documento che presenta diversi vantaggi rispetto a DTD.

Sono infatti essi stessi dei documenti XML e pertanto condividono molte delle caratteristiche dei linguaggi XML che definiscono e soprattutto sono estensibili [PRO01].

La possibilità di manipolare XML [XML04] in maniera semplice e lineare è una delle caratteristiche fondamentali per la nostra applicazione; la possibilità per l’utente di poter scegliere se salvare i propri post su Database o su XML implica la necessità per la nostra applicazione di poter gestire indifferentemente entrambe le tipologie di dati. Il CFML ci viene in questo caso notevolmente in aiuto in entrambi i casi, vediamo, infatti, come con queste poche righe di codice:

Testo mio doc

Questo è il figlio <cfoutput>#contatore#</cfoutput>

</nodoFiglio>

</cfloop>

</MioDoc>

</cfxml>

Sia possibile definire una struttura dati nativa in Coldfusion [COL06] che rappresenta il seguente documento XML:

Testo mio doc

</MioDoc>

Tale documento può essere manipolato in modo semplice utilizzando funzioni native che permettono di effettuare ricerche utilizzando Xml PATH Language (XPATH) [XPA99], un linguaggio dedicato alla definizione ed al recupero di parti di documenti XML, e di effettuare trasformazioni utilizzando eXtensible Stylesheet Language (XSL) [XSL99], un linguaggio dedicato alla trasformazione di documenti XML in documenti XML.

Supporto XMPP

Extensible Messaging and Presence Protocol (XMPP) [XMP04] è un protocollo basato su XML per l’Instant Messaging. Google Talk® [TAL06] è il servizio più popolare che si basa su di esso.

Coldfusion [COL06] mette a disposizione nativamente strumenti per interagire direttamente con account che utilizzano questo protocollo e permette quindi di realizzare applicazioni che utilizzano interfacce di tipo IM.

Supporto SMPP

Short Message Peer-to-Peer protocol (SMPP) [SMP99] è un protocollo per lo scambio di messaggi di testo di tipo Short Message Service (SMS). Coldfusion [COL06] supporta questo protocollo e permette quindi di realizzare applicazioni che utilizzano SMS come strumento di interazione.

Motore di indicizzazione integrato

Coldfusion [COL06] integra al suo interno il motore di indicizzazione dei documenti di Verity® [VER06]; tale strumento permette di effettuare ricerche all’interno di documenti non strutturati come file HTML [HTM06] o XML [XML04], a documenti di Office [OFF06] e file PDF [PDF06].

Nel nostro caso utilizzeremo proprio questa funzionalità per poter ricercare informazioni all’interno dei nostri post.

Generazione automatica documenti PDF

Funzionalità chiave dell’ultima versione di Coldfusion [COL06], è possibile tramite un unico tag fornire output in PDF [PDF06] partendo da un preesistente documento HTML [HTM06].

Dato un file di tipo html, per esempio documento.html, per ottenere la renderizzazione in PDF [PDF06] dello stesso è sufficiente scrivere:

</cfdocument>

Storage

Per quanto riguarda la scelta del sistema con cui memorizzare i dati del blog, dai post ai commenti ai log, abbiamo volutamente cercato di renderla il più ampia possibile cercando quindi di utilizzare un linguaggio SQL [KUL02] standard nel caso di utilizzo di database relazionali, per la maggiore compatibilità possibile con diversi database relazionali, e di utilizzare documenti in formato Extensible Markup Language (XML) [XML04] salvati su filesystem come alternativa ai database.

XML

Nell’ambito della nostra applicazione non faremo uso di DTD [DTD06] né di XML Schema [SCH00] per definire la struttura dei documenti XML [XML04] che conterranno i nostri dati; tale scelta dipende esclusivamente dalla voluta semplicità delle strutture dati richieste.

Uno dei nostri obiettivi era quello di dare la massima libertà di scelta da parte dell’utente su quale sistema di Storage utilizzare e la possibilità di utilizzare documenti XML salvati sul filesystem presenta diversi vantaggi rispetto alla scelta di utilizzare un database di tipo relazionale:

Semplicità di installazione: la nostra applicazione può essere installata semplicemente copiandola nella cartella di destinazione. L’utilizzo di XML come tipologia di storage predefinita permette infatti di evitare setup e configurazione di un database.
Indicizzazione del contenuto: l’utilizzo di file XML permette di indicizzare i post utilizzando il motore di ricerca di Verity® [VER06] incluso in Coldfusion [COL06].
Portabilità: trasportare l’applicazione da una piattaforma ad un’altra (per esempio da Windows [WIN06] a Linux [LIN06]) si trasforma in una semplice copia di una cartella da un sistema ad un altro.

Gli svantaggi sono invece dovuti alla maggiore pesantezza dell’applicazione se la mole di dati del nostro blog diviene significativa in quanto operazioni su un numero elevato di file del filesystem (nella nostra applicazione per ogni post viene creato un file contenente il documento XML) dal punto di vista delle prestazioni sono penalizzanti rispetto ad operazioni fatte su tabelle in un database di tipo relazionale.

Un esempio di documento XML da noi utilizzato per memorizzare i post del blog è il seguente:

<?xml version="1.0" encoding="UTF-8"?>

<author>Andrea Veggiani</author>

<email>andrea@dinamica.it</email>

<title>Titolo</title>

<description>Descrizione</description>

</blogentry>

Database

L’utilizzo di un database per memorizzare i dati di un'applicazione Web dinamica è oggi la scelta più comune e non si poteva prescindere dal rendere disponibile questa possibilità all’utente all’interno della nostra piattaforma.

Utilizzare un Database di tipo relazionale implica realizzare interrogazioni allo stesso utilizzando il linguaggio SQL [KUL02], promosso dall’ANSI (American National Standards Institute) e da ISO (International Standards Organization), del quale sono state rilasciate diverse versioni dando origine a quello che viene definito ANSI-SQL [KUL02].

Purtroppo però al giorno d’oggi esistono diverse implementazioni del linguaggio SQL, prima di tutto dovute alla volontà dei produttori di differenziare i loro software.

Infatti ad oggi i principali Database non supportano solo ANSI-SQL [KUL02] ma anche una serie di funzionalità aggiuntive che hanno il pregio di aggiungere potenza al prodotto, ma il grosso difetto di limitare fortemente la portabilità dei prodotti che utilizzano queste estensioni proprietarie.

La nostra scelta è stata quella di utilizzare esclusivamente ANSI-SQL [KUL02] nelle nostre interrogazioni allo scopo di rendere completamente portabile la nostra piattaforma su qualunque database.

I vantaggi di una simile scelta sono ovvi in quanto la nostra soluzione è virtualmente adattabile senza modifiche a qualsiasi Database; per contro alcune operazioni che in alcuni dialetti SQL possono essere eseguite con un’unica interrogazione utilizzando ANSI SQL [KUL02] richiedono diverse interrogazioni.

Modalità di presentazione dei dati

Per presentazione dei dati si intendono le modalità con le quali l’applicazione fornisce output all’utente; uno dei nostri obiettivi era quello di realizzare interfacce multiple e rendere quindi il nostro blog fruibile da mezzi diversi dal Web perciò la parte di presentazione dei dati nel nostro progetto ricopre un’importanza fondamentale.

UTF-8

Prima di entrare nel dettaglio delle tecnologie utilizzate per la parte di presentazione occorre specificare la scelta di utilizzare UTF-8 (Unicode Transformation Format ad 8 bit) [UTF05].

Unicode assegna un numero univoco a ogni carattere, indipendentemente dalla piattaforma, indipendentemente dall'applicazione, indipendentemente dalla lingua [UNI05].

L'adozione di Unicode sui siti Web e nelle applicazioni client/server o multi-tiered, rispetto all'utilizzo dei set di caratteri tradizionali, permette un significativo abbattimento dei costi di gestione. Unicode consente che un'unica versione di un software o di un sito Web siano fruibili con piattaforme, lingue e paesi diversi, evitando la necessità di reingenierizzare il prodotto per ogni situazione specifica. Permette, inoltre, il trasporto del testo fra sistemi diversi senza che abbia luogo alcuna corruzione dei dati [UNI05].

UTF-8 è una codifica dei caratteri Unicode in sequenze di lunghezza variabile di byte (da uno a quattro) ed è quella più diffusa.

In UTF-8 è sia il codice della nostra applicazione che i dati da essa gestiti; questo ci permette di gestire in maniera concreta diverse lingue (comprese quelle con caratteri non latini); a scopo di esempio l’applicazione viene fornita anche con il linguaggio turco.

Interfaccia Web tradizionale

Per quanto riguarda l’interfaccia utente della nostra applicazione in ambito Web abbiamo optato per l’utilizzo di Extensible HyperText Markup Language (XHTML [XHT02]) [XHT02] e Cascading Style Sheets (CSS) [CSS99] in quanto, al momento, riteniamo meglio coniughino le esigenze di un codice prodotto aderente agli standard alla flessibilità necessaria per un’applicazione di questo tipo.

L’utilizzo di CSS [CSS99] per mantenere le informazioni sulla visualizzazione e formattazione dei contenuti ci permetterà di realizzare in maniera estremamente semplice un meccanismo di skin che permetterà di variare l’aspetto del nostro Blog semplicemente variando il file CSS [CSS99] che è utilizzato per renderizzare il contenuto a video; a scopo dimostrativo sono forniti già alcuni skin di default.

XHTML

XHTML [XHT02] è una famiglia di tipologie di documento ed essenzialmente definisce riformulazioni di HTML [HTM06] versione 4 come applicazioni di XML.

Se quindi XHTML [XHT02] è essenzialmente HTML 4.01 definito in XML vediamo quali sono i requisiti fondamentali che un documento XHTML [XHT02] deve soddisfare:

Deve essere validato rispetto ad una delle tre DTD [DTD06] approvate per la famiglia XHTML [XHT02].
L'elemento radice del documento deve essere <html>; L’elemento radice è il nodo principale della struttura ad albero di XML e deve essere presente un’unica radice per ogni documento; tutti gli altri elementi contenuti saranno nodi figli della radice.
L'elemento radice del documento deve indicare lo spazio dei nomi di XHTML [XHT02] usando l'attributo xmlns. Lo spazio dei nomi è la collezione dei nomi degli elementi e degli attributi utilizzati in un linguaggio a marcatori basato su XML, nel nostro caso il nodo radice sarà:

All'interno del documento vi deve essere una dichiarazione di DOCTYPE prima dell'elemento radice. L'identificatore pubblico incluso nella dichiarazione di DOCTYPE si deve riferire ad una delle tre :

<!DOCTYPE html

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"DTD/XHTML 1-strict.dtd">

Quest DOCTYPE non è retro compatibile e non permette l’uso di tag deprecati. Sono obbligatoriamente necessari i CSS [CSS99] per una formattazione che vada oltre le impostazioni predefinite dei Browser.

<!DOCTYPE html

PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"DTD/XHTML [XHT02]1-transitional.dtd">

Questo DOCTYPE è invece retro compatibile e permette l’uso di TAG ed attributi deprecati; l’ideale per una maggiore compatibilità della propria applicazione con browser meno recenti (o meno aderenti agli standard). Per la nostra applicazione utilizzeremo questo tipo di document type.

<!DOCTYPE html

PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"

"DTD/XHTML 1-frameset.dtd">

È necessario se si utilizzando dei Frameset; fra l’altro l’utilizzo dei frame risulta comunque essere deprecato ed è ipotizzabile che scompaia del tutto con il passare del tempo [HTM02].

I vantaggi nell’utilizzare XHTML [XHT02] rispetto a HTML nella realizzazione di pagine Web sono essenzialmente due:

Gli sviluppatori di documenti e i disegnatori di user agent sono costantemente alla scoperta di modi nuovi per esprimere le loro idee attraverso nuovi marcatori. In XML [XML04] è relativamente semplice introdurre nuovi elementi o aggiungere attributi agli elementi. La famiglia XHTML [XHT02] è stata concepita per accogliere queste estensioni attraverso moduli e tecniche per lo sviluppo di nuovi moduli conformi a d esso (descritti nella futura specifica di modularizzazione di XHTML [XHT02]). Questi moduli permetteranno la combinazione di insiemi di caratteristiche nuove ed esistenti durante la creazione del contenuto così come il disegno di nuovi user agent.
Costantemente sono prodotte nuove forme di accesso ad Internet diverse dal computer. La famiglia XHTML [XHT02] è stata concepita tenendo conto della interoperabilità con gli user agent generali. Attraverso un nuovo user agent e un nuovo meccanismo di specifica del documento, i server, i proxies e gli user agent potranno realizzare una migliore trasformazione del contenuto. In ultimo, sarà possibile sviluppare contenuto conforme a XHTML [XHT02] che sia utilizzabile da tutti gli user agent conformi ad esso [HTM02].

HTML 4.01 ha introdotto l’attributo id, che sostituisce l’ormai deprecato attributo name e XHTML [XHT02], che non dimentichiamo è XML [XML04], fa un passo oltre e richiede che, nel caso in venga utilizzato l’attributo id (facoltativo), esso sia univoco.

Questo significa che due diversi elementi in documento XHTML [XHT02] non possono avere lo stesso valore di id. Vi sono ragioni pratiche che hanno portato a questo e sono essenzialmente legate agli aspetti che vedono documenti XHTML [XHT02] o parti di essi elaborati e/o memorizzati all’interno di Database XML.

Nel nostro caso utilizzeremo l’attributo id in maniera estensiva principalmente per poter definire stili CSS [CSS99] per descrivere le modalità di presentazione dei contenuti presenti all’interno degli elementi con l’attributo valorizzato.

La nostra applicazione all’interno dei normali browser restituirà documenti XHTML [XHT02] 1.0 di questo tipo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/XHTML 1/DTD/XHTML 1-transitional.dtd">

<head>

... elementi header …

</head>

<body>

... visualizzazione dei post …

</div>

… area laterale …

</div>

… piè di pagina …

</div>

</body>

</html>

CSS

HTML [HTM06] fu creato per essere un linguaggio di marcatura semantica: in altri termini esso riguardava il significato del contenuto in un documento, non la sua rappresentazione visiva; tuttavia, man mano che la popolarità del Web è cresciuta, questo tipo di linguaggio è stato percepito come un limite. Si desiderava ottenere un controllo maggiore sull’aspetto dei propri documenti Web rispetto a quello ottenibile con HTML.

Questa richiesta, unita al fatto che HTML [HTM06] fornisce comunque elementi base di formattazione, ha portato alla realizzazione di un gran numero di pagine e siti che mescolano in maniera approssimativa, inelegante e formalmente scorretta parti di contenuto e di presentazione ed in generale generano tre tipologie principali di problemi:

Il primo problema è costituito dalla lunghezza di questi tag. Se confrontata con una pagina che adotta il linguaggio CSS [CSS99], una pagina che non lo adotta è in genere molto più pesante in termini di dimensioni. Inoltre le istruzioni CSS possono essere raccolte in un file esterno che rimane memorizzato nella cache del browser, riducendo ulteriormente la quantità di dati che i server devono trasmettere.
Il secondo problema risiede nella mancanza di logica del codice (X)HTML. Un codice non aderente agli standard, ridondante e confuso comporta infatti lavoro aggiuntivo per i browser (user agent), che devono cercare di correggere ed interpretare (quando possibile) direttive arbitrarie.
Il terzo problema comincia a diventare sempre più rilevante ed è la mancanza di compatibilità con nuovi device quali computer palmari e smartphone. Pagine non realizzate con i CSS [CSS99] sono di solito progettate per schermi con risoluzione minima 800x600 pixel. I palmari, che hanno una risoluzione inferiore ed una forma dello schermo ben diversa dal rapporto 4:3 dei monitor per computer, si trovano quindi impossibilitati a visualizzare correttamente la pagina.

Il modo migliore per fornire agli autori un controllo completo sull’aspetto del documento, mantenendo contemporaneamente la separazione contenuto/presentazione, si ottiene quindi mediante i CSS. Esistono attualmente tre versioni di CSS per i browser Web:

CSS1: Nel 1996 il W3C [W3C06] emanò le specifiche CSS1 [CS199]. La base di questoe specifiche consiste nel fatto che il contenuto sarebbe stato sempre definito dal codice (X)HTML, mentre la formattazione sarebbe stata demandata ad un codice completamente separato, il CSS appunto. I richiami tra i due codici venivano effettuati tramite due particolari attributi: class e ID. Queste specifiche forniscono un'efficace soluzione al primo problema in quanto permettono di ridurre notevolmente le dimensioni della pagine.

Risolvono il secondo problema in modo parziale perché consentono al codice (X)HTML di ritornare in gran parte semplice ed essenziale, ma presentano qualche lacuna che costringe a ricorrere in alcuni casi ai tag HTML per definire alcune formattazioni. Non è nemmeno in considerazione il terzo problema che all’epoca non era evidente quanto oggi.

CSS2: Nel 1998 il W3C [W3C06] emanò le specifiche CSS2 e nel 2004 le specifiche CSS2.1. [CS205] che costituiscono la naturale evoluzione dei CSS1 ed offrono funzionalità finalizzate alla soluzione del terzo problema implementando la possibilità di creare fogli di stile separati per ciascun dispositivo e risolvono definitivamente
CSS3 [CS305]: Le specifiche sono ancora in fase di definizione e la loro caratteristica principale sarà costituita dalla modularizazzione dei CSS, un po’ sulla falsariga di quanto avvenuto con il passaggio di XHTML [XHT02] dalla versione 1.0 alla 1.1.

Accessibilità

Uno dei vantaggi più importanti nella scelta di XHTML [XHT02] e CSS [CSS99] per la parte di presentazione della nostra applicazione è sicuramente quello di poter realizzare layout (skin) del nostro blog che soddisfano le linee guida dell’accessibilità definite dal W3C [W3C06] nel 1999; le Web Content Accessibility Guidelines 1.0 (WCAG 1.0) [WCA99].

Per accessibilità di un sito Web intendiamo la possibilità che questo sia fruibile da tutte le categorie di utenti, compresi quindi portatori di handicap che non sarebbero in grado di fruire dei contenuti di un sito realizzato senza seguire queste linee guida.

È in fase di studio la versione 2.0 della guida, al momento in cui scriviamo l’ultima versione del documento è del 3 novembre 2005, che, però non risulta ancora essere stata approvata; noi ci limiteremo a realizzare una skin che permetta al nostro blog di soddisfare i 14 requisiti definiti nella WCAG 1.0 – A [WCA99].

Seguendo queste linee guida, gli sviluppatori di contenuti devono essere in grado di creare pagine che si trasformano e rimangono accessibili nonostante una qualsiasi delle limitazioni dovute all’utilizzo di strumenti atti a permettere la fruizione dei siti anche a persone con disabilità fisiche, sensoriali e dell'apprendimento, oppure a limitazioni causate dal lavoro e barriere tecnologiche. I principi chiave per la progettazione di pagine che si trasformano sono:

Separare la struttura dalla presentazione.
Fornire testo (compresi gli equivalenti testuali ad immagini e/o suoni). Il testo può essere riprodotto secondo modalità disponibili a quasi tutti i dispositivi di browsing e accessibili a quasi tutti gli utenti.
Creare documenti funzionanti nonostante l'utente non possa vedere e/o sentire. Fornire informazioni che abbiano lo stesso obiettivo o funzione di audio e video in maniera che sia adatta anche a canali sensoriali alternativi. Questo non vuol dire creare una versione audio pre registrata dell'intero sito per renderlo accessibile a utenti non vedenti. Utenti non vedenti possono utilizzare le tecnologie dei lettori di schermi per riprodurre per intero l'informazione testuale presente in una pagina.
Creare documenti che non si basino su uno specifico hardware. Le pagine dovrebbero essere utilizzabili senza mouse, con piccoli schermi, con schermi a bassa risoluzione, in bianco e nero, senza schermo, solo con output di voce oppure di testo, ecc.

Le linee guida 1-11 si occupano principalmente di ciò che riguarda la trasformazione delle pagine.

Gli sviluppatori di contenuti dovrebbero rendere il contenuto comprensibile e navigabile. Questo comprende, oltre all'adozione di un linguaggio chiaro e semplice, il fornire meccanismi facilmente comprensibili per la navigazione all'interno della stessa pagina e tra pagine diverse.

Dotare le pagine di strumenti di navigazione e informazioni di orientamento ne massimizza l'accessibilità e l'utilizzabilità. Non tutti gli utenti sono in grado di utilizzare indicazioni visive come immagini sensibili, barre di scorrimento proporzionali, frame affiancati, o comunque elementi grafici che guidano gli utenti vedenti dei normali browser grafici.

Gli utenti possono inoltre perdere informazioni relative al contesto qualora possano vedere solo una parte della pagina, ad esempio perché accedono alla pagina una parola per volta (sintesi vocale o display braille), oppure una sezione alla volta (schermi assai piccoli oppure ingranditi molte volte).

Senza informazioni che favoriscano l'orientamento, tabelle di grandi dimensioni, elenchi, menu, ecc. possono non essere comprensibili da parte di alcune categorie di utenti.

Le linee guida 12-14 si occupano in particolar modo dei principi per rendere il contenuto navigabile e comprensibile. Ogni linea guida presenta una lista di definizioni, detti punti di controllo, che spiegano in che modo la specifica linea guida è applicabile in tipici scenari di sviluppo dei contenuti e per ogni punto di controllo viene specificata la priorità:

Priorità 1: Lo sviluppatore di contenuti Web deve conformarsi al presente punto di controllo. In caso contrario, a una o più categorie di utenti viene precluso l'accesso alle informazioni presenti nel documento. La conformità a questo punto di controllo costituisce un requisito base affinché alcune categorie di utenti siano in grado di utilizzare documenti Web [WCA99].
Priorità 2: Lo sviluppatore di contenuti Web dovrebbe conformarsi a questo punto di controllo. In caso contrario per una o più categorie di utenti risulterà difficile accedere alle informazioni nel documento. La conformità a questo punto consente di rimuovere barriere significative per l'accesso a documenti Web [WCA99].
Priorità 3: Lo sviluppatore di contenuti Web può tenere in considerazione questo punto di controllo. In caso contrario, una o più categorie di utenti sarà in qualche modo ostacolata nell'accedere alle informazioni presenti nel documento. La conformità a questo punto migliora l'accesso ai documenti Web [WCA99].

La priorità di alcuni punti di controllo può variare al verificarsi di alcune condizioni (che vengono precisate); il soddisfacimento di alcuni o tutti dei requisiti indicati dai punti di controllo porta alla definizione di diversi livelli di conformità del nostro documento:

Livello di Conformità "A": conforme a tutti i punti di controllo di Priorità 1.
Livello di Conformità "Doppia-A": conforme a tutti i punti di controllo di Priorità 1 e 2.
Livello di Conformità "Tripla-A": conforme a tutti i punti di controllo di Priorità 1, 2 e 3.

I Livelli di conformità sono indicati in modalità testuale in modo da poter essere comprensibili anche se espressi attraverso sintesi vocale [WCA99].

Oltre il Web

Instant Messaging e XMPP

Un’applicazione Blog ad una di IM a prima vista potrebbero non avere nulla in comune; in realtà riteniamo che la caratteristica peculiare del secondo, che è la comunicazione in tempo reale, potrebbe risultare molto utile per completare i servizi che un Blog offre ma anche per costruire un modo diverso di interrogare e visualizzare i post.

Esistono molte piattaforme di IM [IME06], quasi tutti i grandi portali generalisti offrono la loro soluzione proprietaria, e spesso sono incompatibili fra di loro pur condividendo le medesime funzionalità e modalità di utilizzo.

Nel 1999 la Jabber Software Foundation [JAB06] sviluppò un protocollo, basato su XML, chiamato Extensible Messaging and Presence Protocol (XMPP) [XMP04] per gestire IM e più in generale forme di comunicazione in tempo reale.

Nel 2002 la stessa fondazione propose XMPP [XMPP04] come standard ed iniziò quindi il lavoro di formalizzazione che portò nell’ottobre del 2004 all’approvazione da parte dell’Internet Engineering Task Force (IETF) [IET06] del protocollo tramite il rilascio di due Request for Comment (RFC) [PRO04]:

RFC 3920: Extensible Messaging and Presence Protocol (XMPP) - Core: Il nucleo della tecnologia basata su XML e che comprende il supporto all’internazionalizzazione e della sicurezza [RFC04a].
RFC 3921: Extensible Messaging and Presence Protocol (XMPP) - Instant Messaging and Presence: Descrive le funzioni di base di IM quali, per esempio, la contact list e la gestione delle subscriptions [RFC04b].

Il 24 agosto del 2005 Google® [GOO06] rilascia il proprio software di IM [IME06] e sceglie proprio XMPP [XMP04] come protocollo per gestire la propria piattaforma; si tratta ovviamente del grande salto effettuato da questa tecnologia che da standard approvato ma relegato ad una nicchia di software open source da parte delle altre grandi piattaforme di IM diviene finalmente parte integrante dell’offerta di Google.

L’architettura di IM [IME06] basata su XMPP [XMP04] è molto simile al più usato (e testato) sistema di messaggistica esistente: l’email; ci sono importanti differente ma il pensare a Jabber come ad una ‘email istantanea’ non è molto lontano dalla realtà.

Vediamo con un esempio di chiarire il funzionamento della piattaforma e per farlo scomodiamo Romeo e Giulietta nella famosa scenda del balcone.

Giulietta non manda un messaggio direttamente a Romeo (sarebbe una comunicazione peer to peer), Giulietta possiede un account su un server che supporta IM con tecnologia XMPP (server Jabber), ha un suo identificatore univoco (JID) che assomiglia molto ad un indirizzo email. Poiché Giulietta appartiene alla famiglia dei Capuleti ha registrato il suo JID come giulietta@capuleti.com. Similmente Romeo avrà un suo JID del tipo romeo@montecchi.com.

Appena Giulietta esegue un log in sul server capuleti.com è in grado di inviare messaggi al suo amato; per essere più precisi accade nel momento in cui Giulietta esegue il suo client IM sul suo laptop mentre è sul balcone.

A questo punto Giulietta invia un messaggio a romeo@montecchi.cm; il messaggio viene a questo punto preso in consegna dal server capuleti.com che a sua volta apre una connessione al server montecchi.com (sempre che non sia già stata aperta).

Ipotizzando che i parenti delle due famiglie non abbiano disabilitato la connessione fra i server delle due famiglie il messaggio di Giulietta viene indirizzato al server XMPP [XMP04] di montecchi.com.

Tale server verifica che il messaggio è stato indirizzato ad un account di nome Romeo e lo dirige al client aperto in quel momento da Romeo che con il suo palmare sul quale è in esecuzione Google Talk aperto attende sotto al balcone.

Finalmente il messaggio appare sullo schermo del dispositivo di Romeo che appena lo legge sospira (Figura 7).

La figura è semplice e familiare in quanto può benissimo rappresentare anche l’architettura della posta elettronica; sia le comunicazioni via email che tramite XMPP [XMP04] sono possibili grazie ad una rete distribuita di server che utilizza un protocollo comune. Clienti specifici si connettono ai server per ricevere messaggi da altri utenti e per spedirne ad altri sullo stesso server o ogni altro server connesso alla rete.

tesina blog e web

Figura 7 – comunicazione fra romeo e giuletta via XMPP [XMP04]

La differenza principale fra l’email ed i server Jabber però sta nel fatto che questi ultimi consegnano i messaggi praticamente in tempo reale. Questo tipo di consegna è possibile in quanto i server nel network Jabber sanno quando un utente è online come lo sanno i contatti registrati da ciascun utente. Il sapere la disponibilità o meno di un utente è chiamata ‘presenza’ e costituisce la chiave che permette l’istantaneità della consegna dei messaggi.

La tecnologia di Jabber combina le caratteristiche classiche di un sistema di IM con tre importanti caratteristiche:

Utilizza un set di protocolli standard, aperti e documentati.
Tali protocolli sono XML [XML04].
Gli utenti possiedono un JID basato su DNS e schemi URI riconosciuti in maniera simile alle email (user@host).

Jabber utilizza una tecnologia di tipo client-server, non di tipo peer-to-peer come invece altri sistemi di IM fanno (Skype [SKY06] per esempio). Questo implica che tutti i dati scambiati fra due utenti passano attraverso almeno un server Jabber [JAB06] (in realtà i clienti possono negoziare ed ottenere una connessione diretta, per esempio per effettuare uno scambio di files, ma questo può essere fatto sempre e comunque previa negoziazione con il server).

Nonostante nulla vieti che messaggi XMPP [XMP04] viaggino attraverso qualsiasi porta TCP, solitamente server e client utilizzano un socket sulla porta TCP 5222 (per le comunicazioni server-to-server invece viene utilizzata la porta 5269) [TCP06].

Questa connessione è sempre attiva per tutta la durata della sessione del client con il server e questo implica che il client può fare a meno di richiedere messaggi al server come invece occorre fare periodicamente con le email.

Quando il server riceve un messaggio a noi indirizzato questo viene immediatamente spedito al nostro client se siamo connessi; se non lo siamo invece il server si occupa (se opportunamente configurato) di memorizzare i messaggi che riceviamo per poterceli consegnare non appena effettuiamo la connessione.

Grazie al fatto che queste tecnologie utilizzano protocolli aperti chiunque può implementarle all’interno delle proprie applicazioni e questo ha portato alla realizzazione di un notevole numero di applicazioni Jabber (sia server che client) sia commerciali che open source.

Nel momento in cui un client si connette ad un server, apre uno stream XML dal client al server ed il server a sua volta risponde con uno stream XML verso il client; perciò ogni sessione implica la creazione di due stream XML.

Ogni comunicazione avviene utilizzando questi stream nella forma di piccoli elementi di XML (stanza) come, per esempio, il seguente messaggio da Giulietta a Romeo:

<messagefrom='giulietta@capuleti.com'

to='romeo@montecchi.com'>

<body>Oh Romeo, Romeo, sei tu Romeo?</body>

</message>

Se nella maggior parte di casi questi Jabber stanza sono così semplici, il formato XML [XML04] può comunque essere esteso utilizzando XML namespaces e namespaces customizzati per applicazioni particolari. Questa peculiarità rende Jabber [JAB06] una potente piattaforma per il trasferimento di ogni tipo di dato strutturato come chiamate di tipo SOAP [SOA03] XML-RPC [JAB04], syndication via RSS [RSS02] o grafica vettoriale.

Uno dei criteri di progettazione della piattaforma Jabber includeva la possibilità di realizzare client semplici da scrivere (semplici, per esempio, come una connessione telnet) e per questo l’architettura della piattaforma impone poche restrizioni ai client; le uniche cose che questi devono fare:

Comunicare con il server utilizzando socket TCP [TCP06].
Effettuare parsing ed interpretare ‘stanze’ XML passate attraverso stream XML.
Gestire i data type base di Jabber: message; presence e iq.

L’obiettivo in Jabber è quello di spostare complessità dal client al server; da qui la relativa facilità con cui è possibile scrivere client (come dimostra l’ampia varietà di soluzioni oggi presente) e la possibilità di aggiungere funzionalità senza dover necessariamente aggiornare il client.

In pratica molte delle funzioni di basso livello del client sono gestite dalle Jabber Client Library permettendo agli sviluppatori di concentrarsi sull’aspetto dell’interfaccia utente.

All’interno del network di server Jabber [JAB06] sono coinvolte differenti ‘entità’ che devono comunicare una con l’altra; queste entità possono essere server, gateway, stanze di utenti o singoli utenti ed ognuna di essere deve essere identificata da un id univoco (JID) che deve possedere le seguenti caratteristiche:

Devono essere facili da ricordare per gli utenti.
Flessibili per poter essere inserite in altre piattaforme IM [IME06].
Ogni JID contiene una serie di elementi quali un dominio, il nodo e la risorsa definiti nel seguente formato: [nodo@]dominio[/risorsa].

Il dominio è l’identificativo primario; rappresenta il server Jabber [JAB06] al quale l’entità si connette; è obbligatorio e da solo rappresenta comunque un JID valido.

Il nodo è un identificativo secondario e rappresenta l’utente; tutti i nodi vivono all’interno di uno specifico dominio.

La risorsa è un terzo identificativo, opzionale, ed afferisce ad un nodo. Permette di identificare singole risorse che si riferiscono al medesimo nodo. Le risorse permettono al singolo utente di mantenere diverse connessioni simultanee allo stesso server Jabber, un esempio potrebbero essere i seguenti JID:

giulietta@capuleti.com/balcone.
giulietta@capuleti.com/camera.

La semplicità con cui è possibile realizzare client è sicuramente alla base della scelta di Adobe di inserire all’interno di Coldfusion [COL06] un gateway per permette di connettersi a server Jabber e di realizzare applicazioni interattive che utilizzano il sistema di IM come interfaccia.

Nel nostro caso alcune funzionalità che abbiamo realizzato e che permettono di ampliare le potenzialità dello strumento sono:

Utilizzo di un alert via IM al ricevimento di commenti o trackback da parte dei lettori; questo permette all’autore di essere avvisato in tempo reale (se è connesso ad un server Jabber) e di rispondere tempestivamente riducendo i tempi nell’interazione fra blogger e lettore
Utilizzo di una completa interfaccia testuale per visualizzare i contenuti del Blog.
Realizzazione di un sistema di login e di gestione dei post riservato ai blogger che permette di inserire e cancellare post da qualsiasi clienti Jabber in tempo reale.

Client Desktop e XML-RPC

Uno dei nostri obiettivi è quello di realizzare una piattaforma che possa essere fruibile dal maggior numero possibile di interfacce e modalità differenti. Esiste una categoria di software client che gira su desktop, e ve ne sono per tutte le piattaforme, che permette di interagire con i propri blog e per farlo utilizzano sia API proprietarie che API aperte e documentate (anche se non esistono standard formalizzati da W3C [W3C06] in questo senso). Tutte queste API [API06] però hanno il minimo comune denominatore nell’utilizzo di XML Remote Procedure Calling (XML-RPC) [XML99] per le comunicazioni client-server.

XML-RPC è costituito da una serie di specifiche e da implementazioni che permettono a sotware che girano su differenti piattaforme di effettuare chiamate remote attraverso Internet.

Un messaggio XML-RPC [XML99] è una chiamata HTTP di tipo POST ed il contenuto della stessa è in XML; una procedura viene quindi eseguita sul server chiamato e la risposta viene fornita in XML [XML04].

I parametri passati alla procedura possono essere numeri, stringe, date ma anche tipi di dati complessi come array e strutture, vediamo un esempio di chiamata:

Header

POST /RPC2 HTTP/1.0

User-Agent: Frontier/5.1.2 (WinNT)

Host: betty.userland.com

Content-Type: text/xml

Content-length: 181

Richiesta

<?xml version="1.0"?>

<methodName>examples.getStateName</methodName>

<param>

</param>

</params>

</methodCall>

Per quanto riguarda l’header della chiamata:

User-Agent ed Host devono essere specificati.
Content-type è text/xml.
Content-Length deve essere specificato e deve essere corretto.

Per quanto riguarda il formato dell’XML [XML04] al quale, intendendo la singola struttura di <methdocall>, ci si può riferire con il termine payload esso deve contenere un nodo <methodName> che contiene il nome del metodo che vogliamo chiamare.

Se la procedura chiamata richiede dei parametri allora <methodCall> deve contenere un nodo <params>; questo può contenere qualsiasi numero di sottonodi <param> ognuno dei quali avrà all’interno un <value> nel quale definire la tipologia ed il valore del parametro passato.

I valori di tipo scalare ammessi sono riassunti in tabella 1.

Tag	Tipo	Esempio
<i4> or <int>	intero	-12
<boolean>	0 (false) o 1 (true)	1
<string>	stringa	hello world
<double>	float	-12.214
<dateTime.iso8601>	data in formato iso8601	19980717T14:08:55
<base64>	binario in base 64	eW91IGNhbid0IHJlYWQgdGhpcyE=

Tabella 1 – Tipologie dati trattate da XML-RPC [JAB04].

Se il tipo non è definito di default viene passato come stringa, nel caso invece di valori complessi è possibile passare strutture ed array:

<struct>: Una struttura contiene <member> ed ogni <member> una coppia di <name> e <value>, per esempio:

<name>lowerBound</name>

</member>

<name>upperBound</name>

</member>

</struct>

Le strutture possono essere ricorsive ed ogni <value> può contenere ogni altra tipologia di dati supportata, compresi gli array.

<array>: Un array coniente un singolo elemento <data> che contiene un numero variabile di <value>, per esempio:

<array>

<data>

<value><string>Egypt</string></value>

</data>

</array>

Anche in questo caso gli elementi di un array sono riscorsivi ed oltre ad altri array possono contenere ogni altra tipologia di dati supportata.

Vediamo ora invece un esempio di risposta:

Header

HTTP/1.1 200 OK

Connection: close

Content-Length: 158

Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:08 GMT

Server: UserLand Frontier/5.1.2-WinNT

XML

<?xml version="1.0"?>

<param>

<value><string>South Dakota</string></value>

</param>

</params>

</methodResponse>

Per quanto riguarda la risposta alla chiamata, a meno di errori nella procedura questa deve essere sempre di tipo 200 OK. Per quanto riguarda l’header il Content-Type è text/xml ed il Content-Length deve essere presente e corretto.

Il corpo della risposta è un documento XML [XML04] che contiene <methodResponse> come radice e che a sua volta contiene un singolo nodo <param> all’interno del quale nel nodo <value> viene passato il valore creato dalla procedura <methodResponse> può anche contenere un nodo <fault> che contiene una struttura nella quale vengono indicati il codice ed il valore di un eventuale errore ritornato dalla procedura.

<?xml version="1.0"?>

<fault>

<value>

<name>faultCode</name>

</member>

<name>faultString</name>

<value>

<string>Too many parameters.</string>

</value>

</member>

</struct>

</value>

</fault>

</methodResponse>

XML-RPC [XML99] è semplice e di facile utilizzo ed ha avuto un’ampia diffusione in quanto risulta sufficiente per molti usi senza dover ricorrere a tecnologie che forniscono più garanzie in termini di affidabilità e sicurezza (come SOAP [SOA03]) al prezzo di una maggiore complessità. È, infatti, su XML-RPC che sono costruite le principali API [API06] esistenti che permettono di utilizzare i client desktop citati in precedenza e le pià diffuse sono:

Blogger API (anche se il servizio Blogger ora fornisce solo API Atom) [BLO03].
MetaWebLog API [MET02].
LiveJournal API [LIV06].
MovableType API [MOV02].

Abbiamo deciso di rendere compatibile la nostra piattaforma Blog con l’ultima API in elenco, quella di Movable Type, grazie ad alcuni vantaggi evidenti nei confronti delle altre:

Estende sia Blogger API che MetaWebLog API.
Dispone di una documentazione più strutturata e completa rispetto alle altre in elenco.
Tutti i client desktop disponibili permettono di interagire con piattaforme blog che utilizzano queste API.

La possibilità di utilizzare XML-RPC [XML99] non ha solo reso la nostra piattaforma in grado di dialogare con i software di cui sopra, ma anche di interagire con un numero di servizi online che sfruttano XML-RPC come strumento di comunicazione (come Flickr [FLI06] per le foto e Ping-O-Matic [PIN06] per i servizi di ping).

Email

La possibilità di aggiornare il proprio blog tramite un semplice invio di un’email può a prima vista sembrare una funzionalità di scarso interesse; ma se pensiamo a come sia possibile inviare email direttamente da dispositivi mobili quali i telefoni cellulari diventa immediatamente percepibile come questo sia il metodo più veloce per poter effettuare del mo-Blogging, abbreviazione di mobile Blogging, e poter quindi aggiornare il proprio Web Log in qualunque momento e da qualsiasi posto senza bisogno di utilizzare un computer.

La possibilità tramite Coldfusion [COL06] di spedire mail tramite il tag <cfmail> e di scaricare email da un account di posta elettronica con il tag <cfpop> ci ha permesso di realizzare un meccanismo per l’inserimento di post utilizzando semplici messaggi di posta elettronica in cui l’oggetto deve però essere formattato in questo modo: parola chiave @ nome utente @ password @ oggetto del post

Il testo della mail costituirà invece la descrizione del nostro post; eventuali allegati sono gestiti e visualizzati alla fine del testo se immagini, visualizzati come link per il download se invece si tratta di altre tipologie di files.

RSS

Esistono tipologie di documenti, spesso XML, definiti feed, che sono utilizzati per rendere disponibili ad applicazioni e piattaforme esterne i contenuti di un sito, nel nostro caso di un Blog.

Il formato più diffuso è sicuramente il Really Simple Syndication (rss, anche se vedremo che sotto questa sigla in realtà si nascondano diverse versioni ed anche come non ci sia accordo sul significato dell’acronimo; noi abbiamo optato per Really Simple Syndication ma c’è chi preferisce Rdf Site Summary e chi invece Rich Site Summary.

RSS nasce nel marzo 1999 in casa Netscape®, per gestire in modo automatico la pubblicazione delle notizie provenienti da fonti diverse sul portale MyNetscape [MYN06] e per favorire la personalizzazione della pagina da parte degli utenti, i tecnici del gruppo America OnLine® [AOL06], che in precedenza aveva rilevato Netscape®, ricorrono ad una personalizzazione di Resource Description Framework (RDF) [RDF04], un’insieme di specifiche XML studiate per favorire l’interoperabilità tra applicazioni Web e realizzano RSS 0.90 [PIL02]. Questa versione risultò fin troppo complessa e fu realizzata allora la versione 0.91 che fu poi acquistata da UserLand in quanto nel frattempo Netscape aveva perso interesse per il mercato dei portali.

Nel frattempo un terzo attore, un’organizzazione no profit di nome RSS-DEV Working Group, entra in scena e progetta un nuovo formato basato sui principi guida che avevano portato alla realizzazione della versione 0.99 (e che erano stati secondo loro parzialmente disattesi con la versione 0.91) [MAI04]. Il nuovo formato, basato nuovamente su RDF viene chiamato RSS 1.0 [RSS00].

Ma UserLand, che non fu interpellata nella realizzazione del nuovo formato in quanto accusata di averlo snaturato semplificandolo troppo, continuò nello sviluppo delle sue versioni; uscirono così la 0.92, la 0.93, la 0.94 e finalmente la 2.0 [RSS05] (tabella 2).

Versione	Proprietario	Vantaggi	Stato attuale	Raccomandazioni
0.90	Netscape		Resa obsoleta dalla 1.0	Non va utilizzata
0.91	UserLand	Più semplice	Ufficialmente resa obsoleta dalla 2.0; ma ancora molto usata.	Va utilizzata per compiti non complessi, facilmente estendibile alla 2.0 se occorre maggiore flessibilità.
0.92, 0.93, 0.94	UserLand		Rese obsolete dalla 2.0	Non vanno utilizzate, meglio usare la 2.0
1.0	RSS-DEV Working Group	Basata su RDF, estendibile tramite moduli, non è controllata da un singolo vendor.	Stabile il formato base, in fase di definizione e sviluppo i moduli aggiuntivi.	Va utilizzata per applicazioni basate su RDF.
2.0	UserLand e poi Berkman Center for Internet and Society	Estendibile attraverso moduli, permette un passaggio indolore dalla 0.91; ora non è più sotto il controllo di un singolo vendor.	Stabile il formato base, in fase di definizione e sviluppo i moduli aggiuntivi.	Utilizzato per ogni genere di syndication.

Tabella 2 – Versioni di RSS [PIL02].

Perciò in base alla versione di RSS che si decide di implementare il nostro feed avrà un aspetto diverso; vediamo un esempio di RSS 0.91 [PIL02].

<rss version="0.91">
  <channel>
    <title>XML.com</title>
    <link>http://www.xml.com/</link>
    <description>XML.com features a rich mix of information and services for the XML community.</description>
    <language>en-us</language>
    <item>
      <title>Normalizing XML, Part 2</title>
      <link>http://www.xml.com/pub/a/2002/12/04/normalizing.html</link>
      <description>In this second and final look at applying relational normalization techniques to W3C XML Schema data modeling, Will Provost discusses when not to normalize, the scope of uniqueness and the fourth and fifth normal forms.</description>
    </item>
    <item>
      <title>The .NET Schema Object Model</title>
      <link>http://www.xml.com/pub/a/2002/12/04/som.html</link>
      <description>Priya Lakshminarayanan describes in detail the use of the .NET Schema Object Model for programmatic manipulation of W3C XML Schemas.</description>
    </item>
  </channel>
</rss>

Un feed comprende quindi un channel, che a sua volta include un titolo, un link ed una descrizione e, ma non è obbligatorio, l’indicazione del linguaggio e da una serie di item ognuna con titolo, link e descrizione.

Vediamo ora la versione RSS 1.00 [RSS00] delle stesse informazioni:

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
  xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel rdf:about="http://www.xml.com/cs/xml/query/q/19">
    <title>XML.com</title>
    <link>http://www.xml.com/</link>
    <description>XML.com features a rich mix of information and services for the XML community.</description>
    <language>en-us</language>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://www.xml.com/pub/a/2002/12/04/normalizing.html"/>
        <rdf:li rdf:resource="http://www.xml.com/pub/a/2002/12/04/som.html"/>
        <rdf:li rdf:resource="http://www.xml.com/pub/a/2002/12/04/svg.html"/>
      </rdf:Seq>
    </items>
  </channel>
  <item rdf:about="http://www.xml.com/pub/a/2002/12/04/normalizing.html">
    <title>Normalizing XML, Part 2</title>
    <link>http://www.xml.com/pub/a/2002/12/04/normalizing.html</link>
    <description>In this second and final look at applying relational normalization techniques to W3C XML Schema data modeling, Will Provost discusses when not to normalize, the scope of uniqueness and the fourth and fifth normal forms.</description>
    <dc:creator>Will Provost</dc:creator>
    <dc:date>2002-12-04</dc:date>
  </item>
  <item rdf:about="http://www.xml.com/pub/a/2002/12/04/som.html">
    <title>The .NET Schema Object Model</title>
    <link>http://www.xml.com/pub/a/2002/12/04/som.html</link>
    <description>Priya Lakshminarayanan describes in detail the use of the .NET Schema Object Model for programmatic manipulation of W3C XML Schemas.</description>
    <dc:creator>Priya Lakshminarayanan</dc:creator>
    <dc:date>2002-12-04</dc:date>
  </item>
</rdf:RDF>

Decisamente meno concisa; le principali differenze sono:

L’elemento radice è rdf: RDF [RDF04] al posto di rss.
RSS 1.0 [RSS00] utilizza i namespace, il namespace di default è definito all’url http://purl.org/rss/1.0. Il feed utilizza anche il namespace definito all’url http://www.w3.org/1999/02/22-rdf-syntax-ns# per gli elementi specifici di RDF e il namespace definito all’url http://purl.org/dc/elements/1.1/ che definisce il cosiddetto Dublin Core [DUB06]. Il Dublin Core Metadata si propone come uno standard di descrizione delle risorse in formato elettronico ed è costituito da 15 elementi descrittivi. È stato concepito allo scopo di consentire agli autori di effettuare direttamente in modo standardizzato la descrizione di risorse rese disponibili sulla rete.
I nodi <item> sono all’esterno del nodo <channel>.
All’interno di <channel> il marcatore <items>, che nella versione 0.91 non esiste

Vediamo ora lo stesso feed anche in versione RSS 2.0 [RSS05].

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>XML.com</title>
    <link>http://www.xml.com/</link>
    <description>XML.com features a rich mix of information and services for the XML community.</description>
    <language>en-us</language>
    <item>
      <title>Normalizing XML, Part 2</title>
      <link>http://www.xml.com/pub/a/2002/12/04/normalizing.html</link>
      <description>In this second and final look at applying relational normalization techniques to W3C XML Schema data modeling, Will Provost discusses when not to normalize, the scope of uniqueness and the fourth and fifth normal forms.</description>
      <dc:creator>Will Provost</dc:creator>
      <dc:date>2002-12-04</dc:date>
    </item>
    <item>
      <title>The .NET Schema Object Model</title>
      <link>http://www.xml.com/pub/a/2002/12/04/som.html</link>
      <description>Priya Lakshminarayanan describes in detail the use of the .NET Schema Object Model for programmatic manipulation of W3C XML Schemas.</description>
      <dc:creator>Priya Lakshminarayanan</dc:creator>
      <dc:date>2002-12-04</dc:date>
    </item>
  </channel>
</rss>

Anche in questo caso sono utilizzati i namespace ma non quelli RDF [RDF04] (in questo caso abbiamo utilizzato Dublin Core come nell’esempio precedente) ma non ne esiste uno di default; inoltre gli <item> sono di nuovo all’interno del marcatore <channel>

Per la nostra piattaforma utilizzeremo RSS 2.0 [RSS00] in quanto più semplice da realizzare rispetto alla versione 1.0 e comunque più che sufficiente per il nostro utilizzo.

<title>AVBlog - A Cold Fusion Blog application</title>

Blog platform made with Cold Fusion MX 7, it can use both DB or XML file for storage.

</description>

<item>

<title>New feature on the work</title>

<link>

http://www.avblog.org/index.cfm?mode=viewentry&id=59B5F321-CDFE-6613-CAA36E6CB08FC4E7

</link>

I'm expect to release a 1.5 version of AVBlog in april

</description>

<category>AVBlog</category>

<category>AVBlog Lite</category>

<author>andrea@dinamica.it (Admin)</author>

http://www.avblog.org/index.cfm?mode=viewcomment&id=59B5F321-CDFE-6613-CAA36E6CB08FC4E7

</comments>

</item>

</channel>

</rss>

Rispetto agli esempi precedenti vi sono alcuni marcatori aggiuntivi, essenzialmente <category>, uno per ogni categoria alla quale il post afferisce, e <comments> che contiene il link per visualizzare i commenti effettuati al post [PIL02].

Atom

Per superare le ambiguità e l’intrico di dialetti RSS [PIL02], nel 2004 nasce Atom [ATO05], un nuovo standard sviluppato autonomamente da un dipendente di IBM, Sam Ruby e sostenuto da molti blogger influenti. La fortuna di Atom è quella di essere stato adottato ancora in fase sperimentale da Blogger, la veterana delle piattaforme di blogging, ora in quota a Google®, un’apertura di credito di grande prestigio, che posto immediatamente Atom come possibile nuovo standard di fatto per la condivisione di contenuti [MAI04].

È inevitabile che, prima o poi, un formato fra RSS [PIL02] ed Atom [ATO05] prevalga sull’altro, per il momento è buona norma fornire i propri feed utilizzando entrambi i formati per dare la massima libertà di scelta a chi vorrà utilizzare i nostri contenuti.

Il formato Atom 1.0 [ATO05] è descritto nella RFC 4287 di IETF, un documento Atom deve essere XML ben formato ed identificato da un mime-type application/atom+xml [RFC05].

Gli elementi obbligatori sono definiti in tabella3, quelli facoltativi in tabella 4, vediamo ora un esempio di feed Atom:

<?xml version="1.0" encoding="utf-8"?>

<title>Example Feed</title>

</author>

<entry>

<title>Atom-Powered Robots Run Amok</title>

</entry>

</feed>

Gli elementi obbligatori dell’elemento <feed> sono descritti in tabella 3, quelli opzionali ma consigliati in tabella 4, quelli facoltativi in tabella 5.

In tabella 6 troviamo, invece, gli elementi obbligatori dell’elemento <entry> mentre in tabella 7 quelli facoltativi ma consigliati ed, infine, in tabella 8 gli elementi opzionali.

Elemento	Descrizione
id	Identifica il feed utilizzando un URI univoco e permanente. Di solito è l’indirizzo del sito al quale i feed si riferiscono; nel nostro caso: <id>http://www.avblog.org/</id>
title	Contiene il titolo del sito, e non deve essere lasciato vuoto. <title>Example, Inc.</title>
updated	Indica giorno ed ora dell’ultima modifica importante al feed. <updated>2003-12-13T18:30:02Z</updated>

Tabella 3 – Elementi di <feed> obbligatori [ATO05].

Elemento

Descrizione

author

Contiene il nome dell’autore del Feed. Ogni feed può avere più di un autore. Un feed deve avere obbligatoriamente almeno un autore a meno che tutti gli elementi di tipo <entry> contengano almeno un autore.

<email>JohnDoe@example.com</email>

<uri>http://example.com/~johndoe</uri>

</author>

link

Identifica una pagina Web corelata; ogni feed deve contenere almeno un link con l’indirizzo della pagina del feed stesso.

Tabella 4 – Elementi facoltativi di <feed> il cui utilizzo è però consiglitato dalle specifiche [ATO05].

Elemento	Descrizione
category	Specifica la categoria (o tag) alla quale il feed appartiene. Ogni feed può avere più elementi di questo tipo. <category term="sports"/>
contributor	Contiene i nomi di chi contribuisce al feed. Ogni feed può avere più elementi di questo tipo. <contributor> <name>Jane Doe</name> </contributor>
generator	Specifica il software utilizzato per generare il feed; utilizzato solo per debugging. Gli attributi uri e version sono entrambi opzionali. <generator uri="/feed/atom.cfm" version="1.0"> AVblog Atom Generator </generator>
icon	Specifica un’icona che identifica visivamente il feed, l’icona deve essere quadrata. <icon>/icon.jpg</icon>
logo	Specifica un’immagine che identifica visivamente il feed, l’immagine deve avere una larghezza in pixel doppia della sua altezza. <logo>/logo.jpg</logo>
rights	Informazioni di copyright sul contenuto del feed. <rights> © 2005 John Doe </rights>
subtitle	Contiene un eventuale sottotitolo del feed. <subtitle>all your examples are belong to us</subtitle>

Tabella 5 – Elementi facoltativi di <feed>[ATO05].

Elemento	Descrizione
id	Identifica univocamente l’URI del post. <id>http://example.com/blog/1234</id>
title	Contiene il titolo del post e non può essere vuoto <title>Atom-Powered Robots Run Amok</title>
updated	Indica il giorno e l’ora in cui il post è stato modificato l’ultima volta. <updated>2003-12-13T18:30:02-05:00</updated>

Tabella 6 – Elementi obbligatori di <entry> [ATO05].

Elemento	Descrizione
author	Indica il nome dell’autore del post; un post può avere più autori. Un post deve avere almeno un autore a meno che non esista l’elemento <author> all’interno di <feed> <author> <name>John Doe</name> </author>
content	Contiene il testo del post od un link che rimanda ad asee. Deve essere valorizzato se non esiste <summary> e se non è previsto un <link> con attributo alternate. <content>complete story here</content>
link	Identifica una pagina legata al post. Il tipo di relazione è definito dall’attributo rel che deve essere alternate nel caso non venga inserito <content> <link rel="alternate" href="/blog/1234"/>
summary	Contiene un breve riassunto (o solo l’inizio) del post. Deve essere indicato se non è definito <content> o se è definito con l’attributo src o se il suo contenuto è codificato in base64. <summary>Some text.</summary>

Tabella 7 – Elementi facoltativi ma consigliati di <entry> [ATO05].

Elemento	Descrizione
category	Specifica la categoria alla quale il post afferisce. Un post può avere più elementi di tipo <category> <category term="technology"/>
contributor	Indic ail nome di chi ha contribuito alla redazione del post; vi possono essere più <contributor> per ogni post. <contributor> <name>Jane Doe</name> </contributor>
published	Contiene data ed ora della prima pubblicazione del post. <published>2003-12-13T09:17:51-08:00</published>
source	Se un post viene copiato da un feed ad un altro feed, allora i metadata (tutti i nodi figli del feed a parte <entry> e relativi figli) del feed originale devono essere preservati <source> <id>http://example.org/</id> <title>Fourty-Two</title> <updated>2003-12-13T18:30:02Z</updated> </source>
rights	Contiene informazioni sul copyright del post

Tabella 8 – Elementi facoltativi di <entry> [ATO05]

Progetto dell’applicazione

Dal punto di vista della progettazione l’applicazione ricalca fedelmente lo schema visto in precedenza e tipico dei Blog ed in questo capitolo descriveremo quindi le funzionalità previste dall’applicazione attraverso la descrizione delle interfacce che abbiamo realizzato per accedere ai contenuti della stessa. Inizieremo con la descrizione dell’interfaccia Web, successivamente elencheremo le altre modalità tramite le quali è possibile interagire con l’applicazione e termineremo elencando brevemente i plugin e le loro funzionalità.

L’interfaccia Web

L’interfaccia Web ricopre tuttora un’importanza fondamentale, nonostante sia possibile interagire con il blog con altri sistemi, in quanto è molto probabile che la maggior parte dei lettori utilizzerà un comune browser per leggere i post del blogger, cosa che dovrà fare anche quest’ultimo per accedere all’interfaccia di configurazione in Flash per ora visualizzabile solo su Web.

Ma vediamo ora come è strutturata l’interfaccia pubblica del nostro blog e come questa cambia una volta che il blogger effettua il login sul sistema.

Interfaccia pubblica

L’interfaccia pubblica (figura 8) ricalca fedelmente lo schema tipico del blog, una parte centrale dedicata alla visualizzazione dei post (nel nostro caso due post di esempio pubblicati il 1 marzo ed il 28 febbraio). Dei post viene visualizzato il titolo ed il testo, in basso a sinistra compaiono le categorie relative, link attivi che rimandano all’elenco dei post della categoria, mentre a destra l’orario di pubblicazione ed il nome dell’autore ed i link per inserire commenti e trackback.

Nella parte laterale (nel nostro esempio a destra, ma dipende dal layout e dallo skin scelto in fase di configurazione) che contiene una serie di funzionalità che vediamo partendo dall’alto verso il basso:

Calendario: visualizza graficamente i giorni in cui sono stati scritti dei post, cliccando sul giorno è possibile accedere a tutti i post relativi.

Motore di ricerca: permette di effettuare ricerche nei post inseriti.
Archivio mensile: una serie di collegamenti che permette di accedere ai post divisi per mese di pubblicazione.
Categorie: qui vengono visualizzate le categorie, in questo caso due, AVBlog e Tesi, e di fianco il numero di post che afferisce loro.
Ultimi post: qui vengono visualizzati gli ultimi post pubblicati.
Feed: rendono disponibili i feed RSS [PIL02] ed ATOM [ATO05] di tutto il blog o solo delle singole categorie.

Interfaccia di amministrazione

Al blogger che effettua login non viene presentata un’interfaccia completamente differente (figura 9), come capita per gran parte dei CMS, ma una versione modificata di quella vista prima.

Nella parte centrale dedicata ai post vi sono due nuovi link, Cancella e Modifica che permettono, rispettivamente, di cancellare e modificare il post.

Nella parte laterale, invece, compare un menù completamente nuovo che permette di effettuare le operazioni di amministrazione e che vediamo in dettaglio.

Configurazione

Configurazione (figura 10): questo link porta all’interfaccia di configurazione del blog, realizzata in Flash, che permette di modificare tutti gli aspetti del file di configurazione xml che vedremo in dettaglio in seguito.

tesina blog e web

Figura10 – Interfaccia di configuraziona (dettaglio sulla scelta per quanto riguarda l’utilizzo di editor WYSIWYG [WYS06]).

Vediamo quali sono gli elementi sui quali è possibile agire utilizzando questa interfaccia:

Header: Qui è possibile definire il titolo del blog ed una sua breve descrizione; tali valori sono utilizzati per generare i tag necessari ad una corretta indicizzazione nei motori di ricerca.
Labels: Qui è possibile inserire codice HTML [HTML06] (o semplici stringe di testo) per l’intestazinone ed il piè di pagina che compaiono nell’interfaccia Web del blog.
Owner: In questa sezione è possibile inserire i dati del Blogger quali il nome, l’indirizzo e-mail ed l’url completo del sito.
Internationalization: All’interno di questa parte sono raggruppate tutte le opzioni che riguarda la scelta della lingua, del locale ed eventuali offset da utilizzare per sincronizzare il fuso orario dell’applicazione con quello del luogo dove si trova il blogger.
Options: Qui sono raggruppate le opzioni:
General: permette di definire se il blog deve essere o meno privato, se inviare email al blogger all’inserimento di commenti da parte del lettore, quanti giorni (con i relativi post) visualizzare in home page, se attivare i permalink, i trackbacks e se moderare questi ultimi. È inoltre possibile indicare se utilizzare o meno un editor WYSIWYG [WYS06] nell’editing dei post e dei trackback manuali. Infine va indicato il nome dell’istanza del gateway XMPP nel caso di utilizzo di tale opzione.
Smtp settings: qui è possibile indicare i valori del server che l’applicazione utilizza per spedire mail; di solito non è necessario valorizzare nulla in quanto Coldfusion [COL06] è di solito configurato a livello generale in questo senso.
GTalk account: qui viene semplicemente indicato il nome dell’account XMPP [XMP04].
Comments: in questa sezione è possibile decidere se abilitare i commenti, se abilitare l’editor WYSIWYG nei commenti, se utilizzare come metodo di prevenzione per lo spam una stringa che modifica l’email visualizzata, se attivare la possibilità di abbonarsi ai commenti e se permettere al lettore di spedire commenti privati al blogger.
RichEditor: qui è possibile decidere se utilizzare o meno un editor di tipo WYSIWYG e, in caso affermativo, se utilizzare FCKeditor [FCK05] o TinyMCE [TIN06].
Feed: Da questo punto è possibile abilitare o meno le interfacce diverse dal web:
Blog API: è possibile scegliere se abilitare o meno il supporto a client desktop ed, in caso affermativo, quale API [API06] supportare (in questo caso Movable Type API [MOV02]).
Email: qui è possibile attivare o meno il controllo su di un account email per l’inserimento di post tramite questo mezzo. È possibile impostare un intervallo di tempo in minuti che indica ogni quanto tempo l’applicazione controllerà l’account di posta per verificare se sono stati inseriti nuovi post. Seguono i dati per l’accesso all’account di posta.
IM – Xmpp (GoogleTalk): qui viene presentata l’opzione per abilitare o meno l’interfacciamento con IM [IME06], in caso affermativo è possibile indicare il tipo di IM (al momento solo XMPP [XMP04] è supportato) e l’account e la password utilizzati dall’account riservato all’applicazione.
Storage: In questa sezione è possibile specificare quale tipologia di storage utilizzare; le scelte possibili son al momento due: XML e DB; nel primo caso sarà richiesto il percorso dove memorizzare i file XML [XML06] creati nel secondo, invece, il nome della connessione JDBC [JDB06] utilizzata da Coldfusion per connettersi al nostro database.
Layout: Da questo punto è possibile specificare lo skin da utilizzare (Figura 11) ed il layout da applicare (Figure 12-13-14) al nostro blog. Skin e layout possono essere creati semplicemente essendo esclusivamente basati su CSS [CSS99].
Plugin: qui è possibile accedere alle parti di amministrazione previste dai plugin installati. Nel nostro caso sono presenti tre plugin:
CMS: non sono previste opzioni in amministrazione
Library: permette di scegliere la tipologida dei file che il plugin potrà gestire.
Permette di specificare l’eventuale digital Watermark [WAT02], le dimensioni delle immagini e delle miniature create in automatico dal plugin e di specificare il layout dei photoblog creati.
Log: Permette di selezionare a quali operazioni si vuole effettuare il log.

Figura 11 – esempi di skin applicati allo stesso Blog

tesina blog e web

Figura 12 – Layout centrato a dimensioni fisse

tesina blog e web

Figura 13 – Layout a tutta pagina

tesina blog e web

Figura 14 – Layout fissato a sinistra

Categorie

Categorie (figura 15): permette di creare, modificare ed ordinare l’elenco delle categorie.

tesina blog e web

Figura 15 – Gestione delle categorie

Modifica collegamenti

Permette di gestire ed ordinare il blogroll con un’interfaccia del tutto simile a quella della gestione categorie.

Modifica utenti

Permette di creare, modificare e cancellare gli utenti con accesso ti tipo amministratore o blogger (figura 16).

tesina blog e web

Figura 16 – Gestione utenti

Aggiungi un post

Aggiungi un post (figura 17): permette di creare un nuovo post. La stessa interfaccia, con i campi prevaricati, viene utilizzata per modificare post esistenti.

Ricarica blog

Ricarica Blog: permette di reinizializzare l’applicazione, utile se si effettuano dei cambi di configurazione manuali al file di configurazione xml.

Statistiche

Statistiche (figura 18): permette di accedere alla sezione statistiche basate sul sistema di gestione dei log

Altri link

Seguono poi i link per l’amministrazione dei plugin installati nell’applicazione e che permettono di inserire ed ordinare pagine nel caso del CMS, aggiungere e modificare file nel caso del plugin Library ed infine aggiungere e modificare gallerie di foto nel plugin Photoblog.

Una voce Wizards indica due ulteriori link che permettono il passaggio dei dati da un sistema di storage basato su XML ad uno basato su DB e viceversa.

Chiude il menù il link per effettuare il log out.

Figura 17 – Interfaccia per l’inserimento di un nuovo post

Multimodalità

Seguono alcuni esempi pratici riguardo ai possibili utilizzi delle caratteristiche di accesso multimodale peculiari della nostra applicazione.

Instant Messaging

Vediamo ora un esempio di interazione via IM fra un utente ipotetico, Andrea, e l’account controllato dal Blog, avblogdemo.

Per prima cosa Andrea digita il comando ‘help’ e avblogdemo risponde con la lista dei comandi disponibili (figura 18).

tesina blog e web

Figura 18 – risposta del blog al comando help

Dopodiché Andrea digita il comando ‘show 7’ ed in risposta avblogdemo visualizzerà il settimo post (figura 19). Da notare come in fondo alla risposta sia presente il permalink per poter aprire direttamente il browser all’indirizzo del post.

Successivamente Andrea digita il comando ‘login’, a quel punto avblogdemo richiede prima la user e poi la password dell’utente e, in caso in cui i dati inseriti siano corretti, visualizza un messaggio di benvenuto all’utente (figura 20).

Una volta effettuato il login possiamo provare ad inserire un post direttamente dall’interfaccia di IM [IME06].

Andrea digiterà prima il comando ‘addpost’; a questo punto avblogdemo richiederà rispettivamente il titolo ed il testo del post; poi richiederà se il post deve essere immediatamente pubblicato o meno ed infine richiederà conferma definitiva per l’inserimento del post (figura 21).

Ad un’ultima risposta affermativa la procedurà inserirà il post nel blog e questo verrà visualizzato nel blog come in figura 22.

tesina blog e web

Figura 19 – risposta del blog al comando show 7

tesina blog e web

Figura 21 – inserimento di un post sul blog

tesina blog e web

Figura 22 – visualizzazione sul blog del post inserito via IM [IME06]

Client Desktop

Il supporto a XML-RPC [XML99] permette di utilizzare una serie di applicazioni di terze parti che possono interagire con la nostra piattaforma attraverso lo sfruttamento delle API di Movable Type [MOV02].

Fra le numerose applicazioni che supportano questo tipo di API [API06] e che funzionano con la nostra applicazione ricordiamo:

Qumana [QUM06]: un’applicazione free e completa, in figura 23 ne vediamo l’interfaccia mentre visualizza un post di un blog che utilizza il nostro software.

Figura 23 – L’interfaccia di Qumana configurata per interagire con il blog http://www.avblog.org

W.Bloggar! [WBL05]: un’altra applicazione free che si integra perfettamente con il nostro software, soffre di qualche limitazione in più rispetto a Qumana.
BlogJet [BLJ06]: applicazione a pagamento ma ricchissima di features.

Email e Mo-Blogging

Un semplice esempio (detto di Mo-Blog [MOB06]) ben illustrato nelle figure 24 e 25 ci aiuta a verificare come compare il layout di un post contenente un’immagine e spedito da un cellulare dotato di foto camera.

Tutto quello che il blogger deve fare è spedire un messaggio di posta elettronica tramite il suo telefono cellulare allegando la foto che ha provveduto a scattare utilizzando la fotocamera integrata.

tesina blog e web

Figura 24 – Invio dell’immagine dal cellulare

tesina blog e web

Figura 25 – Post come compare sul blog

I plugin

Con l’applicazione sono forniti tre plugin relativamente semplici ma che implementano funzionalità molto diffuse fra altre piattaforme di Blog, vediamone le caratteristiche principali.

Photoblog

Permette di realizzare gallerie di foto partendo da un file compresso che contiene una serie di immagini in formato jpeg o gif.

È possibile inserire un digital watermark [WAT02], una stringa di testo personalizzabile che viene codificata insieme all’immagine e la caratterizza univocamente (utile per proteggere il copyright sulle proprie foto), la larghezza delle miniature e delle foto più grandi che si visualizzeranno cliccando sulle prime.

Viene poi richiesto l’inserimeno del file .zip contenente le immagini originali, il nome da dare alla galleria, una categoria alla quale eventualmente afferisce ed infine un testo descrittivo.

tesina blog e web

Figura 26 – Una foto di una galleria inserita con il plugin photoblog

Una volta effettuato l’inserimento il plugin si occupa di compattare il file, ridimensionare le immagini originali e creare due immagini una piccola e l’altra più grande in base alle dimensioni inserite precedentemente.

I file delle immagini sono memorizzati in cartelle all’interno di user/photoblog/galleries, qui viene creata una cartella con il nome della galleria ed al suo interno sono create altre tre cartelle, big, original e thumb che contengono rispettivamente le immagini ridimensionate grandi, le immagini originali e le miniature.

Il risultato permette di visualizzare le foto ridimensionate e di scorrere la gallery sia visualizzando le foto ingrandite una alla volta (figura 26) che utilizzando le miniature per avere un’idea più generale delle foto inserite (figura 27).

tesina blog e web

Figura 27 – Visualizzazione della descrizione della galleria e delle miniature

CMS

Questo è un plugin che implementa la possibilità di salvare pagine personalizzate. Diventa utile nei blog quando si vuole inserire anche informazioni non sottoforma di post ma come vere e proprie pagine Web dove la data e l’ora di pubblicazione non rivestono importanza.

Tipici utilizzi sono l’inserimento del curriculum o una descrizione del blogger; alcune piattaforme utilizzano per generare pagine di testo dei post speciali, noi abbiamo scelto di implementare la funzione tramite un semplice plugin che permette di inserire pagine e relative categorie e di salvarle fisicamente all’interno della cartella /user/cms.

File repository (library)

La possibilità di inserire file di qualsiasi tipo, di potere assegnare categorie agli stessi e di renderne possibile il download ai lettori è una funzionalità molto richiesta nei Blog pur non facendo parte delle caratteristiche essenziali che un applicazione per Web Log deve possedere.

Nel nostro caso abbiamo optato per una soluzione semplice che permette di inserire file, categoria e descrizione all’interno di un repository (situato nella cartella /user/library/files); gli eventuali download effettuati sono salvati con il meccanismo di log dell’applicazione e sarà quindi possibile quali e quanti file sono stati scaricati tramite la sezione statistiche dell’applicazione.

La piattaforma in dettaglio

La struttura

Prima di definire la struttura dell’applicazione è opportuno introdurre brevemente alcune nozioni sui meccanismi che Coldfusion [COL06] utilizza per realizzare il meccanismo delle applicazioni.

Separare logica e presentazione

Coldfusion [COL06] rende disponibili allo sviluppatore una serie di strumenti per la riusabilità del codice e, dalla versione 6 in poi, introduce i componenti che prendono a prestito alcuni aspetti degli tipici della programmazione ad oggetti e che rendono possibile la realizzazione di applicazioni Web più strutturate.

Questi componenti possono in teoria produrre output, come abbiamo visto in un template cfml è possibile mescolare tag Coldfusion [COL06] a tag HTML [HTM06], ma è buona norma evitarlo ed utilizzarli esclusivamente per contenere logica.

Un altro strumento offerto da Coldfusion [COL06] è il meccanismo dei custom tags; questi sono procedure riutilizzabili che però vengono impiegate prevalentemente per produrre output (per esempio una procedura che permette di la visualizzazione di un recordset con la paginazione).

È quindi possibile realizzare applicazioni nelle quali la logica dell’applicazione risulta separata da quella della presentazione utilizzando i componenti per la prima ed i custom tags per la seconda.

I Cfc

File con estensione .cfc, incapsulano funzionalità specifiche e mettono a disposizione un’interfaccia standard per l’accesso ad esse [FOR05a].

Le applicazioni client posso accedere a tali funzionalità richiamando (tramite il tag <cfinvoke> o con una sintassi del tipo nomeOggetto.nomeMetodo) i metodi definiti nei componenti stessi.

Un esempio banale di componente:

serverTime=now();

localStructure=structNew();

localStructure.Hour=DatePart("h", serverTime);

localStructure.Minute=DatePart("n", serverTime);

</cfscript>

</cffunction>

</cfcomponent>

Tale componente, salvato in un file chiamato mioComponente.cfc, contiene un solo metodo chiamato getLocalTime che restituisce una struttura con due chiavi, Hour e Minute. Può essere richiamato sia tramite tag scrivendo

<cfinvoke

component="myComponent"

method="getlocaltime"

returnvariable="myStructLocal">

oppure utilizzando una sintassi tipica dei linguaggi di scripting:

myObj = createobject(“component”,myComponent);

myStructLocal = myObj.getLocalTime();

</cfscript>

I Custom Tags

I Custom Tags sono invece normali template cfml, quindi file con estensione .cfm, che se richiamati da altre procedure con una sintassi particolare, sono eseguiti in un modalità specifica e godono di uno spazio di variabili non condiviso ma loro riservato (come i componenti) [FOR05a].

Vediamo un semplice customTag, myCustomTag.cfm, che si occupa di visualizzare l’ora:

serverTime=now();

localStructure=structNew();

localStructure.Hour=DatePart("h", serverTime);

localStructure.Minute=DatePart("n", serverTime);

</cfscript>

<cfoutput>#localStructure.Hour#:#localStructure.Minute#</cfoutput>

Questo può invece essere richiamato in tre modi, in tutti e tre i casi l’output da lui prodotto sarà visualizzato nel contesto indicato dal chiamante:

Semplicemente scrivendo un tag <cf_myCustomTag>
Utilizzando il tag <cfmodule>
Importando con <cfimport> tutti i tag di una cartella ed utilizzandoli poi tramite un prefisso predefinito.

Tipologia di variabili in Coldfusion

Prima di entrare nel dettaglio dell’applicazione è opportuno indicare velocemente quali tipologie di variabili abbiamo utilizzato e quali sono le loro differenze.

Fra le tipologie di variabili che Coldfusion [COL06] mette a disposizione dello sviluppatore, identificate da un prefisso (scope), e che noi abbiamo utilizzato, ci preme distinguere:

Variabili di tipo Application: Sono variabili che vengono inizializzate al momento della prima richiesta di una qualsiasi pagina della nostra applicazione; queste variabili rimangono in memoria per tutta la durata dell’applicazione che può essere definita a livello programmatico. Queste variabili sono globali all’interno di ogni request e di ogni sessione; utili quindi per contenere dati riguardanti la configurazione dell’applicazione.
Variabili di tipo Session: Vengono invece inizializzate per ogni utente alla sua prima richiesta di una pagina dell’applicazione. Vivono per tutta la durate della sessione (che può essere definita programmaticamente ma che comunque decade al momento della chiusura del browser) e sono utili per mantenere informazioni specifiche dell’utente che sta utilizzando l’applicazione.
Variabili di tipo Request: Sono variabili che non vengono mantenute in memoria una volta che la pagina è stata servita al browser (o ad altro user-agent). Sono però estremamente utili in quanto accessibili da qualsiasi componente o customtag (elementi che Coldfusion [COL06] mette a disposizione per la realizzazione di applicazioni).

Application.cfc e variabili di sistema

Coldfusion [COL06], per implementare il concetto di applicazione in un’ambiente tipicamente stateless come il Web, implementa un meccanismo legato alla presenza di un file, Application.cfc, che contiene la logica principale per gestire le operazioni da eseguire al verificarsi di determinati eventi [FOR05b].

Il file viene eseguito automaticamente da Coldfusion [COL06] ad ogni richiesta ad un template .cfm che appartiene alla cartella (o ad un sottocartella) della nostra applicazione; gli eventi che possiamo gestire sono:

onApplicationStart: si verifica quando l’applicazione viene eseguita la prima volta. In questo caso effettuiamo una serie di operazioni di inizializzazione che consistono nella lettura di un file di configurazione xml e nell’allocare in memoria istanze degli oggetti (componenti in Coldfusion [COL06]) che contengono la logica dell’applicazione.
onSessionStart: si verifica nel momento in cui un utente apre il browser e visualizza il sito la prima volta. Nel nostro caso inizializziamo semplicemente alcune variabili di sessione.
onRequestStart: si verifica ad ogni richiesta che viene effettuata al server. In questo caso inizializziamo una serie di variabili d’ambiente che vengono poi utilizzate all’interno dell’applicazione.
onError: vi verifica nel momento in cui Coldfusion [COL06] solleva un’eccezione (a causa di errori di programmazione o di comportamenti non previsti da parte dell’utente).

Il file si trova nella root dell’applicazione; vediamone ora la struttura:

this.name = "AVBlog";

this.applicationTimeout = createTimeSpan(2,0,0,0);

this.sessionManagement = true;

this.sessionTimeout = createTimeSpan(0,0,20,0);

</cfscript>

Nella prima riga troviamo il tag <cfcomponent> che indica a Coldfusion [COL06] che il file in questione (che ha estensione .cfc) è un componente (equivalente del concetto di classe in Java [JAV06]).

Nelle righe successive impostiamo alcune variabili che definiscono il nome dell’applicazione, in questo caso AVBlog, la durata della stessa, in questo caso 2 giorni, l’abilitazione del meccanismo delle sessioni e la durata delle stesse.

Da notare che le durate indicate, sia per l’applicazione che per la sessione, indicano il tempo massimo dall’ultima richiesta dell’utente trascorso il quale la sessione o l’applicazione scadono.

All’interno del file seguono poi una serie di tag <cffunction>, che in Coldfusion [COL06] identificano i metodi dell’oggetto, che implementano la logica dell’applicazione al verificarsi degli eventi indicati precedentemente.

Vediamo, per esempio, nel dettaglio il metodo onApplicationStart:

init();

application.id = createuuid();

application.start = now();

</cfscript>

...

</cfif>

</cffunction>

Come prima cosa, viene effettuata la chiamata al metodo private init(), che si occupa dell’inizializzazione dell’applicazione; poi vengono definite due variabili di applicazione chiamate id e start. La prima contiene un Universal Unique Identified (UUID) [UUI06], una stringa di 35 caratteri che ha la proprietà di essere univoca rispetto a tutti gli altri UUID generati, che identificherà univocamente l’istanza dell’applicazione per tutta la sua durata, la seconde serve semplicemente per memorizzare il momento in cui l’applicazione parte.

Successivamente vi è un controllo che verifica se nel file di configurazione, che vedremo nel dettaglio in seguito, abbiamo scelto di effettuare il log degli onApplicationStart, in caso positivo viene registrato nei log l’avvenuta inizializzazione dell’applicazione.

Vediamo ora quali operazioni esegue la init() richiamata da onApplicationStart:

application.objLocale = createobject("component","cfc.locale.utils");

Qui viene istanziato l’oggetto objLocale, che si trova all’interno della cartella cfc/locale/utils, che serve per gestire le problematiche relative alla gestione delle varie localizzazioni.

request.charset = "utf-8";

Qui indichiamo il charset utilizzato; questo parametro viene poi soprascritto dalle impostazioni presenti nel file di configurazione; qui viene impiegato solamente come valore predefinito in attesa del caricamento del parametro.

initRequest();

Il metodo initRequest è un metodo privato che si occupa di valorizzare le variabili di tipo request utilizzate dall’applicazione.

application.userFilesPath = '#request.appMapping#user/fckeditor';

Qui viene definita una variabile di tipo application che contiene il path dove FCKeditor può effettuare l’upload di file.

application.mapping = "avblog";

Questa variabile identifica il nome del gateway XMPP [XMP04] da definire nell’amministrazione di Coldfusion [COL06] per poter gestire le funzionalità di IM [IME06].

application.configurationCFC = createobject("component","cfc.configuration");

application.fileSystem = createobject("component","cfc.fileSystem");

application.blogCFC = createobject("component","cfc.blog");

In queste righe istanziamo 3 oggetti, configurationCFC che si occupa di caricare in memoria e gestire il file di configurazione, fileSystem che si occupa di gestire tutte le operazioni effettuate dall’operazione sul fileSystem e BlogCFC che contiene tutti i metodi legati alla gestione dei post.

application.configuration=application.configurationCFC.loadconfiguration();

In application.configuration viene caricata la struttura xml del file di configurazione.

application.authoping = application.configurationCFC.loadautopings();

In applicatio.authoping viene invece caricata la struttura xml dei servizi di autoping configurati.

application.objLocale.loadLocale(application.configuration.config.internationalization.setlocale.xmltext);

Qui viene caricato il locale definito nel file di configurazione.

initRequestStorage();

Viene poi richiamato il metodo private initRequestStorage() che si occupa di definire alcune variabili e soprattutto la variabile request.storage che specifica se nella nostra applicazione abbiamo deciso di utilizzare XML [XML06] o DB per lo storage dei dati.

application.configurationCFC.initSchedule(application.configuration.config.options.feed.email.active.xmltext);

application.configurationCFC.initVerityCollection(application.applicationname);

Qui vengono inizializzati i servizi di scheduling per il controllo dell’account di posta elettronica, che viene controllato ad intervalli predefiniti dall’utente, e di indicizzazione dei file xml dei post per il motore di ricerca.

application.objBlogStorage

= createobject("component","cfc.#request.storage#.blog");

application.objCommentStorage

= createobject("component","cfc.#request.storage#.comment");

application.objCategoryStorage

= createobject("component","cfc.#request.storage#.category");

application.objLinksStorage

= createobject("component","cfc.#request.storage#.link");

application.objUsersStorage

= createobject("component","cfc.#request.storage#.user");

application.objLogsStorage

= createobject("component","cfc.#request.storage#.log");

application.objSubscriptionsStorage

= createobject("component","cfc.#request.storage#.subscription");

application.objtrackbacksStorage

= createobject("component","cfc.#request.storage#.trackback");

In queste righe inizializziamo i componenti che vengono utilizzati per gestire post, commenti, categorie, link, utenti, log, subscription e trackback che sono contenuti nel percorso cfc / valore di request.storage. In base quindi al valore di quest’ultima variabile saranno inizializzati set di oggetti differenti .

Seguono altre impostazioni di variabili di applicazione che in questo contesto non indichiamo; vediamo invece come, alla fine del metodo, viene gestita la presenza di eventuali plugin:

"application.#listgetat(application.plugins.name,1,'.')#Obj"

=createObject("component","plugins.#listgetat(application.plugins.name,1,'.'#.cfc.#listgetat(application.plugins.name,1,'.')#");

tmpObj

= evaluate("application.#listgetat(application.plugins.name,1,'.')#Obj");

tmpObj.init();

</cfscript>

</cfloop>

Tramite <cfloop>, il tag di Codlfusion per effettuare iterazioni, sulla variabile application.plugin che contiene l’elenco dei plugin installati nella cartella plugins (e che vedremo in seguito) creiamo infatti delle variabili application in modo automatico e che avranno un nome del tipo application.nomepluginObj e che conterranno l’istanza dell’oggetto nomeplugin.cfc che si trova nella cartella plugins/ nomeplugin /cfc.

Successivamente viene eseguito il metodo init() di ognuno di questi plugin utilizzando la variabile temporanea tmpObj.

Similmente a onApplicationStart, i metodi onSessionStart e onRequestStart si occupano di inizializzare le variabili a livello di session e request; vediamo invece nel dettaglio il metodo onError che si occupa di gestire le eccezioni rilevate dall’applicazione:

Questi sono gli argomenti passati al metodo automaticamente dal sistema di gestione degli errori di Coldfusion [COL06]; il primo è una struttura che contiene tutti i dati relativi all’errore, il secondo un parametro che specifica all’interno di quale evento gestito da Application.cfc si è verificato l’errore.

In caso di errore salviamo su due file di log, tramite il tag <cflog>, il tipo di errore, dato da eventname, ed il messaggio di errore stesso, dato dalla chiave message nella struttura except.

init();

</cfscript>

In questo caso rieseguiamo una init() dell’applicazione, funzione che abbiamo visto in precedenza e che si occupa di reinizializzare l’applicazione, la scelta di effettuare un’operazione di questo tipo potrebbe sembrare troppo aggressiva in quanto si presenta il rischio concreto di eseguire operazioni non necessarie se l’errore si verifica per cause non dovute ad un problema legato all’inizializzazione delle variabili e dell’applicazione.

È però vero che l’esperienza ci ha suggerito per optare per una soluzione di questo tipo in quanto il sovraccarico dovuto all’esecuzione della init() è comunque limitato e rimangono comunque buone possibilità che questo possa risolvere l’errore che è stato intercettato.

<cfmail

to="#application.configuration.config.owner.email.xmltext#"

from="#application.configuration.config.owner.email.xmltext#"

subject="#application.applicationname# - Error"

type="html">

<p>Error Event: #EventName#</p>

<p>

Error details:<br/>

</p>

<p>

Application:<br/>

</p>

<p>

CGI:<br />

</p>

</cfoutput>

</cfmail>

Indipendentemente dal tipo di errore questo viene spedito via posta elettronica all’indirizzo specificato nel file di configurazione dell’applicazione; viene inviato un messaggio in HTML [HTM06] che contiene il contenuto dei parametri passati al metodo ed anche le strutture Application e CGI [CGI96] che incorporano rispettivamente tutte le variabili di tipo application e quelle di tipo cgi.

Da notare l’utilizzo del tag <cfdump>, un potente strumento che visualizza qualsiasi tipologia di variabile Coldfusion [COL06], utile soprattutto quando si cerca di analizzare il contenuto di array, recordset e strutture, ai fini del debug, in quanto queste vengono mostrate in una forma facile da leggere (figure 10 e 11) senza scrivere codice aggiuntivo.

</cffunction>

In conclusione viene incluso il messaggio di errore generico come definito nel file error.cfm presente all’interno della cartella include.

tesina blog e web

Figura 10 – <cfdump> di una variabile contenente un post; si tratta di un array di 1 elemento con all’interno una struttura i cui elementi sono i campi del post.

tesina blog e web

Figura 11 – risultato di <cfdump> sulla variabile application.links che contiene un recordset.

L’organizzazione del file system

Introduzione

Un’applicazione Web è generalmente costituita da un’insieme di file di testo contenenti il codice, file immagine ed altre tipologie di file inseriti all’interno di una struttura ben precisa; nel nostro caso in figura 12 sono visualizzate le cartelle fino al primo livello.

Le cartelle, così come i file, a parte Application.cfc ed Application.cfm, sono tutte in carattere minuscolo al fine di garantire la massima compatibilità sia con le piattaforme che supportano nomi di file case-sensitive che con quelle dove invece non viene fatta differenza fra maiuscole e minuscole nel file system.

La suddivisione delle cartelle è stata fatta in base alla logica dell’applicazione e nel corso di questa sezione vedremo nel dettaglio il contenuto di ognuna di esse.

tesina blog e web

Figura 12 – Struttura dell’applicazione

I file nella root dell’applicazione

Vediamo ora in dettaglio i file presenti nella root ed il loro significato:

Application.cfc: permette di definire il concetto di applicazione in Coldfusion [COL06], lo abbiamo visto in dettaglio in precedenza.
Application.cfm: per motivi di compatibilità con le vecchie versioni di Coldfusion [COL06] dove sostituisce Application.cfc
controller.cfm: il file chiave dell’applicazione; si occupa di smistare le richieste in base ai parametri passati via url.
download.cfm: file legato al plugin library, permette il download dei file che sono nel repository e di effettuare il log di queste operazioni.
email.cfm: template che si occupa di rintracciare presso l’account di posta definito nel file di configurazione eventuali messaggi da trasformare in post; viene eseguito automaticamente dallo scheduler interno di Coldfusion [COL06] ad ogni scadenza dell’intervallo di tempo definito nel file di configurazione.
index.cfm: è il file principale, quello che viene eseguito nella gran parte delle richieste; vediamolo in dettaglio:

</cfsilent>

Il tag <cfimport> ci permette di poter richiamare i file .cfm all’interno della cartella specificata nell’attributo taglib utilizzando il prefisso definito nell’attributo prefix; i file all’interno della cartella definita da taglib sono trattati come custom tags, una funzionalità specifica di Coldfusion [COL06] che vedremo in seguito.

Qui viene incluso il codice presente nel file header.cfm situato nella sottocartella include; tale file si occupa di visualizzare i tag XHTML [XHT02] per la dichiarazione del doctype e dell’header.

<body>

Questo <div> identifica e racchiude tutto l’output dell’applicazione.

Qui viene incluso il file header_top.cfm presente nella cartella include, tale file contiene il codice per generare la testata dell’interfaccia dell’applicazione.

<vb:blog>

</div>

Questo è il cuore dell’applicazione, entries definisce lo spazio entro il quale vengono visualizzati i post; al suo interno viene richiamato il customtag tramite il tag <vb:blog>, tale codice utilizza il prefisso imposto nel precedente <cfimport> per richiamare il template blog.cfm presente all’interno della cartella customtags.

<cfif application.configuration.config.options.privateblog.xmltext and (isuserinrole('blogger') or isuserinrole('admin') )

not application.configuration.config.options.privateblog.xmltext>

<vb:side_cal>

<vb:side_admin>

<vb:side_tagcloud>

<vb:side_search>

<vb:side_plugins>

<vb:side_listmonths>

<vb:side_categories>

<vb:side_recentposts>

<vb:side_recentcomments>

<vb:side_subscribeBlog>

<vb:side_links>

<vb:side_categories_rss>

</cfif>

<vb:side_logo>

</div>

Questa parte invece si occupa di visualizzare la parte laterale del blog; inquadrate all’interno del <div> con id side vi sono una serie di chiamate a customtags presenti nella cartella customtags che si occupano di visualizzare tutti gli elementi della parte laterale dell’applicazione.

Troviamo quindi il calendario, la parte di amministrazione ed una seriedi chiamate che si occupano degli elementi laterali; il controllo che viene effettuato con il tag <cfif> si occupa di verificare se il blog è impostato come privato o meno, in caso affermativo gli elementi della parte laterale, ad esclusione di side_logo, sono visualizzati solo se l’utente ha effettuato login.

#application.configuration.config.labels.footer.xmltext#

</cfoutput>

</div>

</body>

</html>

Qui invece viene indicato il testo a livello del piè di pagina e definito nel file di configurazione

install.txt: Un file di testo in lingua inglese con una breve guida all’installazione
license.txt: File di testo con la licenza dell’applicazione, in questo caso abbiamo scelto la General Public License (GPL) [GPL91].
releasenotes.txt: Un file di testo con l’elenco delle release rilasciate nel tempo e le relative note.
robots.txt: File di testo, formattato secondo le specifiche adottate dalla maggior parte dei motori di ricerca, nel quale istruiamo i motori di ricerca a tralasciare alcune cartelle della nostra applicazione nel loro processo di indicizzazione.
slideshow.cfm: Utilizzato dal plugin photoblog, si occupa di mostrare le foto di una galleria.
trackback.cfm: Template che, richiamato da blog o siti esterni, permette di inserire trackback sui post della nostra applicazione.
wizard_xmltodb.cfm: Template per la conversione dei dati da XML [XML06] a DB.
xmlrpc.cfm: Questo file si occupa di interfacciare i client desktop, utilizzando le API Movable Type [MOV02], e lo vedremo in dettaglio più avanti.

Cache

La cartella racchiude una serie di file html contenenti porzioni di pagina del sito e che vengono utilizzati come cache.

Un blog infatti si presta molto, come applicazione, all’utilizzo di meccanismi di questo tipo in quanto le operazioni di inserimento e modifica dei post da parte dei blogger per quanto numerose saranno sempre poche rispetto alle letture dei post stessi.

Questo implica la possibilità di evitare a Coldfusion [COL06] di generare dinamicamente tutte le volte un contenuto sempre uguale e quindi di incrementare le prestazioni della nostra applicazione.

Il meccanismo implementato prevede di mettere in cache principalmente il contenuto dei post; di ogni post viene salvata una versione statica che viene utilizzata per tutta la durata del periodo di refresh della cache, definito a livello di variabile di sistema.

Cfc

Nella cartella vi sono tutti i file con estensione .cfc; in Coldfusion [COL06] sono chiamati componenti e molte delle loro funzionalità sono derivate dalle classi Java [JAV06], tanto che in fase di compilazione ogni file con estensione .cfc viene trasformato in una classe Java [JAV06] equivalente.

Nella cartella sono presenti 3 sottocartelle, locale, db e xml; la prima contiene un component opensource chiamato utils.cfc [UTI03] con alcuni metodi che restituiscono data e ora nel formato definito dal locale settato sul server dove gira l’applicazione, le altre due, invece, hanno lo stesso numero di file con gli stessi nomi e permettono di interagire rispettivamente con il database o con i file xml.

Vedremo nel dettaglio più avanti i component delle cartelle db ed xml, vediamo ora invece l’elenco dei file presenti nella cartella cfc principale ed una veloce descrizione del loro scopo:

blog.cfc: contiene i metodi relativi alle operazioni sui post del blog.
configuration.cfc: contiene i metodi che riguardano la gestione del file di configurazione dell’applicazione.
fileSystem.cfc: contiene i metodi per gestire il fileSystem, quindi per creare e salvare file e directory ed è stato ideato per poter creare uno strato di astrazione fra le primitive per la gestione del file system, date dai tag <cffile> e <cfdirectory>, di Coldfusion [COL06] e le chiamate nei nostri componenti. Questo permette di operare correzioni a livello del cfc in questione nel caso, per esempio, in cui rinominare una cartella richieda differenti sintassi a seconda della versione di Coldfusion [COL06] che stiamo utilizzando, lasciando quindi inalterati tutti gli altri cfc che richiamano fileSystem.
gateway_controller.cfc: Si occupa di interagire con il gateway XMPP [XMP04], implementa i metodi per restituire output testuale alle interrogazioni fatte via IM [IME06].
links.cfc: implementa i metodi per la gestione del blogroll.
logs.cfc: implementa i metodi per la gestione dei logs.
mail.cfc: implementa un metodo per spedire mail, anche in questo caso si crea uno strato software che permette di astrarre dalla primitiva di Coldfusion [COL06] per la spedizione dei messaggi di posta elettronica, il tag <cfmail>.
subscriptions.cfc: implementa i metodi per la gestione degli abbonamenti ai commenti di un post o a tutto il blog.
trackbacks.cfc: implementa i metodi per la gestione dei trackback.
users.cfc: implementa i metodi per la gestione degli utenti del blog.
xmlrpc.cfc: componente di terze parti [XML03], implementa le primitive per generare richieste e risposte secondo lo standard XML-RCP [XML99].

Config

In questa cartella vi sono due files, configuration.cfm e ping.cfm; il primo è un file XML [XML06] che contiene la configurazione del Blog e che può essere sia modificato manualmente che in automatico utilizzando l’interfaccia di configurazione in Flash che il blog mette a disposizione.

Il file di configurazione viene caricato in memoria dall’applicazione al momento dell’inizializzazione della stessa; vediamo ora in dettaglio:

Questo tag (insieme a quello di chiusura presente a fine file) , unitamente all’estensione del file stesso (.cfm e non .xml) permette di evitare l’accesso dall’esterno. Si tratta infatti di un file di configurazione che può contenere informazioni delicate come password, va perciò evitata la possibilità di un download diretto dall’esterno del file.

<title>AVBlog 1.07</title>

</headers>

La sezione headers indica il titolo che si vuole dare al nostro blog, la descrizione dello stesso (questi dati sono poi utilizzati nei relative meta tag dell’output HTML [HTM06]) ed infine il charset con cui l’applicazione lavora.

Di default viene utilizzato UTF-8 [UTF05], per la massima compatibilità con tutti i set di caratteri, ma può essere cambiato dall’utente.

<![CDATA[

Administration</a> | 

AVBlog roject</a>

]]>

</header>

</labels>

La sezione labels contiene essenzialmente il testo che compare nell’interfaccia Web del blog come intestazione e come piè di pagina.

<owner>

<author>Blog Owner</author>

<email>email Owner</email>

<blogurl>url Owner</blogurl>

</owner>

Questa sezione contiene informazioni sul nome dell’autore, la sua email (è importante che sia valorizzata in quanto è l’email di cui si serve l’applicazione per le comunicazioni al blogger) e sull’url completo del Blog.

</internationalization>

La sezione internationalization è il cuore della gestione del multilingua e della scelta del locale da utilizzare nel sistema. È possibile indicare tutti i locale di Java [JAV06] e, per quanto riguarda le lingue, al momento sono disponibili italiano, inglese, spagnolo e turco.

I tag timeoffset e timeoffsetGMT vengono utilizzati per sincronizzare data e ora dei post in base a dove il server è ubicato (può capitare di avere il blog su di un server americano mentre il blogger risiede in europa).

<privateblog>false</privateblog>

Se valorizzato a true il blog è accessibile solo agli utenti registrati.

Contiene il numero dei giorni per i quali visualizzare i relativi post in home page.

Se valorizzato a true abilita la gestione dei permalinks.

Se valorizzato a true abilita la gestione dei trackback.

Se valorizzato a ture abilita la moderazionie dei trackback.

Se valorizzato a true abilita l’utilizzo di un editor WYSIWYG [WYS06] per i trackback manuali.

Se valorizzato a true abilita l’utilizzo di un editor WYSIWYG [WYS06] nella gestione dei post.

<whichricheditor>fckeditor</whichricheditor>

Qui viene specificato quale editor utilizzare (al momento l’applicazione supporta FCKEditor® [FCK05] e TinyMCE® [TIN06].

<xmppgatewayname>avblog</xmppgatewayname>

Qui indichiamo il nome del gateway XMPP [XMP04] da abilitare nell’interfaccia di amministrazione di Cold Fusion.

<toolbarset>Avblog</toolbarset>

</fckeditor>

Qui, nel caso sia stato scelto FCKEditor® [FCK05] come rich editor, viene specificata quale toolbar di strumenti utilizzare (nel nostro caso una specifica creata appositamente per l’applicazione).

<smtp>

<active>false</active>

<port/>

<user/>

</smtp>

Nel caso in cui sia necessario specificare quale server smpt impiegare per la spedizione di mail in questa sezione vanno indicati i valori del server, della porta utilizzata e dello user e della pwd se si tratta di un server che richiede autenticazione.

<im>

<gtalk>

</gtalk>

</im>

Qui viene indicato l’account XMPP [XMP04] del blogger, serve all’applicazione per inviare avvisi non appena un lettore invia un commento od un trackback.

<api>

<type>MovableType</type>

</api>

In questa sezione specifichiamo quale API [API06] utilizzare per l’interfacciamento con i client desktop. Al momento è supportata solo XML-RPC [XML99] con API per Movable Type [MOV02].

<email>

<active>false</active>

<subjectkey>avblog</subjectkey>

<pop3/>

<port/>

<user/>

</email>

Qui invece vanno indicati i dati per l’accesso ad un account di posta elettronica per inviare post al blog. È infatti possibile indicare un intervallo di tempo che separa ogni check dell’account da parte del blog. Al ricevimento di una mail con oggetto opportunamente formattato questo sarà letto e trasformato in post dall’applicazione.

<im>

<active>false</active>

<type>gTalk</type>

<gtalk>

</gtalk>

</im>

Qui indichiamo invece se vogliamo attivare il gateway XMPP [XMP04] e quale account utilizzare; vanno indicati user e pwd dell’account. Si tratta di un account specifico per il blog in quanto sarà a questo user che il blogger od il lettore farà le interrogazioni via IM [IME06].

</comment>

La gestione dei commenti prevede la possibilità di attivare o meno la moderazione; di utilizzare o meno un rich editor all’interno del commento; di attivare la protezione della mail del lettore contro lo spam; di attivare le sottoscrizioni ai commenti e di permettere o meno commenti privati dal lettore al blogger.

Qui indichiamo di quale tipologia di storage vogliamo servirci, al momento solo XML [XML06] e Database sono attivi.

<xml>

<folder>storage/xml</folder>

</xml>

Nel caso scegliamo XML [XML06] in questa sezione va indicato il percorso in cui saranno salvati i file.

<db>

<datasource>avblogdemo</datasource>

</db>

Se invece viene utilizzato un database in questa sezione viene indicato il nome del datasource (la connessione al db va creata nell’interfaccia di amministrazione di Coldfusion [COL06]).

<email>

<pop3/>

<user/>

<pwd/>

</email>

Al momento non è attiva la possibilità di servirsi di un account di email come storage per il blog; sarà implementata in versioni successive.

<theme>default</theme>

<layout>centered</layout>

</layout>

Qui invece è possibile scegliere quale skin utilizzare per la nostra applicazione.

<log>

<sessionstart>false</sessionstart>

<sessionend>false</sessionend>

<applicationstart>false</applicationstart>

<applicationend>false</applicationend>

<pageview>false</pageview>

</log>

Nella sezione di log è possibile scegliere a quali operazioni effettuare il log che viene anche elaborato dal modulo per le statistiche.

Il file ping.cfm, invece, viene effettua il ping automatico ai servizi online che segnalano quando un blog è stato aggiornato.

Al momento il file ha questo aspetto:

<?xml version="1.0" encoding="UTF-8"?>

<ping>

<![CDATA[Ping-O-matic]]>

</address>

<![CDATA[TechnoRati]]>

</address>

<![CDATA[IceRocket]]>

</address>

</ping>

Per ogni servizio attivato è presente un marcatore <address> che contiere l’URL del servizio ed il nome dello stesso.

Css

I file in questa cartella sono CSS [CSS99] che danno una struttura di base al blog. Sono separati dagli skin in quanto permettono di organizzare il layout della pagina indipendentemente dallo skin scelto.

I Css in questa cartella definiscono i tre selettori base del blog, main, entries e side che si occupano rispettivamente di definire il riquadro dell’applicazione, quello dove vengono visualizzati i post, e la barra laterale.

Al momento la cartella contiene tre files

layout_centered.css: struttura i tre selettori per ottenere un layout centrato e fissa la dimensione del selettore entries a 595px;
layout_fixleft.css: in questo caso i selettori sono impostati per fissare il layout a sinistra per un’ampiezza di 800 pixel.
layout_justified.css: qui invece il blog si estende per tutta la larghezza dello schermo, con il selettore entries e quello side ad occupare rispettivamente il 79% ed il 19% dell’ampiezza totale.

Customtags

In questa cartella sono raggruppati tutti i custom tags utilizzati nell’applicazione. Vedremo successivamente come questo strumento offerto da Coldfusion [COL06] ci permette di ottenere la separazione della presentazione dal contenuto; in questo caso tutti i file della nostra applicazione che producono parti di presentazione (quindi output a video ma anche su IM [IME06]), a parte i file presenti nella root, sono all’interno di questa cartella.

External

External è una cartella che contiene tool di terze parti impiegat nel Blog; probabilmente cresecerà con il tempo ma tutte le applicazioni che saranno ridistribuite dovranno possedere le seguenti caratteristiche:

Essere ovviamente ridistribuibili
Essere open source
Non essere necessarie al funzionamento del blog; in pratica è possibile eseguire la nostra applicazione anche senza nessuna delle applicazioni presenti all’interno della cartella; ovviamente mancheranno alcune feature ma il funzionamento del blog deve comunque essere garantito.

Al momento le applicazioni ridistribuite sono tre:

FCKEditor [FCK05]: Si tratta di un editor di tipo WYSIWYG [WYS06] utilizzabile sia con Internet Explorer che con Firefox e che permette di inserire elementi di formattazione XHTML [XHT02] all’interno dei post. La versione allegata alla nostra applicazione è la 2.2.
Jscalendar-1.0 [TCD03]: Si tratta di un’applicazione che ci dà la possibilità di costruire calendari tramite HTML [HTM06] dinamico e Javascript e viene impiegate nella nostra applicazione per creare il calendario con evidenziati i giorni in cui sono stati effettuati dei post.
Tinymce [TIN06]: Un altro editor di tipo WYSIWYG [WYS06], ha funzionalità molto simili ad FCKEditor [FCK05].

Feed

In questa cartella sono raggruppati i file che si occupano di generare i feed RSS [PIL02] ed ATOM [ATO05]: i file in questione sono rss.cfm ed atom.cfm.

Vediamo in dettaglio rss.cfm:

<cfif not

application.configuration.config.options.privateblog.xmltext>

Con questo controllo verifichiamo che il blog non sia stato impostato come privato, in questo caso non vengono forniti feed all’esterno.

Questo tag impone a Coldfusion di non generare caratteri se non all’interno del tag <cfoutput> e di non visualizzare eventuali informazioni di debug.

<cfinvoke

component="#request.blog#"

method="rss"

returnvariable="rssfeed">

</cfif>

</cfinvoke>

Con <cfinvoke> invece richiamiamo il metodo rss dell’oggetto definito in request.blog ed assegnamo il risultato (un xml ben formato contenente il feed) nella variabile rssfeed.

<cfcontent type="text/xml;

charset=#request.charset#">

Con il tag <cfcontent> invece indichiamo a Coldfusion [COL06] che dovrà restituire al chiamante una pagina con mime-tpye text/xml e con un set di caratteri valorizzato nella variabile request.charset (equivale a quello definito nel file di configurazione visto in precedenza).

<cfoutput>#trim(rssfeed)#</cfoutput>

Qui infine restituiamo il contenuto della variabile rssfeed dopo averne eliminato eventuali spazi inutili (funzione trim).

</cfif>

Se andiamo ad analizzare il codice nel file /cfc/blog.cfc relativo al metodo rss vediamo che dalla riga 247:

<title>

#application.configuration.config.headers.title.xmltext#

</title>

Il tag cfsavecontent permette di salvare all’interno di una variabile definita nell’attributo variable (in questo caso rssfeed) tutto quanto viene scritto all’interno del tag stesso (che prevede un tag di chiusua <cfsavecontent>).

Risulta quindi estremamente agevole generare un feed RSS [PIL02] conforme alle specifiche in quanto è sufficiente scriverne lo scheletro e poi valorizzare i vari attributi e nodi servendoci dei dati forniti da CF (nell’esempio il valore del title del blog è definito dalla variabile application.configuration.config.headers.title.xmltext che contiene il valore del titolo del blog indicato nel file di configurazione configuration.cfm visto in precedenza.

Il file atom.cfm si comporta in maniera analoga, ovviamente richiamerà un metodo atom dallo stesso componente cfc/blog.cfc che restituirà un fedd xml di tipo ATOM 1.0 [ATO05] correttamente formattato.

Gateway

La cartella contiene 3 files:

Application.cfc: necessario per poter gestire correttamente i gateway; si occupa di sovra scrivere i parametri definiti nel file con il medesimo nome presente nella root del blog. Dovendo in questo caso servire non pagine Web ma un’account di IM [IME06] alcune impostazioni fatte in quest’ultimo non sono accettabili.
avblog.cfc: tale file va impostato nell’amministrazione di Coldfusion [COL06] e contiene i metodi che sono richiamati dal gateway quando vengono effettuate operazioni di IM (principalmente il metodo onIncomingMessagge nel quale vanno specificate le azioni da intraprendere quando l’account gestito dal gateway riceve un messaggio)
avblog.cfg: è un file di configurazione e semplicemente indica al gateway quale account di tipo XMPP [XMP04] utilizzare, vediamolo in dettaglio:

# AVBlog XMPP Instant Message Configuration file

userid=myuser@gmail.com

password=mypassword

resourceName=Coldfusion MX 7

secureprotocol=TSL

securerequirement=true

serverip=talk.google.com

serverport=5222

Tale file viene automaticamente generato e cambiato dall’applicazione quando variamo i parametri dell’account gmail nell’interfaccia di amministrazione.

Images

In questa cartella vi sono tutti i file relativi ad immagini utilizzate nel blog. Si tratta, per esempio, delle icone per la validazione di XML [XML06] e RSS [PIL02]; le immagini relative alla grafica del blog sono invece nelle cartelle di skin.

Include

Coldfusion [COL06], tramite il tag <cfinclude>, permette di includere file con estensione .cfm all’interno di altri file; questo risulta comodo per poter separare in file differenti parti di codice che poi possono essere facilmente riutilizzate.

Nel nostro caso i file sono 4:

error.cfm: contiene il messaggio di errore che viene visualizzato in caso si verifichi un errore nell’applicazione.
functions.cfm: contiene alcune funzioni utilizzate all’interno di altri template dell’applicazione.
header.cfm: il file che viene incluso in ogni pagina generata dall’applicazione e restituita al browser, contiene la dichiarazione del DocType e le informazioni relative agli header della pagina; qui vengono inseriti i collegamenti ai fogli di stile, agli skin ed agli indirizzi dei feed.
header_top.cfm: questo file contiene esclusivamente il layout dell’intestazione dell’applicazione.

Js

La cartella comprende un solo file, functions.js, che raggruppa una serie di funzioni Javascript di uso comune.

Languages

In questa cartella vengono salvati tutti i file .xml che contengono le traduzioni delle stringhe di testo usate nell’applicazione. I file principali sono nominati in base alla codifica internazionale delle lingue ISO 639 a due caratteri [ISO99] .

Vi è poi una cartella plugins con all’interno una cartella per ogni plugin installato; all’interno vi saranno i file con le traduzioni delle stringhe utilizzate dai plugin.

Aggiungere un linguaggio all’applicazione implica semplicemente la creazione di questi file XML [XML06]; una volta inseriti in questa cartella il nostro blog la renderà disponibile come opzione.

Permalink

I permalink nella nostra applicazione sono equivalenti come formato a quelli creati da WordPress® [WOR06] e sono del tipo:

http://urlblog/permalinks/aaaa/mm/gg/titolo post

dove aaaa è l’anno espresso in 4 cifre e mm e gg sono rispettivamente il mese ed il giorno di pubblicazione del post.

L’applicazione si occupa della generazione automatica del permalink e della sua manutenzione; una regular expression si occupa di eliminare tutti i caratteri che potrebbero dare problemi nel salvataggio su file; così un post del 21 febbraio 2006 dal titolo Telefonare gratis a numeri di rete fissa (per ora) produrrà permalink del tipo /permalinks/2006/02/21/Telefonare-gratis-a-numeri-di-rete-fissa-per-ora/ in quanto le parentesi (ed ogni altro carattere non valido) vengono sostituite con un trattino.

Plugins

Questa cartella contiene eventuali plugin; al momento insieme all’applicazione vengono forniti tre plugin dei quali vedremo più avanti le caratteristiche.

Ogni plugin deve essere sviluppato seguendo una serie di regole; la nostra applicazione funziona perfettamente anche senza plugin installati.

Skins

Il meccanismo delle skin è stato realizzato utilizzando in maniera estensiva i Css; nella cartella vi sono una serie di sottocartelle ed ognuna di esse identifica uno skin diverso.

Uno skin è caratterizzato:

Due file di tipo css; main.css e calendar.css che definiscono lo stile rispettivamente per l’applicazione principale e per il calendario
Una cartella images che contiene tutte le immagini relative a quello specifico skin
Una cartella plugins che contiene un file .css per ogni plugin installato

L’applicazione verifica in maniera automatica gli skin installati e li mette a disposizione dell’utente nell’interfaccia di amministrazione.

Storage

La cartella storage include due sottocartelle, db e xml. La prima contiene un file .mdb con la struttura del DB già pronta per l’utilizzo con Microsoft Access®, contiene inoltre una sottocartella scripts con alcuni script sql predefiniti per generare la struttura del db con :

MySql 5 [MYS06].
Oracle 9i [ORA06].
Postgres 9 [POS06].
SQL Server [SQL06].

Nella cartella xml, invece, vi sono una serie di sottocartelle che a loro volta conterranno tutti i dati dell’applicazione se si sarà scelto di utilizzare xml come storage per i dati.

User

Nella cartella user vi sono i files dei quali viene fatto l’upload con FCKEditor [FCK05] ed anche quelli generati e gestiti dai plugin; in dettaglio:

cms: in questa cartella sono salvati fisicamente i file contenenti i testi delle pagine inserite con il plugin; la sottocartella metadata è utilizzata solo nel caso di storage in xml e contiene i metadata relativi alle pagine inserite.
fckeditor: qui ci sono i file dei quali viene fatto l’upload da Fckeditor [FCK05].
library: due sottocartelle, metadata e file ospitano rispettivamente i metadata xml (se non si è optato per l’opzione di storage con DB) ed i files del nostro repository.
photoblog: vi sono tre sottocartelle:
galleries contiene una cartella per ogni galleria creata. Ogni galleria a sua volta contiene una cartella big nella quale risiedono le immagini ridimensionate secondo le istruzioni date al plugin, una cartella thumb dove invece risiedono le miniature delle immagini originali (anche queste create in base alle preferenze espresse in fase di creazione della galleria) ed infine una cartella original dove vengono mantenute le immagini originali delle quali è stato fatto l’upload.
metadata è utilizzata solamente se si è scelto xml come storage per i dati; contiene un file xml per ogni galleria con i metadati per la stessa.
tmp contiene il file .zip con tutte le immagini che viene mandato al server in fase di creazione di un galleria; il plugin si occupa poi di estrarre i file immagine e di ridimensionarli e posizionarli nella relativa cartella.

Verity

In questa cartella vengono salvati i file utilizzati da Verity [VER06] per l’indicizzazione dei file .xml dei post.

Un layer per l’astrazione dal sistema di storage

Uno degli obiettivi nella realizzazione della nostra applicazione era quello di dare la massima libertà di scelta all’utente per quanto riguarda il sistema di storage. La scelta di ANSI SQL [KUL02] come linguaggio di interrogazione nel caso si voglia impiegare un DB va in questo senso e nello stesso va anche quella di rendere possibile l’utilizzo di file xml come sistema di storage.

Per rendere fattibile questa scelta ed affinché la stessa fosse comunque trasparente all’utente, era necessario realizzare un livello di astrazione software per rendere trasparente ai nostri componenti il sistema di storage utilizzato.

Abbiamo così creato una serie di componenti suddivisi in due cartelle, una chiamata xml, l’altra db, con lo stesso nome ed identici metodi.

La decisione di uniformare quindi le interfacce di questi componenti ha permesso di realizzare altri cfc di più alto livello che risiedono invece nella cartella cfc principale.

Così se l’inserimento di un nuovo post viene effettuato dal file controller.cfm che alla riga 274 indica:

id = request.blog.saveBlogEntry(….);

La variabile request.blog contiene un’istanza del componente blog.cfc della cartella cfc principale, vediamo la riga 176 del metodo:

application.objBlogStorage.save(arguments.date,arguments.old_date,arguments.time,arguments.category,arguments.author,arguments.email,arguments.menuitem,arguments.title,arguments.description,arguments.excerpt,arguments.published,arguments.id);

Viene richiamato il metodo save dell’istanza di oggetto definito nella variabile di tipo application application.objBlogStorage: tale variabile viene inizializzata nel metodo init() di Application.cfc visto in precedenza e vediamo che alla riga 434 di quel metodo:

application.objBlogStorage =

createobject("component","cfc.#request.storage#.blog");

viene creata l’istanza application.objBlogStorage e che questa si riferisce all’oggetto definito dal percorso cfc.#request.storage#.blog; la request.storage è una variabile di sistema che viene valorizzata in base a quanto presente nel file di configurazione dell’applicazione e che può assumere valore xml o valore db.

Diventa quindi chiaro come la semplice variazione del contenuto di quella variabile implica la creazione di istanze di oggetti dall’interfaccia identica ma dal comportamento completamente differente in quanto eseguono le stesse operazioni su sistemi differenti (gli uni lavorano su query gli altri su file xml).

Realizzare un nuovo sistema di storage (per esempio utilizzare un account email) diventa quindi più semplice; basta creare un set di oggetti con interfaccia identica a quelli già presenti e che al loro interno eseguono le operazioni necessarie per l’implementazione del sistema di storage prescelto.

Abbiamo inoltre deciso di utilizzare UUID [UUI06] come identificatori dei nostri post e degli altri elementi nel blog e tale scelta è dovuta essenzialmente a due fattori:

UUID [UUI06] permette di generare un codice univoco e permette di risparmiare delle query necessarie, invece, nel caso in cui come identificativo si voglia, per esempio, utilizzare un campo numerico.
L’utilizzo di UUID [UUI06] permette di passare in maniera indolore i dati da XML [XML06] a DB utilizzando un wizard apposito (file wizard_xmltodb.cfm).

Database

Lo schema delle tabelle, molto semplice, lo possiamo osservare in figura 13.

tesina blog e web

Figura 13 – schema DB della nostra applicazione

Elenchiamo ora le varie tabelle e ne vediamo la descrizione in dettaglio:

Tabella blogcategories: Contiene i riferimenti delle categorie di ogni post tabella (tabella 9).
Tabella categories: Contiene le categorie (o TAG) (tabella 10).
Tabella cms: Utilizzata nel plugin CMS, contiene le pagine che vengono visualizzate tramite il plugin (tabella 11).
Tabella comments: Contiene tutti i commenti inviati dagli utenti (tabella 12).
Tabella library (plugin) Utilizzata dal plugin library (per il file repository) contiene i file che fanno parte della libreria (tabella 13).
Tabella linksContiene tutti i link del blogroll (tabella 14).
Tabella logsContiene i log (tabella 15).
Tabella photoblog (plugin)Utilizzato dal plugin photoblog, contiene le foto che fanno parte di ogni galleria (tabella 16).
Tabella photobloggallery (plugin) Contiene le gallerie che raggruppano le foto presenti nella tabella photoblog (tabella 17).
Tabella posts Contiene i post del blog (tabella 18).
Tabella subscriptions Contiene tutte le sottoscrizioni fatte dagli utenti ai commenti dei post (tabella 19).
Tabella trackbacks Contiene i trackbacks fatti da blog esterni a nostri post (tabella 20).
Tabella users Contiene gli utenti che hanno accesso al nostro blog (tabella 21

Chiave	Nome campo	Tipo	Descrizione
PK	Blogid	Varchar (50)	Contiene l’id del post in formato UUID
PK	Category	Varchar (50)	Contiene la categoria

Tabella 9 – blogcategories

Chiave	Nome campo	Tipo	Descrizione
PK	Name	VarChar (50)	Contiene il nome della categoria

Tabella 10 – categories

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id della pagina CMS in formato UUID
	Name	VarChar (50)	Contiene il nome della pagina
	Ordername	VarChar (4)	Contiene l’ordine della pagina
	Category	VarChar(50)	Contiene il nome della categoria
	Ordercategory	VarChar(4)	Contiene l’ordine della categoria
	Description	Blob	Contiene la descrizione
	Sdate	VarChar(8)	Contiene la data nel formato aaaammgg
	Stime	VarChar(8)	Contiene l’ora nel formato hh:mm:ss

Tabella 11 – cms

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id del commento
	Blogid	VarChar (50)	Contiene l’id del blog cui il commento afferisce
	Sdate	VarChar (8)	Contiene la data nel formato aaaammgg
	Stime	VarChar(8)	Contiere l’ora nel formato hh:mm:ss
	Author	VarChar (50)	Contiene il nome dell’autore del commento
	Email	VarChar (50)	Contiene la mail dell’autore del commento
	Description	Blob	Contiene il testo del commento
	Emailvisible	VarChar (5)	Flag per scegliere se visualizzare la mail
	Private	VarChar (5)	Flag per commento privato
	Published	VarChar (5)	Flag per commento pubblicato o meno

Tabella 12 – comments.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id del file
	Name	VarChar (50)	Contiene il nome dell’elemento
	Category	VarChar (50)	Contiene la categoria dell’elemento
	Description	Blob	Contiene la descrizione dell’elemento
	File	VarChar (50)	Contiene il nome del file
	Sdate	VarChar (8)	Contiene la data nel formato aaaammgg

Tabella 13 – library.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id del link
	Name	VarChar (50)	Contiene il nome del lnk
	Address	VarChar (50)	Contiene l’indirizzo del link
	Ordercolumn	Int	Contiene l’ordine del link

Tabella 14 – links.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id del log in formato UUID
	Sdate	VarChar (8)	Contiene la data nel formato aaaammgg
	Stime	VarChar (8)	Contiene l’ora nel format hh:mm:ss
	Type	VarChar(50)	Contiene il tipo di log
	Svalue	Blob	Contiene la descrizione del log

Tabella 15 – logs.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id della foto
	Id_gallery	VarChar (50)	Contiene l’id della galleria di foto cui la foto appartiene
	Name	VarChar (50)	Contiene il nome della foto
	File	VarChar(50)	Contiene il nome del file della foto
	Description	Blog	Contiene la descrizione della foto
	Sdate	VarChar(8)	Contiene la data nel formato aaaammgg

Tabella 16 – photoblog.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id della galleria di foto
	Name	VarChar (50)	Contiene il nome della galleria
	Category	VarChar (50)	Contiene la categoria della galleria
	Description	Blob	Contiene la descrizione della galleria
	Sdate	VarChar(8)	Contiene la data nel formato aaaaaammgg

Tabella 17 – photobloggallery.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id del post in formato UUID
	Sdate	VarChar (8)	Contiene la data nel formato aaaaaammgg
	Stime	VarChar (8)	Contiene l’ora nel formato hh:mm:ss
	Author	VarChar(100)	Contiene il nome dell’autore del post
	Email	VarChar(100)	Contiene la mail dell’autore
	Menuitem	VarChar(100)	Titolo del post che in barra laterale
	Title	VarChar(100)	Contiene il titolo del post
	Excerpt	Blob	Contiene una sintesi o l’inizio del post
	Description	Blob	Contiene il testo del post
	Published	VarChar(5)	True o false a seconda se pubblicato

Tabella 18 – posts.

Chiave	Nome campo	Tipo	Descrizione
PK	Blogid	VarChar(50)	Contiene l’id del post
	Userid	VarChar (50)	Contiene l’id dell’utente
	Email	VarChar (50)	Contiene la mail dell’utente

Tabella 19 – subscriptions.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id del trackback
	Blogid	VarChar(50)	Contiene l’id del post a cui il trackback afferisce
	Sdate	VarChar (8)	Contiene la data nel formato aaaammgg
	Stime	VarChar (8)	Contiene l’ora nel formato hh:mm:ss
	Url	VarChar (50)	Contiene l’url del post dal quale è partito il trackback
	Blog_name	VarChar (50)	Contiene il nome del blog dal quale è partito il trackback
	Excerpt	Blob	Contiene una sintesi o l’inizio del post dal quale è partito il trackback
	Title	VarChar (50)	Contiene il titolo del post dal quale è partito il trackback
	Published	VarChar (5)	Contiene true o false a seconda se pubblicato

Tabella 20 – trackbacks.

Chiave	Nome campo	Tipo	Descrizione
PK	Id	VarChar(50)	Contiene l’id dell’utente
	Fullname	VarChar (50)	Contiene il nome completo dell’utente
	Email	VarChar (50)	Contiene l’email dell’utente
	Us	VarChar (50)	Contiene lo username dell’utente
	Pwd	VarChar (50)	Contiene la password dell’utente
	Role	VarChar (50)	Ruolo dell’utente (blogger o admin)

Tabella 21 – users.

XML

Le sottocartelle all’interno di storage/xml sono:

Categories: conterrà una cartella per ogni categoria; all’interno di ogni cartella sarà inserito un file per ogni post afferente alla relativa categoria.
Comments: conterrà un file xml per ogni commento.
Entries: conterrà un file xml per ogni post.
Links: contiene un file xml con i link per il blogroll.
Logs: contiene un file .xml per ogni operazione di log.
Subscriptions: contiene un file di testo per ogni post in cui sono stati inseriti commenti ed i cui autori hanno richiesto di essere avvisati via email se altri commenti relativi allo stesso post sono inseriti.
Trackbacks: conterrà un file xml per ogni trackback.
Users: contiene un file xml con l’elenco degli utenti che hanno la possibilità di inserire dei post; sono previsti due livelli di accesso; blogger e admin; il primo può solo inserire, modificare e cancellare i propri post; il secondo ha accesso a tutti i post nel blog ed all’amministrazione dello stesso.

Le principali funzionalità

Di seguito vedremo in dettaglio alcune delle principali funzionalità dell’applicativo realizzato.

Integrazione XMPP e GoogleTalk

La possibilità di interagire con il blog utilizzando un software di IM [IME06] sicuramente una delle caratteristiche più innovative della nostra applicazione.

Requisiti

Per poter utilizzare questa funzionalità occorre predisporre un account XMPP [XMP04] che sarà di esclusiva competenza dell’applicazione e indicare un’ulteriore account XMPP [XMP04] che sarà quello avvisato in caso di ricevimento di commenti o trackback.

Questa funzionalità inoltre è disponibile esclusivamente con la versione Enterprise di Coldfusion MX [COL06], altri cfml engine al momento non offrono questa opportunità.

Installazione

Per prima cosa è necessario configurare il nostro account all’interno dell’interfaccia di amministrazione della nostra applicazione (figura 28); occorre infatti abilitare la funzionalità, selezionare il tipo di IM, al momento è supportato solo GoogleTalk [TAL05], ed infine indicare user e pwd dell’account XMPP [XMP04].

Occorre inoltre indicare l’account XMPP del blogger (figura 29), questo permette a quest’ultimo di essere avvisato via IM non appena un lettore inserisce un commento od effettua il trackback sul blog.

A questo punto è possibile aprire la console di amministrazione di Coldfusion [COL06], effettuare il login e cliccare sulla voce di menù Gateway Instances all’interno della sezione Event Gateways.

tesina blog e web

Figura 28 – Configurazione account XMPP.

tesina blog e web

Figura 29 – account XMPP del blogger.

Si deve poi aggiungere una nuova istanza (figura 30) inserendo l’id da assegnare alla stessa, nel nostro esempio AVBlog, la tipologia del gateway, in questo caso XMPP –XMPP Gateway, ed il percorso fisico per i due file, avblog.cfc ed avblog.cfg che si trovano nella cartella gateway della nostra applicazione.

tesina blog e web

Figura 30 – Creazione istanza gateway XMPP.

Aggiunta l’istanza è sufficiente farla partire premendo l’apposito pulsante presente in basso nella stessa schermata; se è tutto configurato correttamente l’istanza risulterà in running e sarà possibile interrogare il nostro blog tramite il nuovo account myavblog@gmail.com

Il file avblog.cfc

Questo file viene richiamato dal gateway non appena si verificano gli eventi supportati dallo stesso:

onAddBuddyRequest: questo evento viene invece richiamato ogni volta che un utente aggiunge il nostro account fra i suoi contatti, anche in questo caso nel componente vi è un metodo che si occupa di gestire questa situazione; nel dettaglio:

</cffunction>

In questo caso il codice è molto semplice, alla struttura retValue che restituiamo al chiamante e che contiene tre chiavi daremo i valori:

Command = accept in quanto diamo il permesso al richiedente di inserirci fra i suoi contatti.
BuddyID = CFEvent.data.sender, valore che contiene l’id dell’account che ha spedito la richiesta.
Reaseon = “Welcome!”, una semplice stringa di testo restituita al chiamante.

onIncomingMessage: tale evento viene richiamato ogni volta che l’account configurato riceve un messaggio; nel componente vi è un metodo con lo stesso nome che contiene la logica per creare la risposta da inviare.

In quest’ultimo caso il codice è più complesso ed all’interno del metodo una serie di condizioni eseguirà le operazioni in base al comando richiesto. Se, per esempio, un utente tramite IM [IME06] inserisce il comando listall, verrà attivato l’evento onIncomingMessage e sarà passata allo stesso una struttura, chiamata CFEvent, che avrà una chiave, data.message che contiene il valore listall.

A questo punto viene eseguito il controllo alla linea 77 del file avblog.cfc che, nel caso il messaggio sia listall effettua una chiamata al metodo listAll del componente objController (un’istanza del file gateway_controller.cfc)

returnMessage = objController.listAll();

</cfscript>

</cfif>

Il metodo restituirà una stringa che costituirà la risposta che sarà inviata all’IM del utente che aveva effettuato la richiesta.

Il file gateway_controller.cf

Situato nella cartella cfc è un componente che possiede una serie di metodi, uno per ogni comando che abbiamo reso disponibile nell’interfaccia via IM [IME06].

Nel caso, per esempio, in cui il comando richiesto sia listall, come abbiamo visto prima viene richiamato il metodo equivalente che vediamo in dettaglio. Viene creata una variabile posts, una stringa che sarà costruita dinamicamente e che conterrà il risultato da restituire al chiamante.

La variabile application.days contiene tutte le date in cui sono stati effettuati post perciò viene fatto un ciclo per poter prendere tutti i post del blog; all’interno di questo primo ciclo, riportato in grassetto, viene creata la variabile dayposts, un array per l’esattezza, che viene restituito dal metodo show del component istanziato in request.blog e che restituisce un array con tanti elementi quanti sono i post effettuati nella data passata al metodo.

Iterando a questo punto anche sull’array costruisco dinamicamente la mia variabile posts nella quale, essendo una stringa e dovendo essere visualizzata su un IM, vengono inseriti anche i codici per le andate a capo.

var i = 1; var j = 1; var k = 1; var dayposts = arraynew(1);

var posts = "#chr(13)##chr(13)#All posts (to show a post type 'post'

and the post number)#chr(13)#";

for (i=1;i lte listlen(application.days);i=i+1) {

dayposts = request.blog.show(listgetat(application.days,i),session.IMlogged);

for (k=1; k lte arraylen(dayposts); k=k+1) {

posts = …….. ;

if (session.IMlogged)

posts = posts & "published:#dayposts[k].published# #chr(13)#";

else posts = posts & chr(13);

j = j + 1;

}

</cfscript>

</cffunction>

Supporto Client Desktop

Il supporto di XML-RPC [XML99] e delle API di Movable Type [MOV02] permette alla nostra applicazione di interagire con una serie di client di terze parti e di fornire quindi uno strumento flessibile che lascia all’utente un’ampia scelta riguardo all’interfaccia preferita per interagire con il Blog.

Qumana

Fra i tool disponibili per il nostro esempio scegliamo Qumana [QUM06], un tool free e molto completo. Una volta installato il prodotto va configurato per poter gestire la nostra applicazione, è sufficiente cliccare sulla voce di menù Posting / Configure / Configure Publishers, dopodiché premere il pulsante news; comparirà una schermata come da figura 31.

Alla voce server va indicato Movable Type API [MOV02], nella voce host va invece indicato l’url del blog; alla voce endpoint va indicato come endpoint il file /xmlrpc.cfm e come porta va indicata quella utilizzata dal Web server sul quale risiede l’applicazione.

La comodità di tool come questi è sicuramente la possibilità di scrivere post anche offline e di poterli poi pubblicare con calma una volta connessi ad Internet.

tesina blog e web

Figura 31 – Configurazione di Qumana [QUM06].

Nella schermata successiva sarà sufficiente inserire nome utente e password di un utente di tipo admin del nostro blog; a quel punto Qumana [QUM06] è pronto per poter gestire i nostri post e diventa quindi possibile inserire nuovi post, modificare o cancellare quelli esistenti, creare categorie e fare l’upload di file come abbiamo visto in precedenza.

Il file xmlrpc.cfm

Il template Coldfusion [COL06] che si occupa della comunicazione con questi tool e che fa da ‘endpoint’ è xmlrpc.cfm, vediamone la struttura:

Questi due Tag servono per poter restituire la pagina con mime type text/xml e senza spazi vuoti nel contenuto.

objXmlrpc = createObject("component","cfc.xmlrpc");

structWork = objXmlrpc.XMLRPC2CFML(getHttpRequestData().content);

arrayResponse = arraynew(1);

</cfscript>

Qui viene creata la struttura structWork che contiene l’xml spedito da tool come Qumana opportunamente trasformato in una struttura Coldfusion [COL06] dal componente objXmlrpc, componente di terze parti citato precedentemente.

Successivamente vengono eseguiti una serie di controlli, che non riportiamo, che si assicurano della correttezza formale della chiamata, a quel punto un costrutto del tipo CASE, realizzato da Coldfusion [COL06] con i tag <cfswitch> e <cfcase> ci permette di scrivere la logica necessaria per la generazione delle risposte.

myResponse = arraynew(1);

myResponse[1] = structnew();

myResponse[1].nickname = qryUser.us;

myResponse[1].userid = "(string)" & qryUser.us;

myResponse[1].url=

application.configuration.config.owner.blogurl.xmltext;

myResponse[1].email=qryUser.email;

myResponse[1].lastname=

listgetat(qryUser.fullname,1,' ');

myResponse[1].firstname=

listgetat(qryUser.fullname,2,' ');

result =

xmlparse(objXmlrpc.CFML2XMLRPC(myResponse,'response'));

</cfscript>

</cfcase>

….

</cfswitch>

Abbiamo indicato un solo <cfcase> come esempio, vediamo infatti il codice che permette di preparare la risposta ad una chiamata XML-RPC [XML99] al metodo getUserInfo delle API [API06] di Blogger [BLO03] (Movable Type è retrocompatibile con le API di Blogger e MetaWebLog [MET02] e ne condivide alcune chiamate).

Viene costruita una variabile, result, che è un documento XML [XML06] (memorizzato come struttura Coldfusion [COL06], che in questo caso contiene i dati dell’utente che ha effettuato la richiesta.

<cfif isdefined('result')><cfoutput>#tostring(result)#</cfoutput></cfif>

Una volta ottenuta la variabile result, che a seconda del metodo richiamato assumerà risultati differenti ma che comunque è sempre un documento XML [XML06], questa viene visualizzata, si utilizza la funzione tostring() che in Coldfusion [COL06] ha la funzione di trasformare in stringa un documento XML memorizzato come struttura; il tag <cfheader> risulta necessario in quanto il possedere un’header Content-Length contenente la lunghezza esatta in byte del documento restituito fa parte delle specifiche XML-RPC [XML99].

Email e Mo-Blogging

Come accennato nell’introduzione la possibilità di aggiornare il proprio Blog utilizzando strumenti mobili come i cellulari od i palmari può aumentare in maniera considerevole le capacità di aggiornamento del nostro sito.

Abbiamo implementato un sistema di questo tipo che si appoggia ad un account di posta elettronica i cui dati di accesso vengono specificati nel file di configurazione; nello stesso file viene anche configurato il numero di minuti che deve intercorrere fra un controllo dell’arrivo di messaggi nell’account di posta elettronica e l’altro.

I messaggi che hanno un oggetto formattato in questo modo parol achiave@username@password@titolo post saranno scaricati dal blog ed inseriti come post a tutti gli effetti.

Il file email.cfm

Il file è quello che si occupa di controllare il contenuto dell’account di posta elettronica configurato e di verificare la presenza o meno di messaggi da inserire come post. Tramite il tag <cfpop> scarica gli header di tutti i messaggi presenti in quel momento all’interno dell’account di posta; da notare che <cfpop> restituisce questi risultati come recordset veri e propri e questo ci permette di utilizzare tutte le funzioni ed i tag che Coldfusion [COL06] rende disponibili per trattare questa tipologia di dati.

A questo punto i messaggi vengono filtrati in base alla presenza o meno della parola chiave definita in file di configurazione, in caso positivo rimane in memoria un recordset contenete tutti i messaggi con un oggetto di questo tipo, viene eseguito allora un ciclo su quest’ultimo recordset, chiamato qryGetMessagesFiltered e per ogni record viene eseguito questo codice:

<cfpop

action="getall"

uid = "#qryGetMessagesFiltered.uid#"

name="qryMessage"

server="#application.configuration.config.options.feed.email.pop3.

xmltext#"

port="#application.configuration.config.options.feed.email.port.

xmltext#"

username="#application.configuration.config.options.feed.email.user.

xmltext#"

password="#application.configuration.config.options.feed.email.

password.xmltext#">

</cfpop>

Questa parte si occupa di scaricare questa volta tutto il messaggio dal server, non solo l’header, il risultato viene memorizzato in un nuovo recordset di nome qryMessage.

okdelete = 0;

user = listgetat(qryMessage.subject,2,'@');

pwd = listgetat(qryMessage.subject,3,'@');

title = listdeleteat(qryMessage.subject,1,'@');

title = listdeleteat(title,1,'@');

qryUser = request.users.authenticate(user,pwd);

if (trim(qrymessage.htmlbody) is not '')

text = qrymessage.htmlbody;

else

text = qrymessage.textbody;

if (qryuser.recordcount gt 0)

{

if (isdate(qryMessage.date))

messageDate = qryMessage.date;

else

messageDate = now();

request.blog.saveBlogEntry(dateformat(messageDate,'dd/mm/yyyy'),'',timeformat(now(),'HH:mm:ss'),'',qryUser.fullname,qryUser.email,title,title,text,'','true');

okdelete = 1;

}

</cfscript>

A questo punto prima di effettuare il salvataggio del post controlleremo che il resto dell’oggetto contenga username e password separati dal carattere @ ed in caso positivo procederemo con l’inserimento.

Generazione immagini captcha

Come abbiamo visto in precedenza la nostra applicazione, come mezzo di protezione anti Spam, prevede l’utilizzo di immagini Captcha [CAP05] (figura 26); tali immagini hanno la peculiarità di essere generate dinamicamente secondo determinati algoritmi e di essere difficilmente interpretabili utilizzando procedure automatiche.

Figura 26 – Immagine Captcha generata dalla nostra applicazione

Esistono innumerevoli algoritmi, alcuni brevettati altri liberi, per la generazione di immagini di questo tipo; per la nostra applicazione abbiamo ritenuto sufficiente una semplice stringa alfanumerica di sei caratteri costituita dai primi sei caratteri del risultato della funzione di hash() applicata ad un numero casuale da zero a duecentomila. Il file che si occupa della generazione delle immagini captcha è captcha.cfm e si trova nella cartella /customtags e sfrutta la possibilità di Coldfusion [COL06] di interfacciarsi nativamente con le classi Java [JAV06] che la Java [JAV06] Virtual Machine sulla quale gira l’Applicatione Server mette a disposionze.

Nel nostro caso abbiamo utilizzato i package Java.io [JAV01], Java.awt [JAV03a] e Javax.imageio [JAV03b] rispettivamente per le operazioni di I/O, per la generazione dell’immagine e per il salvataggio della stessa.

Vediamo, per esempio, come con Coldfusion [COL06] è possibile interagire con le classi facenti parte dei package sopra citati:

jFileOut=createObject("Java","Java.io.File").init(Attributes.file);

</cfscript>

Con questa istruzione, per esempio, viene istanziato l’oggetto File del package Java.io e ne viene eseguito il metodo init() al quale viene passata la variabile attributes.file che contiene il path del file immagine che verrà creato.

createObject(

"Java","Javax.imageio.ImageIO").write(outBufferedImg,

"jpg",

jFileOut);

</cfscript>

Questa semplice chiamata al metodo write della classe ImageIO, invece, permette di salvare sul filesystem l’immagine generata, contenuta in outBufferedImg, di tipo jpeg.

I plugin

La decisione di implementare un meccanismo per i plugin è dovuta essenzialmente alle infinite possibilità che al giorno d’oggi le piattaforme per i Blog offrono e contemporaneamente alla volontà di non trasformare la nostra applicazione in un insieme disomogeneo di funzionalità.

Da questo punto di vista l’utilizzo di plugin per implementare funzionalità accessorie è sicuramente l’ideale in quanto meno invasivo per chi non è interessato ad esse.

La struttura

I plugin devono avere tutti una struttura ben definita (figura 27), all’interno della cartella principale, dal nome equivalente a quello del plugin, vi sono 3 cartelle principali:

cfc: contiene i componenti Coldfusion [COL06] che implementano la logica del plugin.
config: contiene un solo file, configuration.xml con eventuali dati di configurazione.
customtags: contiene i customtags per la parte di presentazione del plugin

tesina blog e web

Figura 27 – Struttura dell’applicazione

All’interno della root del plugin deve essere presente un file, controller.cfm, che replica per il plugin le stesse funzionalità che il file omonimo nell’applicazione principale ricopre. Il file infati si occupa di effettuare determinate operazioni in base ai parametri url passati al plugin.

Anche in questo caso all’interno della cartella cfc sono presenti due sottocartelle che contengono due componenti con metodi identici che implementano il codice

Nel momento in cui una cartella con questa struttura viene inserita all’interno della cartella plugin l’applicazione la rileverà automaticamente e sempre automaticamente aggiungerà le nuove funzionalità agli strumenti a disposizione dell’utente.

Conclusioni e sviluppi futuri

L’obiettivo della tesi è la realizzazione di una piattaforma Blog in grado di competere con le più blasonate piattaforme di Blog sul mercato e con una spiccata vocazione per la multimodalità.

In particolare l’interazione con sistemi diversi dal Web è un tema poco esplorato e l’idea di utilizzare un sistema di IM [IME06] come interfaccia è sicuramente innovativa e da sviluppare nelle versioni future del prodotto.

L’applicazione è stata rilasciata in versione 1.0 il giorno 11 dicembre 2005, con il nome di AVBlog, e da allora è stata scaricata 1200 volte; al momento l’ultima versione rilasciata è la 1.07 che risolve alcuni bug segnalati da utenti che la stanno provando; i blog online che la utilizzano e dei quali siamo a conoscenza sono circa una decina, compreso AVBlog.org che è il sito ufficiale dell’applicazione.

La scelta di una tipologia di licenza GPL [GPL91] è essenzialmente dovuta alla nostra volontà di realizzare qualcosa di aperto, a costo zero, liberamente modificabile da chiunque al fine di realizzare una comunità attorno al progetto.

Gli sviluppi futuri infatti vanno in questa direzione, dal punto di vista del progetto la nostra idea è quella di attirare l’attenzione di altri sviluppatori e di creare un team di lavoro per realizzare le versioni future dell’applicazione.

Dal punto di vista tecnico, invece, abbiamo già definito una serie di priorità che riguarderanno le future versioni della nostra applicazione.

Multimodalità

La possibilità di fruire dei contenuti del blog mediante una serie di interfacce il più ampia possibile è una caratteristica qualificante del progetto e così sarà anche in futuro e l’obiettivo è di migliorare la qualità delle interfacce già presenti e di aggiungerne delle nuove.

Per quanto riguarda il miglioramento delle interfacce esistenti i punti salienti sono:

Incremento delle piattaforme di IM [IME06] supportate: anche se XMPP [XMP04] è uno standard al momento le piattaforme che si basano su di esso non sono sicuramente leader di mercato, AVBlog dovrà essere in grado di colloquiare con sistemi di messaggistica proprietari ma diffusi quali AIM [AIM06], MSN [MSN06b] e Yahoo [YAH06].
Possibilità di effettuare via IM operazioni sui commenti, inserimento e cancellazione, e di migliorare l’interfaccia di consultazione dei post.
Implementazione di ATOM [ATO05] per le comunicazioni con software di tipo desktop client in alternativa a XML-RPC [XML99]. Atom 1.0 è stato approvato di recente e Blogger lo utilizza al posto delle vecchie API [API99] basate su XML-RPC [XML99] per comunicare con software di terze parti. Il supporto di questo standard permetterà ad AVBlog di ampliare ulteriormente il parco di applicazioni desktop con le quali può interagire.
Implementazione di un’interfaccia Flash ottimizzata per l’utilizzo con terminali mobili dotati di questa tecnologia.
Implementazione di un’interfaccia basata su SMS; i questo caso l’obiettivo è quello di dare la possibilità al blogger di essere avvisato con questo mezzo in caso di inserimento di commenti o di errori nell’applicazione. Data la scarsa quantità di testo disponibile risulta fattibile tecnicamente ma di poca utilità pratica la possibilità di inserire post utilizzando messaggi SMS.

Nuove funzionalità

Per quanto riguarda, invece, funzionalità aggiuntive rispetto a quelle presenti esse saranno orientate allo sviluppo di nuovi plugin per quanto riguarda compiti specifici meno legati all’attività di blogging in senso stresso e all’implementazione diretta nell’applicazione dei miglioramenti legati alle attività relative alla gestione dei post.

Per quanto riguarda queste ultime saranno introdotte le seguenti funzionalità:

Generazione automatica di file PDF [PDF06] contenenti uno o più post.
Possibilità di creare gruppi di utenti legati a singoli post o a gruppi di post.
Utilizzo di ATOM [ATO05] per creare post basati su feed esterni; utile per realizzare Blog che contengono post da più blog (feed aggregator).
Nuova interfaccia di amministrazione da affiancare a quella attuale realizzata in flash.
Creazione di nuove skin.
Supporto di un numero maggiore di lingue.
Possibilità di importare dati dalle piattaforme di Blog più diffuse; questo permetterebbe a chi possiede già un Web Log di importare tutti i suoi post e relativi commenti.
Possibilità per il lettore di scegliere una skin personalizzata.
Possibilità per il lettore di personalizzare la tipologia dei post visualizzati in home page.

A nuovi plugin (o al potenziamento di quelli esistenti) sarà invece demandato lo sviluppo di funzionalità più specifiche:

Sondaggi: legati a post specifici o meno, permettono al blogger di richiedere al lettore l’opinione su determinati argomenti; il progetto è quello di rendere possibile la realizzazione di sondaggi sia a domanda singola che domanda multipla.
Forum: si tratta di una tipologia particolare di applicazione Web. Il nostro progetto non prevede la realizzazione di un forum completo e ricco di funzionalità ma di una procedura relativamente semplice che renda però possibile il superamento dei commenti come strumento di interazione con il blogger ed altri lettori quando la discussione diventa complessa e coinvolge più persone.
Chat: un semplice modulo che permetta al lettore di contattare il blogger via IM direttamente dall’interfaccia Web.

Bibliografia

[MOB05], Autori Vari, “/Alfies Moblog”, http://moblog.co.uk/view.php?id=77571, 2005

[COL06], “Macromedia Products: Coldfusion MX 7”, http://www.macromedia.com/software/coldfusion/, 2006

[BOI02], Bob Boiko, “Content Management Bible”,Hungry Minds, 2002

[JEN02], Tim Jennings, “Defining the Document and Content Management Ecosystem”, The Butler Group, 2002

[SHI03], Clay Shirky, “Social Software and the Politics of Groups”,http://shirky.com/writings/group_politics.html, 2003

[WIK06a] “Social Software – Wikipedia thre free encyclopedia”, http://en.wikipedia.org/wiki/Social_software, 2006

[WIK06b] “Wikipedia the free encyclopedia”, http://www.wikipedia.org/, 2006

[WIK06c] “Wiki history”, http://c2.com/cgi/wiki?WikiHistory, 2006

[ADO06a] “Adobe Labs - Wiki”, http://labs.macromedia.com/wiki, 2006

[CHO06], “ChoralWiki”, http://www.cpdl.org/wiki/index.PHP [PHP06]/Main_Pagem, 2006

[WEB06], “WebSemantique”, http://www.Websemantique.org, 2006

[WIK06d], “Wikimedia Commons”, http://commons.wikimedia.org, 2006

[WIK06e], “Wiki di Ubuntu-it”, http://wiki.ubuntu-it.org/, 2006

[MEL06], “Melug Wiki”, http://www.messinalug.org/mediawiki/index.php/MelugWiki, 2006

[STA06], “Start – I Wiki di Andrea Landrisina”, http://www.landriscina.it/wiki/doku.PHP [PHP06], 2006

[CAM06], “CamelCase – Wikipedia, the free Encyclopedia”, http://en.wikipedia.org/wiki/CamelCase, 2006

[WIK06f], “WikiEngines”, http://c2.com/cgi/wiki?WikiEngines, 2006

[BAR06], “Jorn Barger”,http://www.robotwisdom.com, 2006

[MAI04], Sergio Maistrello, “Come si fa un BLOG”, Tecniche Nuove, 2004

[DOV03], MaurizioDovigi, “WeBlog,personal publishing”, Apogeo, 2003

[BLO06a], “Blog – Wikipedia, the free Encyclopedia”, http://en.wikipedia.org/wiki/Blog, 2006

[BLO06b], “Blogger”, http://www.blogger.com, 2006

[QUI01], William Quick, “DailyPundit.com”, http://www.iw3p.com/DailyPundit/2001_12_30_dailypundit_archive.php#8315120, 2001

[SIF06], “Sifry’s Alert”,http://www.sifry.com/alerts/archives/000419.html, 2006

[BAL05], Carlo Baldi, Roberto Zainello, “Penne Digitali”, CDG, 2005

[GOL97], Michael H. Goldhaber, “The Attentino Economy and the Net”, http://www.firstmonday.dk/issues/issue2_4/goldhaber, 1997

[GRA03], Giuseppe Granirei, “Fenomenologia dei Blog” Internet News, ottobre 2003

[VAL06], Paolo Valdemarin, “Paolo Valdemarin Weblog” , http://paolo.evectors.it/italian/, 2006

[KAM02], Peter Kaminski, “Is Blogging Now a Necessity?”, http://www.istori.com/log/archives/00000189.html, 2002

[SOC06], “Social Enterprise Wiki”, http://www.socialtext.com/, 2006

[BEP06], Beppe Grillo, “Blog di Beppe Grillo”,http://www.beppegrillo.it, 2006

[PER06], “Permalink – Wikipedia, the free Encyclopedia”, http://en.wikipedia.org/wiki/Permalinks, 2006

[VAN06], Thomas Vander Wal, “Folksonomy” , http://www.vanderwal.net/random/category.php?cat=153, 2006

[FLI06], Filckr!, “Flick!”, http://www.flickr.com, 2006

[DEL06], Del.icio.us, http://del.icio.us/, 2006

[TAG06], “Technorati TAGS”, http://www.technorati.com/tags/, 2006

[CAP05]. “The Captcha Project”,http://www.captcha.net/, 2005

[TRA02], “TrackBack Technical Specification”, http://www.sixapart.com/pronet/docs/trackback_spec

[PIL02], Mark Pilgrim, “XML.com: What is RSS”, http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html, 2002

[ATO05], Internet Engineering Task Force, “The Atom Syndication Format”, http://www.ietf.org/rfc/rfc4287.txt?number=4287, 2005

[XML06], W3 Reccomendation, “Extensible Markup Language (XML)”, http://www.w3.org/XML/, 2006

[GOO06], “Google Reader”, http://www.google.com/reader/lens/, 2006

[TAL05], “Google Talk”, http://www.google.com/talk/, 2005

[API06], “Application Programming Interface”, http://it.wikipedia.org/wiki/Application_programming_interface, 2006

[WOR06], “WordPress”, http://www.wordpress.org, 2006

[CSS99], W3c, “Cascading Style Sheets”, http://www.w3.org/Style/CSS/, 1999

[MSN06a], “Msn Spaces”, http://spaces.msn.it, 2006

[VIR06], “Virgilio”, http://www.virgilio.it, 2006

[TIS06], “Tiscali”, http://www.tiscali.it, 2006

[EXC06], “Excite”, http://www.excite.it, 2006

[LIB06], “Libero”, http://www.libero.it, 2006

[SPL06], “Splinder”, http://www.splinder.com, 2006

[LIV06], “LiveJournal”, http://www.livejournal.it, 2006

[TYP06], “TypePad”, http://www.typepad.com, 2006

[PHP06], “PHP: Hypertext Preprocessor”,http://www.php.net/, 2006

[MOV06], “Movable Type”, http://www.sixapart.com/movabletype, 2006

[IME06], “Instant Messaging”, http://it.wikipedia.org/wiki/Instant_messaging, 2006

[WIN05], “Start Something”, http://www.windows.com, 2005

[LIN06], “The Linux Kernel Archives”, http://www.kernel.org/, 2006

[MAC06a], “Apple Mac OS X”, http://www.apple.com/macosx/, 2006

[ASP06], “ASP.NET Web: The Official Microsoft ASP.NET 2.0 Site”, http://asp.net/, 2006

[PYT06], “Python Programming Language”, http://www.python.org/, 2006

[PER06], “Perl.com”, http://www.perl.com/, 2006

[JAV06], “Java Technology”, http://java.sun.com/, 2006

[ADO06b], “Adobe”, http://www.adobe.com, 2006

[CFM06], “Macromedia – Coldfusion MX 7 LiveDocs”, http://livedocs.macromedia.com/coldfusion/7/index.html, 2006

[BLU06], “BlueDragon”, http://www.newatlanta.com/products/bluedragon/, 2006

[RAI06], “Railo”, http://www.railo.ch/en/, 2006

[MAC06b], “Macromedia”, http://www.macromedia.com, 2006

[J2E06], “Java Platform, Enterprise Edition”, http://java.sun.com/javaee/index.jsp, 2006

[IBM06], “IBM WebSphere Software”, http://www-306.ibm.com/software/websphere/, 2006

[BEA06], “BEA Systems – BEA WebLogic”, http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic, 2006

[TOM06], “Apache Tomcat”, http://tomcat.apache.org/, 2006

[JET06]. “Jetty Java HTTP Servlet Server”. http://jetty.mortbay.org/jetty/, 2006

[HTM06], “W3C HTML Home Page”, http://www.w3.org/MarkUp/, 2006

[XML04], W3C, “Extensible Markup Language (XML) 1.1”, http://www.w3.org/TR/2004/REC-xml11-20040204/, 2004

[HTM02], Autori Vari, “HTML 4.01 Guida per il programmatore”, Apogeo, 2002

[XHT02], W3 Reccomendation, “[XHT02] 1.0: The eXtensible HyperText Markup Language”, 2002

[BEL03], Giampaolo Bellavite, “Corso Base di Coldfusion [COL06] MX”, http://www.html.it/Coldfusion [COL06]_mx/, HTML.it, 2003

[OOP95], “Object-Oriented Programming Concept”, http://java.sun.com/docs/books/tutorial/java/concepts/, 2006

[MVC02], “Design Patterns: Model-View-Controller”, http://java.sun.com/blueprints/patterns/MVC.html, 2006

[SGM04], “Overview of SGMIL Resources”, http://www.w3.org/MarkUp/SGML/, 2004

[DTD06], “Document Type Definition”, http://en.wikipedia.org/wiki/Document_Type_Definition, 2006

[SCH00], “W3C XML Schema”, http://www.w3.org/XML/Schema, 2000

[PRO01], Autori Vari, “Professional XML”, Wrox Press Ltd, 2001

[XPA99], “XML Path Language”, http://www.w3.org/TR/xpath, 1999

[XSL99], “XSL Transformations”, http://www.w3.org/TR/xslt, 2006

[XMP04], “Extensible Messaging and Presence Protocol (XMPP)”, http://www.xmpp.org/specs/rfc3920.html, 2004

[SMP99], “SMS Forum”, http://www.smpp.org/, 2006

[VER06], “Verity”, http://www.verity.com/, 2006

[OFF06], “Home Page Microsot Office Online”, http://office.microsoft.com, 2006

[PDF06], “Portable Document Format”, http://en.wikipedia.org/wiki/Portable_Document_Format, 2006

[KUL02], Lance Kulkarni, “SQL 99 Bible”, Paperback, 2002

[UTF05], “UTF-8 and Unicode Standards”, http://www.utf-8.com/, 2005

[UNI05], “What is UNICODE?”, http://www.unicode.org/standard/WhatIsUnicode.html, 2005

[W3C06], “World Wide Web Consortium”, http://www.w3.org, 2006

[CS199], “Cascading Style Sheets, level1”, http://www.w3.org/TR/CSS1, 1999

[CS205], “Cascading Style Sheets, level2 revision 1”, http://www.w3.org/TR/CSS21/, 2005

[CS305], “Cascading Style Sheets, level1”, http://www.w3.org/Style/CSS/current-work, 2005

[WCA99], W3C, “Web Content Accessibility Guidelines 1.0”, http://www.w3.org/TR/1999/WAI-WebCONTENT-19990505/, 1999

[JAB06], “Jabber: Open Instant Messaging and a Whole Lot More, Powere by XMPP”, http://www.jabber.org/, 2006

[IET06], “IETF Home page”, http://www.ietf.org, 2006

[PRO04], DJ Adams, “Programming Jabber: Extending XML Messaging”,O’Reilly 2004

[RFC04a], Ietf, “RFC 3920”, http://www.ietf.org/rfc/rfc3920.txt?number=3920, 2006

[RFC04b], Ietf, “RFC 3921”, http://www.ietf.org/rfc/rfc3920.txt?number=3921, 2006

[GOO06], “Google”, http://www.google.com, 2006

[SKY06], “Skype”, http://www.skype.com, 2006

[TCP06], “Transmission Control Protocol”, http://en.wikipedia.org/wiki/Transmission_Control_Protocol, 2006

[SOA03], “Soap Specifications”, http://www.w3.org/TR/soap/, 2003

[JAB04], William Wright, Dana Moore, “Jabber Developer's Handbook”, Paperback, 2004

[XML99], Dave Winer, “XML-RPC Specifications”, http://www.xmlrpc.com/spec, 1999

[BLO03], “Blogger API”, http://www.blogger.com/developers/api/1_docs/, 2003

[LIV06]. “LiveJournal Developer Information”, http://www.programmableweb.com/api/LiveJournal, 2006

[MOV02], “Movable Type: Programmatic Interfaces”, http://www.sixapart.com/movabletype/docs/mtmanual_programmatic, 2002

[PIN06], “Ping-o-Matic”, http://pingomatic.com/, 2006

[MYN06], “MyNetscape”, http://www.mynetscape.com, 2006

[AOL06], “AOL.com”, http://www.aol.com, 2006

[RDF04], “RDF/XML Syntax Specification”, http://www.w3.org/RDF/, 2004

[RSS00], W3 Recomemendation, “RDF Site Summary (RSS)”, http://www.w3.org/2002/01/rss/rss1_namespace, 2000

[RSS05], Berkman Center. “RSS 2.0 Specifications”, http://blogs.law.harvard.edu/tech/rss, 2005

[DUB06], “Dublin Core Initiative”, http://dublincore.org/, 2006

[RFC05]. “RFC4287 - The Atom Syndication Format”, http://www.ietf.org/rfc/rfc4287.txt?number=4287, 2005

[WYS06], “WYSIWYG”, http://it.wikipedia.org/wiki/WYSIWYG, 2006

[FCK05]. “FCKEDITOR: The text editor for internet”, http://www.fckeditor.net/, 2005

[TIN06], “Javascript Content Editor by Moxiecode Systems AB”, http://tinymce.moxiecode.com/index.PHP [PHP06], 2006

[JDB06]. “JDBC Technology”, http://java.sun.com/products/jdbc/ , 2006

[WAT02], “Digital Watermarking World: Introduction”, http://www.watermarkingworld.org/intro.html, 2002

[QUM06], “Qumana blog editor and blogging tools”, http://www.qumana.org, 2006

[WBL05], “w.bloggar”, http://www.wbloggar.com/, 2005

[BLJ06], “BlogJet”, http://blogjet.com/, 2006

[MOB06], “MoBlog”, http://en.wikipedia.org/wiki/Moblog, 2006

[FOR05a], Ben Forta, “Coldfusion [COL06] MX Web Application Construction Kit”, Macromedia Press, 2005

[FOR05b], Ben Forta, “Advanced Coldfusion [COL06] MX Application Development”, Macromedia Press, 2005

[UUI06]. “UUID”, http://en.wikipedia.org/wiki/UUID, 2006

[CGI96], “Common Gaeway Interface”, http://hoohoo.ncsa.uiuc.edu/cgi/, 1996

[GPL91], “General Public License”, http://www.gnu.org/copyleft/gpl.html#TOC1, 1991

[UTI03], Paul Hastings, “utils.cfc”, 2003

[ISO99], “ISO 639 language codes” , http://www.w3.org/WAI/ER/IG/ert/iso639.htm, 1999

[XML03], “Roger Benningfield”, http://support.journurl.com/users/admin/index.cfm?mode=article&entry=669, 2003

[TCD03], “The Coolest DHTML Calendar”, http://sourceforge.net/projects/jscalendar, 2003

[MYS06], “MySql”, http://www.mysql.com/, 2006

[ORA06], “Oracle Database”, http://www.oracle.com/database/index.html, 2006

[POS06], “PostgreSQL: The world’s most advanced open source database, http://www.postgresql.org/, 2006

[SQL06], “Microsoft SQL Server”, http://www.microsoft.com/sql/default.mspx, 2006

[MET02], “MetaWeblog API”, http://www.xmlrpc.com/metaWeblogApi, 2002

[JAV01], “Package: Java.io”, http://Java.sun.com/j2se/1.3/docs/api/Java/io/package-summary.html, 2001

[JAV03a], “Package: Java.awt”, http://Java.sun.com/j2se/1.4.2/docs/api/Java/awt/package-summary.html, 2003

[JAV03b], “Package Javax.imageio”, http://Java.sun.com/j2se/1.4.2/docs/api/Javax/imageio/package-summary.html, 2003

[AIM06], ”AIM”, http://www.aim.com/, 2006

[MSN06b], “MNS Messenger”, http://join.msn.com/messenger/overview/, 2006

[YAH06], “Yahoo Messenger”, http://messenger.yahoo.com/, 2006

Tesina di Andrea Veggiani fonte www.veggiani.it

Fine articolo Blog e web

Blog e web

Collegamenti utili gratuiti

Disclaimer : gli obiettivi di questo sito sono il progresso delle scienze e delle arti utili in quanto pensiamo che siano molto importanti per il nostro paese i benefici sociali e culturali della libera diffusione di informazioni utili. Tutte le informazioni e le immagini contenute in questo sito vengono qui utilizzate esclusivamente a scopi didattici, conoscitivi e divulgativi. Le informazioni di medicina e salute contenute nel sito sono di natura generale ed a scopo puramente divulgativo e per questo motivo non possono sostituire in alcun caso il consiglio di un medico (ovvero un soggetto abilitato legalmente alla professione). In questo sito abbiamo fatto ogni sforzo per garantire l'accuratezza dei tools, calcolatori e delle informazioni, non possiamo dare una garanzia o essere ritenuti responsabili per eventuali errori che sono stati fatti, i testi contenuti nel sito sono di proprietà dei rispettivi autori. Se trovate un errore su questo sito o se trovate un testo o tool che possa violare le leggi vigenti in materia di diritti di autore, comunicatecelo via e-mail e noi provvederemo tempestivamente a rimuoverlo.