Presentazione tenuta al Linux Day 2005 di Ancona. Un esempio concreto di applicazione basata su Plone per la gestione collaborativa di informazioni strutturate

1. Eugenio
Prototipazione rapida di applicazioni tramite Plone
26/11/2005 – Eugenio

2. Cos'è Eugenio
Eugenio è un sistema web di gestione e
●
pubblicazione dati nell'ambito del progetto “didattica
dell'Archivistica”
Il prof. Federico Valacchi e la dott. Paola Pizzichini
●
hanno ideato e coordinano il progetto nel contesto del
Dip. di Scienze storiche, artistiche, documentarie e del
territorio dell'Università degli Studi di Macerata
26/11/2005 – Eugenio

3. Progetto “didattica dell'Archivistica”
Promosso dalla cattedra di Archivistica dell'Università
degli Studi di Macerata, ha come obiettivi:
il monitoraggio complessivo dell'offerta formativa
●
archivistica nelle università italiane nelle diverse
soluzioni adottate nei singoli atenei in base
all'autonomia conferita dalla riforma
la valutazione dell'efficacia dell'offerta formativa in
●
relazione alle nuove esigenze professionali e
all'evoluzione della disciplina
26/11/2005 – Eugenio

4. Esigenze del progetto
Superare la scarsa visibilità della disciplina in ambito
●
accademico attraverso uno strumento di consultazione e
ricerca dedicato.
Superare le difficoltà di accesso a dati altrimenti dispersi
●
nei siti delle diverse università e non omogenei, fornendo
un canale di consultazione unico attraverso un portale.
Avere dei dati costantemente aggiornati e controllati
●
attraverso il diretto intervento dei docenti per l’inserimento
e la modifica dei dati.
26/11/2005 – Eugenio

5. Il punto di partenza di Eugenio
Progetto “didattica dell'Archivistica”
●
analisi di base sintetizzata in una applicazione MS
●
Access con schede per l'inserimento organico dei dati.
le schede principali: docenti e discipline
●
26/11/2005 – Eugenio

6. Obiettivi di Eugenio
Navigazione più flessibile dei dati
●
pubblicazione su web dei dati disponibili nel
●
database MS Access
desiderabile: gestione web dei dati (gestione
●
contenuti, workflow di pubblicazione)
(tutto questo in tempi stretti..)
26/11/2005 – Eugenio

