Il database ad oggetti (WODBMS)

L'acronimo WODBMS vuol dire "Wedgefish Object Database Management System".
Esso consiste in una base di dati che mette al centro tipi, oggetti e relazioni, e che consente funzionalità non presenti nei database convenzionali, come la localizzazione del contenuto e campi indicizzati numericamente.
Anche senza alcuna conoscenza di linguaggio SQL, è possibile scrivere codice che interroghi il WODBMS e restituisca non solo una serie di oggetti in base a determinati criteri, ma anche valori estrapolati dagli oggetti ad essi relazionati, tutto sottoforma di un unico array o oggetto⁽¹⁾.
Il WODBMS è una componente essenziale di Wedgefish, sulla quale si basano molte delle sue potenzialità, ed è quindi sempre abilitato. Le parti che si occupano nello specifico di leggere e scrivere i dati sono state racchiuse in un modulo, affinché sia possibile modificarne l'implementazione senza dover modificare il nucleo del sistema⁽²⁾.

Di base, Wedgefish è configurato per utilizzare il modulo wodbmsmysql, che consente di gestire il WODBMS come un'astrazione su un insieme di tabelle MySQL, ed offre molteplici vantaggi:

• rispetto dell'integrità referenziale (tramite utilizzo di tabelle InnoDB)
• utilizzo estensivo di indici per ottimizzare le prestazioni
• indice FULLTEXT sulla tabella dei testi localizzati, per costruire motori di ricerca
• utilizzo di normali tabelle contenenti valori numerici o stringa per veloci ricerche comparative
• possibilità di far girare MySQL su un server separato o cluster di server, con replicazione
• supporto nativo di condizioni in formato SQL e altre funzioni SQL
  

Sarà disponibile, nelle prossime versioni di Wedgefish, un modulo wodbmssql, che consentirà di utilizzare come base per il WODBMS qualunque tipo di database basato sul linguaggio SQL (come PostgreSQL e SQLite) mediante interfacciamento al modulo specifico sviluppato per Wedgefish (ad es. mysql, postgresql, sqlite).
Tale architettura consentirebbe anche di creare un'implementazione del WODBMS totalmente indipendente da SQL (ad es. basata su files di testo o binari) sebbene questo implicherebbe notevole lavoro.

Qualora le esigenze di programmazione lo richiedano, è sempre possibile affiancare al WODBMS anche altri database convenzionali, per memorizzare e recuperare dati in forma tabellare mediante normali istruzioni SQL, sebbene molte funzionalità non siano disponibili con tali tipi di database⁽³⁾.

Di seguito verranno illustrati i concetti fondamentali alla base del WODBMS.

Siti web

Un unico WODBMS può memorizzare teoricamente i dati di centinaia di migliaia o milioni di siti web.  Questo è l'ideale per portali di blog o siti personali, siti di piccole aziende e in genere Application Service Providers che altrimenti necessiterebbero di miriadi di database separati con duplicazione di funzionalità e conseguente difficoltà di gestione.
Considerando le sue prestazioni, tuttavia, il WODBMS è adatto anche per progetti con una base di dati molto grande.
L'integrità dei dati è garantita, come già illustrato sopra, dal motore SQL sottostante.
Un altro vantaggio derivante dalla memorizzazione di molti siti in un unico database è la possibilità di stabilire relazioni tra oggetti in siti differenti (cosa altrimenti impossibile con database convenzionali), la ricerca di contenuti in un insieme di siti, come su un portale a tema, e quella di dare diritti di visualizzazione e modifica a determinati utenti di più siti web ⁽⁴⁾.
Se proprio lo si desidera, è anche possibile utilizzare un WODBMS diverso per ogni sito o per insiemi di siti, configurando istanze multiple della piattaforma (come virtual host separati di Apache) che fanno capo allo stesso codice di sistema, dei moduli e dei templates (tramite link simbolici, oppure duplicando il codice), ma che abbiano ciascuna la propria configurazione indipendente. Comunque, l'elevato livello di ottimizzazione del database SQL su cui è costruito il WODBMS e l'utilizzo massiccio di indici dovrebbero rendere inutile questa esigenza.

Classi di oggetti

Le classi in Wedgefish definiscono le proprietà degli oggetti ed i loro attributi.
Potete immaginarle come l'equivalente delle tabelle di un database convenzionale, ma con molte particolarità aggiuntive, tra cui:

