Eugenio Linux Day2005
Upcoming SlideShare
Loading in...5
×
 

Eugenio Linux Day2005

on

  • 927 views

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

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

Statistics

Views

Total Views
927
Slideshare-icon Views on SlideShare
924
Embed Views
3

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 3

http://www.slideshare.net 1
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Eugenio Linux Day2005 Eugenio Linux Day2005 Presentation Transcript

    • Eugenio Prototipazione rapida di applicazioni tramite Plone 26/11/2005 – Eugenio 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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 
    • 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