7. Strumenti
Zope ­ application server
●
SQLite ­ DB relazionale server­less
●
Plone ­ content management system
●
Archetypes ­ class generator
●
(tutti gli strumenti proposti sono open source e multi­piattaforma:
libertà di scelta in fase di rilascio dell'applicazione)
26/11/2005 – Eugenio

8. Cos'è Zope
Application Server Open Source:
●
gestione permessi e sicurezza
–
gestione memorizzazione
–
gestione protocolli di comunicazione (http, ftp, xml­rpc, ...)
–
(collante naturale per costruire applicazioni web)
non si basa su LAMP (Linux, Apache, MySQL, PHP)
●
(per questo a volte può risultare ostico agli addetti ai lavori
abituati a tale paradigma)
26/11/2005 – Eugenio

9. Zope in nuce
Zope significa Z­object Publishing Environment: gli
●
oggetti sono alla base dell'approccio proposto da Zope
Zope è scritto in Python (gira su Linux, Windows, Mac
●
OS X, BSD, Solaris) e dispone di un web server e di un
database a oggetti “proprietari”
26/11/2005 – Eugenio

10. SQLite
Dati estratti da DB Access e importati in DB SQLite per
●
costruire velocemente navigazione e interfaccia web
SQLite implementa un motore di database SQL tramite
●
una piccola libreria C autoconsistente (può essere
inglobata in applicazioni più vaste)
SQLite non ha configurazioni “lato server”
●
SQLite, tra l'altro, implementa i DB in un singolo file e
●
supporta le transazioni
26/11/2005 – Eugenio

11. Interagire con SQLite
Implementazione di un servizio python per estrarre
●
dati dal DB relazionale e renderli disponibili in Zope
(Zope dispone del suo DB a oggetti, ma può facilmente
pubblicare dati memorizzati in database relazionali!)
servizio capace di astrarre il modello a oggetti adottato
●
(atenei, docenti, discipline, ..) sul DB relazionale (per
svincolare l'interfaccia dalle “storture relazionali”)
(tenendo a mente l'obiettivo della gestione dati via web, sarà
rapido il passaggio dal modello relazionale a quello a oggetti)
26/11/2005 – Eugenio

12. Fase 1: prototipo su DB relazionale
Il prototipo basato sui dati disponibili ha permesso una
rapida costruzione dell'interfaccia web, favorendo:
accettazione della struttura dati adottata per la
●
pubblicazione in base al progetto di ricerca iniziale
accettazione dell'architettura informativa e
●
dell'interfaccia di navigazione web
26/11/2005 – Eugenio

13. Fase 1: architettura informativa
Metafora dei punti di accesso: informazioni navigabili in
●
modo esteso partendo da liste sintetiche compilate per
tipo di oggetto (atenei, docenti, discipline)
schede informative: ogni oggetto viene presentato
●
attraverso una scheda che riporta le informazioni
fornite ed i link verso le schede degli oggetti correlati
(es. da una scheda disciplina si risale con un click alla scheda del
docente, per ottenere la sintesi di tutte le discipline a lui legate)
26/11/2005 – Eugenio

14. Fase 1: verso un CMS
Il sistema di pubblicazione web può essere alimentato
●
dal software Access di raccolta dati, ma questo
modello non può garantire coerenza e non­ridondanza
dell'informazione
l'obiettivo più ambizioso è inoltre quello di offrire
●
direttamente su web lo strumento di raccolta dati agli
interessati (lavorando così direttamente sui dati che
saranno pubblicati)
26/11/2005 – Eugenio

15. Cos'è Plone
Plone nasce come skin per CMF, Content
●
Management Framework: una raccolta di tool e servizi
capace di dare struttura e semplificare la costruzione di
CMS basati su Zope
oggi costituisce un caso di successo nel mondo Zope
●
ed è riconosciuto come uno dei CMS opensource più
potenti e versatili in circolazione
(spesso fondamento di intranet e servizi informativi dipartimentali:
implementazioni Plone molte valide non hanno visibilità pubblica)
26/11/2005 – Eugenio

16. Perchè Plone
L'avanzata tecnologia di base e la vivace comunità
●
garantiscono un costante miglioramento del prodotto
e lo sviluppo di numerose estensioni opensource
il concetto di framework favorisce la vita degli
●
sviluppatori che hanno necessità di verticalizzare le
funzioni basiche
l'interfaccia nativa è un ottimo punto di partenza per
●
ottenere una presentazione accessibile dei dati
26/11/2005 – Eugenio

17. Fase 2: prototipo su Z­Oggetti
Prossimo obiettivo: editare direttamente via web i dati
●
pubblicati tramite Zope
gli oggetti informativi attualmente galleggiano tra i
●
dati memorizzati nelle tabelle relazionali e le logiche
racchiuse dall'interfaccia di presentazione
uno Z­Object è un contenitore coerente di logica e
●
dati, capace di facilitare enormemente il compito degli
sviluppatori nel garantire transazionalità delle attività e
accesso secondo le logiche opportune
26/11/2005 – Eugenio

18. Archetypes:
costruire i propri oggetti informativi
Plone garantisce molte caratteristiche necessarie ad
●
un sistema web di gestione dati (sicurezza, profilazione
utenti, workflow di pubblicazione, ricerca, interfaccia, ..)
l'aspetto più sensibile soggetto a sviluppi ad hoc è dato
●
dall'implementazione degli oggetti informativi
(Plone non sa cosa siano atenei, docenti e discipline..)
Archetypes sopperisce a tale carenza offrendo un
●
meccanismo di generazione classi basato su “schemi”
26/11/2005 – Eugenio

19. Definire un oggetto Archetype
Archetypes permette di definire nei dettagli gli oggetti di
cui abbiamo bisogno in maniera dichiarativa:
● lo sviluppatore dichiara uno schema, composto da
elementi “field” (gli attributi dell'oggetto)
● ogni field ha una proprietà “widget” che definisce il suo
comportamento di interfaccia (visualizzazione,
modifica, ricerca)
● la logica specifica dell'oggetto viene generata
direttamente nei metodi della classe dell'oggetto
26/11/2005 – Eugenio

20. Dichiarare o implementare?
Dichiarare uno schema significa astrarre dai meccanismi
di funzionamento legati a quello schema:
● Archetypes gestisce la validazione, la memorizzazione,
le logiche di sicurezza dichiarate sui nostri fields
● Archetypes costruisce automaticamente le interfacce
standard di visualizzazione e modifica dei nostri oggetti
sulla base dei widget dichiarati per ogni attributo
(nel nostro caso abbiamo velocemente adattato l'interfaccia già
realizzata grazie all'approccio usato durante la fase 1 del progetto)
26/11/2005 – Eugenio

21. Gerarchia degli oggetti principali
Atenei, docenti e discipline possono relazionarsi tra loro
in modo molto libero
ateneo 1 ateneo 2
docente 1 docente 2 docente 3
disciplina 1 disciplina 2 disciplina 3
26/11/2005 – Eugenio

22. References: relazioni tra oggetti
Sebbene non si disponga dei classici meccanismi dei
●
DB relazionali, Archetypes implementa le relazioni tra
oggetti utilizzando i loro id univoci
(questo è preferibile rispetto a relazioni di tipo posizionale: le relazioni
continuano a funzionare anche se si sposta l'oggetto referenziato)
Archetypes permette di definire vincoli sui tipi di
●
oggetto ammessi dalla relazione, sulla sua
numerosità, etc.
26/11/2005 – Eugenio

23. Gerarchia degli oggetti disciplina
Ogni disciplina può
ateneo 1 ateneo 2
essere suddivisa in
vari moduli e vivere docente 2
docente 1
in diversi contesti
didattici disciplina 1
modulo 1 modulo 2
contesto 1 contesto 2 contesto 3
26/11/2005 – Eugenio

24. Contenimento: oggetti folderish
L'oggetto disciplina può contenere oggetti modulo e
●
contesto didattico, semplicemente dichiarandolo come
“folderish” (cioè capace di contenere oggetti)
gli oggetti modulo possono presentare relazioni con
●
uno o più dei contesti della disciplina (solo quelli della
disciplina!), inoltre possono relazionarsi con oggetti
docente (esterni alla disciplina)
26/11/2005 – Eugenio

25. Fase 2: interfacce di ricerca
Gli sviluppatori possono dichiarare quali fields dello
●
schema Archetypes sono ricercabili e in che modo
Archetypes offre meccanismi per implementare
●
automaticamente le interfacce di ricerca legate agli
specifici tipi di oggetti
(l'interfaccia di ricerca specializzata per le discipline presenta campi
diversi rispetto a quella relativa ai docenti)
26/11/2005 – Eugenio

26. Fase 3: verso la collaborazione
Ogni contributore di Eugenio dispone della sua area in
●
cui creare gli oggetti di cui ha bisogno
dopo aver completato l'inserimento dati, questi non
●
sono ancora visibili agli altri utenti: ne deve richiedere
la pubblicazione
il manager può approvare la richiesta di pubblicazione,
●
ovvero può respingerla, motivando la sua decisione
all'autore
(i contenuti pubblicati sono immediatamente disponibili a tutti gli utenti)
26/11/2005 – Eugenio

27. Grazie per l'attenzione!
Eugenio è consultabile all'indirizzo:
http://eugenio.unimc.it
●
Zope Italia Maurizio Delmonte
www.zope.it m.delmonte@kilanet.it
26/11/2005 – Eugenio