• possibilità di definire diritti di accesso in lettura e scrittura a liste di utenti e gruppi (ACL)
• possibilità di nascondere la classe nell'amministrazione agli utenti che non possono modificarne gli oggetti
• relazioni con altre classi, potendo specificare anche la proprietà della classe relazionata da considerare
• presenza di attributi su ogni campo, per facilitare la generazione automatica di un'interfaccia grafica di dataentry (numero di tab, riga, posizione nella riga, dimensione dei campi, didascalie, tipo di rappresentazione grafica ecc...)

Le classi sono uniche per ciascun sito web, e ciò consente di personalizzarle liberamente: è quindi possibile ad esempio avere attributi specifici per gli utenti di un particolare sito per memorizzare le loro preferenze e altri dati, variare la posizione nell'interfaccia di dataentry di determinati campi, renderle modificabili solo a determinati gruppi di utenti ecc...

Oggetti (items)

In Wedgefish, ogni tipo di dato è memorizzato come un item: dagli utenti ai gruppi di utenti, dalle pagine dell'amministrazione a quelle del sito, dalle categorie ai menu, dai commenti alle immagini ecc...
Questa uniformità consente di applicare gli stessi strumenti (quali le relazioni, le ACL, l'Editor Universale, l'esportazione XML...) a qualunque tipologia di oggetto, senza dover scrivere nuovo codice e modificare quello esistente ogni volta che se ne aggiunge una nuova, come accadrebbe con la normale programmazione PHP/SQL.

Potete immaginare gli item come righe di un database, con un numero variabile di campi. Ogni item è associato ad una classe, in modo da poterlo raggruppare facilmente assieme agli altri item dello stesso tipo (Utenti, Pagine Web ecc...) ma non è assolutamente legato ad essa in maniera rigida: è possibile quindi trasformare con semplicità un item di un determinato tipo in qualcosa di completamente diverso, semplicemente variandone il tipo, ed il valore delle proprietà presenti con lo stesso nome anche nella nuova classe verranno mantenute.
Ad esempio potremmo convertire una Pagina Web in un indice di Sezione, oppure un Commento in una Pagina Web, completando semplicemente i valori delle proprietà mancanti nella precedente classe.

A ciascun item è possibile associare una o più "web views" ovvero rappresentazioni su web del contenuto dell'item.
Una "web view" è composta da un URL, una view ed un controller.
Il controller legge le proprietà dell'item dal WODBMS e li utilizza per popolare il contenuto della view.
In questo modo, è possibile avere più di un URL che punta allo stesso contenuto, che può tuttavia essere trattato e visualizzato in maniera differente (variando il controller o la view).

Proprietà degli oggetti

Ciascun oggetto può avere un numero variabile di proprietà (dette anche variabili), solitamente corrispondenti a quelle definite nella sua classe.
Le proprietà possono essere di vario tipo, alcune di queste corrispondenti a quelle di un database convenzionale, altre di tipo completamente nuovo. Ogni tipo è identificato da una lettera:

• N - Numerico (interi con segno a 32 bit)
• S - Stringa (testi non localizzati di lunghezza da 1 a 255 caratteri)
• T - Testo localizzato (un testo con lunghezza da 1 a 16777215 caratteri, che può essere localizzato in tutte le lingue abilitate nel sito)
• R - Relazione (contiene l'identificatore dell'item relazionato; l'effettivo nome del campo di tale item da considerare come chiave nell'importazione e nell'esportazione è indicato nella classe dell'oggetto)
• H - HTML localizzato (un testo in formato HTML da 1 a 16777215 caratteri, localizzabile in tutte le lingue abilitate nel sito, i cui link verranno automaticamente corretti per funzionare qualunque sia l'URL della pagina)
• E - Indirizzo Email (che viene memorizzato nel WODBMS solo se valido sintatticamente, ed il cui formato verrà controllato dall'Editor Universale a lato client⁽⁵⁾)
• P - Password (che memorizza solo l'hash md5 della password in questione e mai la password in chiaro)
• B - Booleano (vero o falso, ma anche SI/NO in diverse lingue, 0/1 e tutto ciò che possa essere interpretato in due modi nettamente opposti)
• D - Data (un particolare formato, con indicazione di giorno, mese, anno, ora e minuti ma senza secondi, che consente di rappresentare in 32 bit tutti gli anni da 0 a 4095)
• C - Colore (in formato 32 bit con 8 bit per la trasparenza, 8 bit per il rosso, 8 bit per il verde e 8 bit per il blu)
• A - Indirizzo IP v4 (in formato xxx.xxx.xxx.xxx)

Esiste un insieme di proprietà di tipo Stringa che, pur non essendo definite in alcuna classe, possono tuttavia essere assegnate su ogni tipo di oggetto: i META tags, utilizzati dai browser per fornire indicazioni ai motori di ricerca sul contenuto delle pagine.

Una caratteristica fondamentale delle proprietà, che le distingue nettamente dalle colonne delle tabelle di un database convenzionale, è quella di poter essere indicizzate (multiple).
Quindi possiamo avere, ad esempio, un utente con più numeri di telefono, un articolo con più autori e più fonti, una serie di parole chiave (meta_keyword) associate ad una pagina web ecc...
Allo stesso modo un testo o HTML localizzato può essere tradotto in più lingue, senza dover creare versioni multiple dell'item, ma mantenendo tutte le traduzioni associate allo stesso oggetto.
Nota: Nell'implementazione MySQL del WODBMS, ogni proprietà di un item è memorizzata in una riga di una tabella separata (di tipo numerico, stringa, testo o relazione) relazionata con l'item stesso e indicizzata a partire da 1. In questo modo le proprietà sono associate agli oggetti con una relazione uno a molti, ed è possibile estendere all'infinito il numero di indici delle proprietà, cosa impossibile con un database convenzionale, nel quale sarebbe necessario definire una serie di tabelle di relazione per ciascuna proprietà multipla, con notevole dispendio di tempo di sviluppo.

ACL (Liste di Controllo di Accesso)

Le ACL costituiscono un potente mezzo per definire, in maniera completamente indipendente dalla programmazione, che alcuni oggetti debbano essere visualizzabili e/o modificabili solo da determinati gruppi di utenti o utenti singoli.
Vengono ad esempio utilizzate per limitare l'accesso alle pagine dell'amministrazione agli utenti abilitati, ma possono avere impieghi illimitati, quali ad esempio fare in modo che solo gli utenti registrati possano inviare commenti agli articoli di un blog, caricare nuove foto nelle gallerie di immagini, inserire nuovi articoli e modificare gli esistenti.

Ogni classe ha la sua ACL, che definisce quali gruppi di utenti e utenti singoli possono, in mancanza di altre regole (vedi di seguito) visualizzare e creare nuovi oggetti del loro tipo e modificare quelli esistenti.
Ogni item dispone inoltre di una sua ACL, che consente di stabilire quali utenti e gruppi possono visualizzare e modificare i suoi contenuti (tramite l'Editor Universale oppure istruzioni incluse nei controller).
Se l'ACL di un item è stata lasciata vuota, l'item erediterà le ACL della classe a cui appartiene. Altrimenti, l'ACL impostata nell'item prevarrà sull'ACL della sua classe.
Se l'ACL sia dell'item sia della sua classe sono entrambe vuote, l'oggetto risulterà modificabile da chiunque (funzionalità molto utile nell'implementazione di Wiki).
Esistono circostanze nelle quali è desiderabile che l'ACL non venga presa temporaneamente in considerazione. Ad esempio potremmo avere un form sul sito che consente, online, di registrarsi come nuovo utente, oppure di inviare semplicemente una richiesta di registrazione che verrà poi presa in considerazione dagli amministratori.
In questo caso è possibile disabilitare temporaneamente il controllo delle ACL, limitatamente alla successiva istruzione di lettura, creazione o modifica di un item. Ciò può essere fatto chiamando la funzione wos_ignore_acl().
Spetta in questo caso al codice del controller o della funzione accertarsi di quanto viene svolto sul WODBMS.
Il controllo delle ACL viene ripristinato automaticamente al termine dell'istruzione eseguita sul WODBMS.

Come modificare e aggiungere classi nel WODBMS

Nella versione attuale di Wedgefish, la procedura per creare nuove classi e modificare quelle esistenti consiste in questi tre passi:

• esportare la classe o le classi in un file XML
• modificare la definizione della classe, oppure copiare e incollare una definizione esistente e modificarla se si desidera aggiungere una nuova classe
• reimportare il file XML nel sistema, avendo cura di scegliere di sovrascrivere le classi con lo stesso nome

In una versione futura della piattaforma, sarà presente un'interfaccia web che consentirà di creare nuove classi e modificare quelle esistenti, partendo, se lo desidera, da quelle contenute nei modelli dei moduli per derivare nuove classi personalizzate in base alle necessità del sito.