Pubblicato il:
Iscriviti alla newsletter
TEST NEWS TESTO LUNGO
Testo del comunicato
Indice
1.Caratteristiche del sistema
1.1.Tecnologia lato server
1.2.Struttura delle directory
1.3.Tecnologia lato client
2.Panoramica dell%u2019architettura
2.1.Logica del front-end
2.2.Sistema dei registri
2.3.Schema entit?elazioni del database di front-end
2.4.Logica di autenticazione SOAP/DB
3.La scheda utente
3.1.Navigazione tra i record
3.2.Creazione, modifica ed eliminazione record
3.3.Vista scheda e vista tabella
3.4.La ricerca
4.Introduzione all'amministrazione del front-end
5.Amministrazione delle tabelle e viste
5.1.Il sistema gruppi registri in pratica
5.2.Impostazioni generali di tabella
5.2.1. Impostazione allegati e link
5.3.Impostazione dei campi
5.4.Le sottomaschere
5.5.Impostazione delle viste SQL
6.Livelli di amministrazione e gestione degli utenti
7.Il sistema di log e ripristino operazioni
8.Le variabili di ambiente
9.Esportazione dati e backup database
Appendice 1. Riferimenti per applicazioni open source utilizzate
Indice
Indice 1
1. Caratteristiche del sistema 3
1.1 Tecnologia lato server 3
1.2 Struttura di base delle directory 3
1.3 Tecnologia lato client 3
2. Panoramica dell%u2019architettura 5
2.1 La logica del front-end 5
2.2 Sistema dei registri 5
2.3 Schema entit?elazioni del database di front-end 6
2.4 Logica di autenticazione SOAP/DB 8
3. La scheda utente 10
3.1 Navigazione tra i record 10
3.2 Creazione, modifica ed eliminazione record 11
3.3 Vista scheda e vista tabella 11
3.4 La ricerca 11
4. Introduzione all'amministrazione del front-end 13
5. Amministrazione delle tabelle e viste 14
5.1.Il sistema gruppi registri in pratica 14
5.2.Impostazioni generali di tabella 15
5.2.1. Impostazione allegati e link 16
5.3.Impostazione dei campi 16
5.4. Le sottomaschere 16
5.5. Impostazione delle viste SQL 16
Appendice 1 17
1. Caratteristiche del sistema
1.1 Tecnologia lato server
Il front-end di gestione database Mibac (da ora in poi semplicemente front-end) ?n'applicazione web con le seguenti caratteristiche lato server:
PHP 5 come linguaggio di scripting lato server
MySQL 5 come server database, sia per il database dell'applicazione front-end, sia per il database Mibac.
Il sistema ?esidente attualmente su un server Linux Fedora 5 del Mibac che risponde all'IP 151.12.58.136 e via web all'indirizzo http://sandbox.beniculturali.it
1.2 Struttura di base delle directory
Sono elencati in tabella i primi due livelli del filesystem:
/frontend
/conf
Contiene il file di configurazione conf.mibac.php
/files
Contiene i file allegati nominati numeroprogressivo.dat
/vfront
E' la document root e contiene gli script e le pagine accessibili via web.
1.3 Tecnologia lato client
La tecnologia lato client richiesta ?n comune browser visuale. I browser supportati completamente sono:
Internet Explorer 5.5
Internet Explorer 6
Internet Explorer 7
Firefox 1.5.x
Firefox 2.0
Mozilla 1.8
I browser parzialmente supportati sono:
Internet Explorer 5.0
Opera 8.51
Su questi browser il supporto non ?ssicurato, bench?ia possibile svolgere molte (a volte tutte le operazioni).
Per quanto riguarda il lato client il front-end fa un forte uso di javascript. E' necessario quindi che le funzioni javascript del browser siano abilitate. Molte funzioni javascript derivano da applicazioni o codice esterno in licenza open source di vario tipo. Si veda l'appendice per una documentazione accurata.
2. Panoramica dell%u2019architettura
2.1 La logica del front-end
Il front-end funziona mediante un sistema di regole o %u201Cregistri di regole%u201D che si interpone fra l'interfaccia utente ed il database di dati. Questo sistema, rappresentato dalla figura 1, permette di configurare regole di accesso alle tabelle, alle viste e ai singoli campi, mediante vincoli e formattazioni speciali configurabili dall'amministratore tramite una interfaccia apposita. E' possibile impostare campi con ricerca, campi obbligatori, tipo di input per il singolo campo e molto altro in modo personalizzato per ogni gruppo per un numero indefinito di gruppi. Si noti inoltre che tutte le regole vengono scritte in un database separato da quello dei dati, in modo da non interferire in alcun modo sulla struttura di quest'ultimo. Ci riferiremo ai due database denominandoli db dati (il database del ministero dei Beni Culturali) e db regole.
FIGURA 1 %u2013 RAPPRESENTAZIONE LOGICA
2.2 Sistema dei registri
Il front-end, in altri termini, permette di creare un ulteriore sistema di controllo sui dati, oltre a quello normalmente predisposto da un database relazionale come MySQL 5, con in pi? personalizzazione a livello di gruppo di utenti. Ogni utente ?nserito in uno ed un solo gruppo ed per ogni gruppo c'?n sistema di regole. Sar?ossibile ad esempio, mostrare alcune tabelle in sola lettura per un gruppo di utenti, in lettura e scrittura ad un altro, lettura, scrittura e cancellazione ad un terzo, oppure mostrare un set di tabelle ridotto per un quarto gruppo. L'utente che accede al sistema si trover?n'interfaccia con funzioni differenti su differenti tabelle a seconda che acceda con un gruppo con maggiori o minori diritti (figura 2). E' possibile inoltre impostare i singoli campi delle tabelle e le sottomaschere visibili in base alle esigenze dei differenti gruppi di utenti.
2.3 Schema entit?elazioni del database di front-end
E' qui riportato lo schema del database di regole:
gruppo
E' la tabella dove sono registrati e descritti i gruppi di accesso al frontend.
utente
sono qui registrati gli utenti ed il collegamento tramite chiave esterna (campo gid) alla tabella gruppo)
registro_tab
Sono qui inserite le regole generali per ogni tabella, per ogni gruppo. La tabella in una prima configurazione del front-end legge l'information_schema di MySQL 5 e configura un primo gruppo predefinito. In questa tabella sono registrati i diritti di accessibilit?ella singola tabella per il singolo gruppo in SELECT, INSERT, UPDATE, DELETE nonch?a esportabilit?ei dati della tabella.
registro_col
Tabella figlia di registro_tab ed ad essa collegata tramite chiave esterna, sul campo id_table, questa tabella documenta i campi delle tabelle impostati per ogni gruppo. Sono qua configurate le opzioni di visualizzazione dei singoli campi, il tipo di input, il fatto che i campi siano o meno obbligatori, eccetera.
registro_submask
Collegata alla tabella registro_tab mediante chiave esterna sul campo id_table, registro_submask contiene le informazioni sulle sottomaschere per ogni tabella, per ogni gruppo.
registro_submask_col
Collegata alla tabella registro_submask mediante chiave esterna sul campo id_submask, registro_submask_col descrive i singoli campi delle sottomaschere, per ogni tabella, per ogni gruppo.
recordlock
E' questa una tabella che permette la registrazione di accesso in modifica ai record del database dati, al fine di impedire l'accesso concorrente in modifica ad un record gi?ottoposto a modifica da altro utente.
log
Nella tabella log sono registrate tutte le operazioni di INSERT, UPDATE e DELETE che vengono eseguite sul database dati. La tabella log permette inoltre uno storico dei record con possibilit?i ripristino su dati modificati o cancellati per sbaglio, anche dopo l'eliminazione fisica del dato dal disco. Si veda a riguardo il capitolo %u201CLog e Ripristino dati%u201D.
variabili
In questa tabella sono registrate delle variabili di ambiente. Queste possono essere generiche (per tutto il frontend) o specifiche per un gruppo. In caso di coesistenza dei due tipi di variabili, quella specifica per il gruppo ha la priorit?ispetto a quella generica. Si veda il capito %u201CVariabili%u201D per i dettagli.
2.4 Logica di autenticazione SOAP/DB
L'accesso al front-end Mibac avviene attraverso autenticazione e accreditamento di diritti in passi separati. L'immagine sottostante illustra la procedura:
1)Autenticazione.
Il dipendente inserisce email e password personali nella maschera di login dell'applicazione (si veda la figura). I dati sono inviati tramite il protocollo SOAP al server del CASPUR, lo stesso che gestisce gli account personali di posta. Questo assicura che ogni dipendente del ministero dei beni culturali abbia un potenziale accesso al front-end senza reinserire i suoi dati personali. Se l'utente non esiste, ossia se l'accoppiata emali password non ?rovata nel server CASPUR, la richiesta viene rigettata. In caso contrario l'utente fa accesso al sistema.
FIGURA DI LOGIN
2)Accreditamento dei diritti.
Se il dipendente esiste viene fatto un controllo nel database delle regole per identificare il gruppo a cui il dipendente fa parte. Se questo viene trovato gli sono accreditati i diritti d'uso relativi al gruppo di appartenenza. In caso contrario, ossia se il dipendente non esiste in DB, vine automaticamente registrato (in quanto autenticato come dipendente del Mibac dal server CASPUR) e gli viene attribuito il gruppo di ID 0, ossia il gruppo di default avente solo diritti di lettura su alcune tabelle. Un responsabile (ad esempio un referente informatico) potr?oi %u201Cpromuovere%u201D il dipendente al gruppo di accesso al quale ha diritto.
In questo modo i dipendenti che fanno un primo accesso possono comunque vedere il sistema. Un messaggio sulla pagina iniziale comunicher?uanto riassunto finora (si veda la figura)
FIGURA MESSAGGIO GRUPPO 0
3. La scheda utente
La scheda utente ?l cuore del front-end. E' attraverso questa maschera che vengono letti, inseriti, modificati e cancellati i record. Il funzionamento della scheda utente ?ocumentato nel manuale d'uso utente. In questo documento verranno esposti i dettagli tecnici. Per una documentazione rivolta all'uso si rimanda alla lettura del documento suddetto.
La scheda utente ?n realt?n unico script con numerosi parametri che carica le impostazioni per ogni tabella dal registro di regole in base al gruppo con il quale si ?atto login. E' una pagina piuttosto pesante, specialmente se configurata con molti menu a tendina relativi a chiavi esterne (si veda l'amministrazione dei campi per i dettagli). In compenso viene caricata una sola volta per ogni tabella. Infatti lo scorrimento tra i record, avviene mediante chiamate XML asincrone del browser, tecnica nota anche come AJAX (Asynchronous JavaScript and XML). In pratica quando si avanza di un record la pagina non viene ricaricata come avviene nella maggior parte delle applicazioni web di concezione classica, ma viene mandata una chiamata nascosta al server, tramite javascript. Il server risponde mandando (sempre in modo invisibile all'utente) il dettaglio del record successivo in formato XML , il quale viene letto dal browser. A questo punto i contenuti andranno a popolare i box predisposti. Anche la manipolazione dei record avviene nello stesso modo, con il vantaggio di ottimizzare le transazioni server/client limitandole allo stretto necessario. Ad esempio qualora si volesse modificare un record %u201Cnotizia%u201D e si apportasse solo una modifica al titolo, attraverso le chiamate AJAX non si spedirebbe anche la descrizione, la data ed i valori di tutti gli altri campi, ma solo il valore modificato, ossia il nuovo titolo.
FIGURA SCHEMA AJAX DA WIKIPEDIA
3.1 Navigazione tra i record
La navigazione tra i record ?ossibile in due maniere. La pi?mediata avviene attraverso i tasti di navigazione presenti in figura. E' possibile per?ltare direttamente ad un record mediante doppio click sul contatore. Questo si trasformer?n una casella di testo nel quale si pu?rivere il numero di record al quale si vuole saltare e confermare con il tasto invio.
La casella che appare con il doppio click offre anche un'utile funzione nascosta per l'amministrazione. Se si conosce l'ID del record (il codice numerico chiave primaria) ?ossibile scrivere ad esempio id:418 e si salter?on al 418° record, ma al record di ID 418 della tabella in oggetto.
FIGURA salto tra record.
3.2 Creazione, modifica ed eliminazione record
Se si ha il diritto di creare, modificare e eliminare i record della tabella in esame, appariranno i pulsanti relativi alla creazione di record (Nuovo), alla modifica (Modifica) e all'eliminazione.
Per quanto riguarda la modifica ?ossibile che il sistema non permetta la modifica di un determinato record se qualche altro utente sta gi?perando modifiche sullo stesso. In tal caso appare un messaggio esplicativo. Il tempo per il quale un record resta bloccato dipende da un parametro impostato in numero di secondi nella tabella variabili. Di default questo parametro ?tato settato su 300 secondi (5 minuti) ma si pu?dificare a scelta dell'amministratore. Naturalmente se l'utente che sta modificando il record dovesse premere %u201CAnnulla%u201D o %u201CSalva%u201D il record verrebbe sbloccato anche se non sono passati i 300 secondi.
Per quanto riguarda l'eliminazione dei record pu?ccedere che appaia un messaggio di errore se l'utente cercasse di eliminare un record con record figli, presenti nelle sottomaschere. In tal caso ?ecessario eliminare tutti i record figli dalle sottomaschere prima e poi il record dalla maschera.
3.3 Vista scheda e vista tabella
Dalla vista scheda ?ossibile passare alla vista tabella, nel quale viene mostrato un numero di record definito nelle variabili (si veda il capitolo Variabili). Il valore di record mostrati predefinito ?0. Con doppio click su un record si pu?ssare alla vista scheda sul record cliccato.
3.4 La ricerca
La ricerca ?na propria %u201Cquery by form%u201D. Quando si clicca su ricerca i campi della maschera si svuotano e diventano verdi. Si possono scrivere dei parametri e inviare la ricerca. In questo modo vengono cercati i record che rispondono ai requisiti inseriti. Si noti che la ricerca avviene per uguaglianza, non per affinit?operatore '=' , non operatore 'LIKE') e che la ricerca funziona attraverso AND logici (non OR).
Se il risultato ?no solo la maschera mostrer?l record ricercato, se sono molti mostrer? risultati nella vista tabella.
E' possibile infine aiutare la ricerca mediante i campi con suggerimenti, impostabili dall'amministrazione della tabella. In questo caso mentre si digiter?n un campo appariranno dei suggerimenti. Questo pu?sere utile in campi significativi come la denominazione di un bene o il titolo di una notizia.
FIGURA RICERCA
4. Introduzione all'amministrazione del front-end
FIGURA AMMINISTRAZIONE
L'amministrazione del front-end ?efinita da un diritto slegato dai gruppi. Si tratta del %u201Clivello%u201D:
livello 1 %u2013 utente
livello 2 %u2013 amministratore locale o tutor
livello 3 %u2013 amministrazione generale o superadmin
Gli utenti amministratori (livello 2 e 3) hanno accesso all'amministratore mediante il link %u201Camministrazione%u201D presente in tutte le pagine il alto a destra.
Alcuni menu sono visibili solo al superadmin, e sono
1.il DUMP dei database (db regole e db dati)
2.La creazione e amministrazione dei gruppi/registri
3.La creazione di altri utenti superadmin e di utenti tutor (livello 2).
4.Le variabili di sistema
I tutor (livello 2) possono invece operare sui log, e modificare le appartenenze degli utenti a gruppi. Possono %u201Cpromuovere%u201D altri utenti a livello 2, ma non 3.
5. Amministrazione delle tabelle e viste
5.1.Il sistema gruppi registri in pratica
Come la scheda ?l cuore del front-end lato utente, il menu dei gruppi registri lo ?er la parte di amministrazione. Quando si accede al menu registri, appare una tabella riassuntiva con i registri/gruppi presenti al momento. Il link %u201CCrea nuovo gruppo%u201D fa proprio quello che ci si aspetta, con la possibilit?i scrivere un nome per il nuovo gruppo, una descrizione e %u201Cclonare%u201D le impostazioni di altro gruppo. Questo pu?sere comodo per non dover riconfigurare tutte le opzioni per le tabelle da zero, ma partire da un modello di configurazione esistente. Una volta creato il nuovo gruppo risulter?ompletamente indipendente dagli altri, compreso quello dal quale ?tato clonato. E' possibile anche eliminare i gruppi, tranne il gruppo predefinito. Quando si eliminano gruppi con utenti, questi verranno finiranno nel gruppo predefinito.
FIGURA TABELLA DI AMMINISTRAZIONE
Dalla tabella html che mostra i gruppi visibile nella figura si pu?cedere mediante il link %u201Camministrazione%u201D alle funzioni pi?teressanti del front-end. Si ha qui l'amministrazione delle tabelle del database per il gruppo preso in esame. Si ricorda che nella logica del frontend le impostazioni sulle tabelle di database per un gruppo non influenzeranno in maniera alcuna le impostazioni per gli altri gruppi. Da questa visualizzazione ?ossibile aver un quadro della situazione: le tabelle identificate dal link blu sono quelle sulle quali ?tata operata una qualche modifica, mentre quelle rosse sono quelle senza ancora impostazione da parte dell'amministratore. E' qui avere anche una panoramica veloce di quali tabelle sono accessibili in lettura, scrittura, modifica e cancellazione, nonch?l numero delle sottomaschere impostate. In coda sono visibili le viste con le loro impostazioni. Le viste create con MySQL 5 nel front-end appaiono e sono trattate in maniera simile alle tabelle vere e proprie, tranne alcuni dettagli che saranno discussi nel paragrafo 5.5.
In alto a sinistra c'?nvece un link %u201CFunzioni rapide%u201D che permette di operare modifiche su tutte le tabelle contemporaneamente. Cliccando sul link di una tabella si accede alla configurazione della stessa per il gruppo in oggetto.
5.2.Impostazioni generali di tabella
Come presente in figura si pu?servare che l'amministrazione delle tabelle per i gruppi funzionano mediante una pagina con linguette. La prima linguetta riguarda le impostazioni generali.
Qui ?mpostabile
L'ordinamento dei record2
Pu?sere impostato uno dei campi della tabella e la presentazione ascendente o discendente.
Tabella visibile si/no (SELECT)
L'inserimento di nuovi record (INSERT)
La modifica dei record (UPDATE)
La cancellazione dei record (DELETE)
La possibilit?i esportazione dei dati presenti in tabella da parte degli utenti di questo gruppo.
Per confermare l'operazione si deve esplicitamente cliccare su %u201CSalva impostazione generale%u201D.
5.2.1. Impostazione allegati e link
Come si pu?tare dalla figura precedente ci sono ulteriori impostazioni nella sezione %u201CAllegati e link%u201D. Nel database Mibac e attraverso il front-end ?nfatti possibile collegare a qualunque tabella degli allegati e dei link. Questi saranno poi mostrati nella scheda utente. E' qui possibile configurare la possibilit?i leggere, scrivere ed eliminare allegati e link per la tabella in oggetto per questo gruppo.
5.3.Impostazione dei campi
La seconda linguetta dell'amministrazione tabella per gruppo ?'impostazione dei campi (vedi figura). Per ogni campo ?ossibile impostare campo visibile 3(si|no): se si sceglie %u201Cno%u201D il campo non apparir?ella scheda; campo obbligatorio , come suggerisce la dicitura, impone al dipendente di compilare il campo. In caso contrario un messaggio %u201Calert%u201D avviser?he ?mpossibile salvare l'inserimento o la modifica. Campo con ricerca permette di usare il campo per la ricerca; imposta i suggerimenti invece, permette di mostrare, mentre si scrive in un campo, un elenco dei valori gi?resenti. E' molto utile su alcuni campi per la ricerca (come i titoli o le denominazioni). Visibile in vista tabella permetter?i mostrare il campo nella vista tabella (indipendentemente dalla vista scheda).
Per quanto riguarda i tipi di input, a seconda della tipologia di campo sono possibili solo alcune impostazioni. In linea generale il front-end permette di impostare regole pi?strittive del database, e non viceversa. Questo significa che, per esempio, se un campo ?tato impostato nel database come numerico, il front-end non permetter?i impostarlo come testo. Nel caso di testo lungo invece sar?ossibile impostare dal front-end il campo come testo corto o testo lungo. A seconda delle scelte fatte in questa maschera di amministrazione si pu?terminare come il gruppo dovr?edere la scheda per la tabella in oggetto. I tipi di input per i tipi di campi principali, in base alla definizione SQL del database, sono:
caso numero (INTEGER) %u2013 numero intero
caso numero con virgola (FLOAT) %u2013 numero con virgola
caso booleano (in MySQL TINYINT(1) ) - booleano vero|falso
caso testo (VARCHAR o CHAR) %u2013 testo libero corto, password
caso testo lungo (TEXT) %u2013 testo lungo, testo corto, testo formattato HTML (mediante un richtext editor)
caso data e ora (DATETIME o TIMESTAMP) %u2013 data e ora formattata, data formattata (con ausilio di un popup calendario con %u2013 eventualmente- anche l'ora)
caso data (DATE) %u2013 data formattata (con ausilio di un popup calendario)
Sono sempre presenti infine tre tipi di campi molto importanti, tipici del front-end :
Nascosto
Indica un valore nascosto che pu?sere una costante o una variabile. Le variabili disponibili sono descritte in un popup e sono:
%nick
Nickname dell'utente che ha fatto login
%email
Email dell'utente che ha fatto login
%uid
Identificativo numerico dell'utente che ha fatto login
%nome
Nome dell'utente che ha fatto login
%cognome
Cognome dell'utente che ha fatto login
%nomecognome
Nome e cognome (separati da spazio) dell'utente che ha fatto login
%cognomenome
Cognome e nome (separati da spazio) dell'utente che ha fatto login
%gid
Identificativo numerico del gruppo a cui appartienet l'utente che ha fatto login
%gruppo
Nome del gruppo a cui appartiene l'utente che ha fatto login
%now
Data attuale in formato aaaa-mm-gg
%timestamp
Data ed ora attuale in formato aaaa-mm-gg HH:mm:ss
%istitutocomp
Identificativo numerico dell'istituto a cui appartiene l'utente che ha fatto login
Valori definiti
Con questo tipo di input ?ossibile inserire una lista di valori predefinita. Nella scheda apparir?ome un menu a tendina. E' anche possibile inserire accoppiate valore=>etichetta. Un popup guida l'amministratore alla sintassi corretta.
Valori definiti da tabella.
E' forse questo il pi?portante tipo di input. Permette infatti di mostrare i valori codificati da un'altra tabella. Ad esempio nel campo codiceComune (numerico) ?redisposto un collegamento alla tabella %u201Ccomune%u201D mediante una query SQL. Il risultato ?n men?tendina che avr?ome valore il codiceComune numerico, ma come etichetta visibile all'utente i nomi dei comuni mostrati in chiaro. E' necessario richiamare due campi nella query SQL : il codice e la descrizione. E' possibile scrivere la query a mano oppure avvalersi del popup %u201CQuery Editor visuale%u201D. Questa funzione ?tile soprattutto nel caso di campi che sono anche chiave esterna (segnalata in blu nel front-end). E' possibile scrivere a mano le query anche con l'uso di WHERE e JOIN, funzioni di CONCAT e simili. E' possibile, per ragioni di sicurezza, scrivere solo query di tipo SELECT. E' infine possibile testare con il pulsante %u201Ctest%u201D la correttezza delle proprie query.
Una volta impostati i campi ?ecessario salvare le impostazioni con il tasto in fondo alla pagina.
5.4. Le sottomaschere
Le sottomaschere sono un utile strumento, indispensabile per gestire sul front-end le relazioni %u201Cmolti a molti%u201D. Sono visibili dalla vista scheda mediante un box con dei pulsanti bianchi (si veda la figura).
FIGURA PULSANTI SOTTOMASCHERE POPUP.
5.5. Impostazione delle viste SQL
6. Livelli di amministrazione e gestione degli utenti
7. Il sistema di log e ripristino operazioni
8. Le variabili di ambiente
9. Esportazione dati e backup database
Appendice 1
Sono qui citate le applicazioni sviluppate da terze parti attualmente in uso in qualche misura nel frontend. E' riportata anche la tipologia di licenza delle applicazioni suddette.
FCKeditor - http://www.fckeditor.net/
Rich text editor in javascript
Licenza LGPL - http://www.opensource.org/licenses/lgpl-license.php
Prototype http://prototype.conio.net/
Libreria di funzioni javascript
Licenza MIT - http://www.opensource.org/licenses/mit-license.php
Scriptaculous http://script.aculo.us/
Libreria di funzioni javascript
Licenza MIT - http://www.opensource.org/licenses/mit-license.php
DHTMLxGrid http://www.scbr.com/docs/products/dhtmlxGrid/
Generatore di tabelle dinamiche in javascript nella vista tabella
Licenza GPL - http://www.gnu.org/licenses/gpl.html
JPGraph http://www.aditus.nu/jpgraph/
Libreria per generazionie di grafici in PHP nelle statistiche
Licenza QT Free Licensee - http://www.trolltech.com/products/qt/licenses/
JsCalendar http://sourceforge.net/projects/jscalendar/
Generatore di calendari in javascript
Licenza GPL - http://www.gnu.org/licenses/gpl.html
1.Caratteristiche del sistema
1.1.Tecnologia lato server
1.2.Struttura delle directory
1.3.Tecnologia lato client
2.Panoramica dell%u2019architettura
2.1.Logica del front-end
2.2.Sistema dei registri
2.3.Schema entit?elazioni del database di front-end
2.4.Logica di autenticazione SOAP/DB
3.La scheda utente
3.1.Navigazione tra i record
3.2.Creazione, modifica ed eliminazione record
3.3.Vista scheda e vista tabella
3.4.La ricerca
4.Introduzione all'amministrazione del front-end
5.Amministrazione delle tabelle e viste
5.1.Il sistema gruppi registri in pratica
5.2.Impostazioni generali di tabella
5.2.1. Impostazione allegati e link
5.3.Impostazione dei campi
5.4.Le sottomaschere
5.5.Impostazione delle viste SQL
6.Livelli di amministrazione e gestione degli utenti
7.Il sistema di log e ripristino operazioni
8.Le variabili di ambiente
9.Esportazione dati e backup database
Appendice 1. Riferimenti per applicazioni open source utilizzate
Indice
Indice 1
1. Caratteristiche del sistema 3
1.1 Tecnologia lato server 3
1.2 Struttura di base delle directory 3
1.3 Tecnologia lato client 3
2. Panoramica dell%u2019architettura 5
2.1 La logica del front-end 5
2.2 Sistema dei registri 5
2.3 Schema entit?elazioni del database di front-end 6
2.4 Logica di autenticazione SOAP/DB 8
3. La scheda utente 10
3.1 Navigazione tra i record 10
3.2 Creazione, modifica ed eliminazione record 11
3.3 Vista scheda e vista tabella 11
3.4 La ricerca 11
4. Introduzione all'amministrazione del front-end 13
5. Amministrazione delle tabelle e viste 14
5.1.Il sistema gruppi registri in pratica 14
5.2.Impostazioni generali di tabella 15
5.2.1. Impostazione allegati e link 16
5.3.Impostazione dei campi 16
5.4. Le sottomaschere 16
5.5. Impostazione delle viste SQL 16
Appendice 1 17
1. Caratteristiche del sistema
1.1 Tecnologia lato server
Il front-end di gestione database Mibac (da ora in poi semplicemente front-end) ?n'applicazione web con le seguenti caratteristiche lato server:
PHP 5 come linguaggio di scripting lato server
MySQL 5 come server database, sia per il database dell'applicazione front-end, sia per il database Mibac.
Il sistema ?esidente attualmente su un server Linux Fedora 5 del Mibac che risponde all'IP 151.12.58.136 e via web all'indirizzo http://sandbox.beniculturali.it
1.2 Struttura di base delle directory
Sono elencati in tabella i primi due livelli del filesystem:
/frontend
/conf
Contiene il file di configurazione conf.mibac.php
/files
Contiene i file allegati nominati numeroprogressivo.dat
/vfront
E' la document root e contiene gli script e le pagine accessibili via web.
1.3 Tecnologia lato client
La tecnologia lato client richiesta ?n comune browser visuale. I browser supportati completamente sono:
Internet Explorer 5.5
Internet Explorer 6
Internet Explorer 7
Firefox 1.5.x
Firefox 2.0
Mozilla 1.8
I browser parzialmente supportati sono:
Internet Explorer 5.0
Opera 8.51
Su questi browser il supporto non ?ssicurato, bench?ia possibile svolgere molte (a volte tutte le operazioni).
Per quanto riguarda il lato client il front-end fa un forte uso di javascript. E' necessario quindi che le funzioni javascript del browser siano abilitate. Molte funzioni javascript derivano da applicazioni o codice esterno in licenza open source di vario tipo. Si veda l'appendice per una documentazione accurata.
2. Panoramica dell%u2019architettura
2.1 La logica del front-end
Il front-end funziona mediante un sistema di regole o %u201Cregistri di regole%u201D che si interpone fra l'interfaccia utente ed il database di dati. Questo sistema, rappresentato dalla figura 1, permette di configurare regole di accesso alle tabelle, alle viste e ai singoli campi, mediante vincoli e formattazioni speciali configurabili dall'amministratore tramite una interfaccia apposita. E' possibile impostare campi con ricerca, campi obbligatori, tipo di input per il singolo campo e molto altro in modo personalizzato per ogni gruppo per un numero indefinito di gruppi. Si noti inoltre che tutte le regole vengono scritte in un database separato da quello dei dati, in modo da non interferire in alcun modo sulla struttura di quest'ultimo. Ci riferiremo ai due database denominandoli db dati (il database del ministero dei Beni Culturali) e db regole.
FIGURA 1 %u2013 RAPPRESENTAZIONE LOGICA
2.2 Sistema dei registri
Il front-end, in altri termini, permette di creare un ulteriore sistema di controllo sui dati, oltre a quello normalmente predisposto da un database relazionale come MySQL 5, con in pi? personalizzazione a livello di gruppo di utenti. Ogni utente ?nserito in uno ed un solo gruppo ed per ogni gruppo c'?n sistema di regole. Sar?ossibile ad esempio, mostrare alcune tabelle in sola lettura per un gruppo di utenti, in lettura e scrittura ad un altro, lettura, scrittura e cancellazione ad un terzo, oppure mostrare un set di tabelle ridotto per un quarto gruppo. L'utente che accede al sistema si trover?n'interfaccia con funzioni differenti su differenti tabelle a seconda che acceda con un gruppo con maggiori o minori diritti (figura 2). E' possibile inoltre impostare i singoli campi delle tabelle e le sottomaschere visibili in base alle esigenze dei differenti gruppi di utenti.
2.3 Schema entit?elazioni del database di front-end
E' qui riportato lo schema del database di regole:
gruppo
E' la tabella dove sono registrati e descritti i gruppi di accesso al frontend.
utente
sono qui registrati gli utenti ed il collegamento tramite chiave esterna (campo gid) alla tabella gruppo)
registro_tab
Sono qui inserite le regole generali per ogni tabella, per ogni gruppo. La tabella in una prima configurazione del front-end legge l'information_schema di MySQL 5 e configura un primo gruppo predefinito. In questa tabella sono registrati i diritti di accessibilit?ella singola tabella per il singolo gruppo in SELECT, INSERT, UPDATE, DELETE nonch?a esportabilit?ei dati della tabella.
registro_col
Tabella figlia di registro_tab ed ad essa collegata tramite chiave esterna, sul campo id_table, questa tabella documenta i campi delle tabelle impostati per ogni gruppo. Sono qua configurate le opzioni di visualizzazione dei singoli campi, il tipo di input, il fatto che i campi siano o meno obbligatori, eccetera.
registro_submask
Collegata alla tabella registro_tab mediante chiave esterna sul campo id_table, registro_submask contiene le informazioni sulle sottomaschere per ogni tabella, per ogni gruppo.
registro_submask_col
Collegata alla tabella registro_submask mediante chiave esterna sul campo id_submask, registro_submask_col descrive i singoli campi delle sottomaschere, per ogni tabella, per ogni gruppo.
recordlock
E' questa una tabella che permette la registrazione di accesso in modifica ai record del database dati, al fine di impedire l'accesso concorrente in modifica ad un record gi?ottoposto a modifica da altro utente.
log
Nella tabella log sono registrate tutte le operazioni di INSERT, UPDATE e DELETE che vengono eseguite sul database dati. La tabella log permette inoltre uno storico dei record con possibilit?i ripristino su dati modificati o cancellati per sbaglio, anche dopo l'eliminazione fisica del dato dal disco. Si veda a riguardo il capitolo %u201CLog e Ripristino dati%u201D.
variabili
In questa tabella sono registrate delle variabili di ambiente. Queste possono essere generiche (per tutto il frontend) o specifiche per un gruppo. In caso di coesistenza dei due tipi di variabili, quella specifica per il gruppo ha la priorit?ispetto a quella generica. Si veda il capito %u201CVariabili%u201D per i dettagli.
2.4 Logica di autenticazione SOAP/DB
L'accesso al front-end Mibac avviene attraverso autenticazione e accreditamento di diritti in passi separati. L'immagine sottostante illustra la procedura:
1)Autenticazione.
Il dipendente inserisce email e password personali nella maschera di login dell'applicazione (si veda la figura). I dati sono inviati tramite il protocollo SOAP al server del CASPUR, lo stesso che gestisce gli account personali di posta. Questo assicura che ogni dipendente del ministero dei beni culturali abbia un potenziale accesso al front-end senza reinserire i suoi dati personali. Se l'utente non esiste, ossia se l'accoppiata emali password non ?rovata nel server CASPUR, la richiesta viene rigettata. In caso contrario l'utente fa accesso al sistema.
FIGURA DI LOGIN
2)Accreditamento dei diritti.
Se il dipendente esiste viene fatto un controllo nel database delle regole per identificare il gruppo a cui il dipendente fa parte. Se questo viene trovato gli sono accreditati i diritti d'uso relativi al gruppo di appartenenza. In caso contrario, ossia se il dipendente non esiste in DB, vine automaticamente registrato (in quanto autenticato come dipendente del Mibac dal server CASPUR) e gli viene attribuito il gruppo di ID 0, ossia il gruppo di default avente solo diritti di lettura su alcune tabelle. Un responsabile (ad esempio un referente informatico) potr?oi %u201Cpromuovere%u201D il dipendente al gruppo di accesso al quale ha diritto.
In questo modo i dipendenti che fanno un primo accesso possono comunque vedere il sistema. Un messaggio sulla pagina iniziale comunicher?uanto riassunto finora (si veda la figura)
FIGURA MESSAGGIO GRUPPO 0
3. La scheda utente
La scheda utente ?l cuore del front-end. E' attraverso questa maschera che vengono letti, inseriti, modificati e cancellati i record. Il funzionamento della scheda utente ?ocumentato nel manuale d'uso utente. In questo documento verranno esposti i dettagli tecnici. Per una documentazione rivolta all'uso si rimanda alla lettura del documento suddetto.
La scheda utente ?n realt?n unico script con numerosi parametri che carica le impostazioni per ogni tabella dal registro di regole in base al gruppo con il quale si ?atto login. E' una pagina piuttosto pesante, specialmente se configurata con molti menu a tendina relativi a chiavi esterne (si veda l'amministrazione dei campi per i dettagli). In compenso viene caricata una sola volta per ogni tabella. Infatti lo scorrimento tra i record, avviene mediante chiamate XML asincrone del browser, tecnica nota anche come AJAX (Asynchronous JavaScript and XML). In pratica quando si avanza di un record la pagina non viene ricaricata come avviene nella maggior parte delle applicazioni web di concezione classica, ma viene mandata una chiamata nascosta al server, tramite javascript. Il server risponde mandando (sempre in modo invisibile all'utente) il dettaglio del record successivo in formato XML , il quale viene letto dal browser. A questo punto i contenuti andranno a popolare i box predisposti. Anche la manipolazione dei record avviene nello stesso modo, con il vantaggio di ottimizzare le transazioni server/client limitandole allo stretto necessario. Ad esempio qualora si volesse modificare un record %u201Cnotizia%u201D e si apportasse solo una modifica al titolo, attraverso le chiamate AJAX non si spedirebbe anche la descrizione, la data ed i valori di tutti gli altri campi, ma solo il valore modificato, ossia il nuovo titolo.
FIGURA SCHEMA AJAX DA WIKIPEDIA
3.1 Navigazione tra i record
La navigazione tra i record ?ossibile in due maniere. La pi?mediata avviene attraverso i tasti di navigazione presenti in figura. E' possibile per?ltare direttamente ad un record mediante doppio click sul contatore. Questo si trasformer?n una casella di testo nel quale si pu?rivere il numero di record al quale si vuole saltare e confermare con il tasto invio.
La casella che appare con il doppio click offre anche un'utile funzione nascosta per l'amministrazione. Se si conosce l'ID del record (il codice numerico chiave primaria) ?ossibile scrivere ad esempio id:418 e si salter?on al 418° record, ma al record di ID 418 della tabella in oggetto.
FIGURA salto tra record.
3.2 Creazione, modifica ed eliminazione record
Se si ha il diritto di creare, modificare e eliminare i record della tabella in esame, appariranno i pulsanti relativi alla creazione di record (Nuovo), alla modifica (Modifica) e all'eliminazione.
Per quanto riguarda la modifica ?ossibile che il sistema non permetta la modifica di un determinato record se qualche altro utente sta gi?perando modifiche sullo stesso. In tal caso appare un messaggio esplicativo. Il tempo per il quale un record resta bloccato dipende da un parametro impostato in numero di secondi nella tabella variabili. Di default questo parametro ?tato settato su 300 secondi (5 minuti) ma si pu?dificare a scelta dell'amministratore. Naturalmente se l'utente che sta modificando il record dovesse premere %u201CAnnulla%u201D o %u201CSalva%u201D il record verrebbe sbloccato anche se non sono passati i 300 secondi.
Per quanto riguarda l'eliminazione dei record pu?ccedere che appaia un messaggio di errore se l'utente cercasse di eliminare un record con record figli, presenti nelle sottomaschere. In tal caso ?ecessario eliminare tutti i record figli dalle sottomaschere prima e poi il record dalla maschera.
3.3 Vista scheda e vista tabella
Dalla vista scheda ?ossibile passare alla vista tabella, nel quale viene mostrato un numero di record definito nelle variabili (si veda il capitolo Variabili). Il valore di record mostrati predefinito ?0. Con doppio click su un record si pu?ssare alla vista scheda sul record cliccato.
3.4 La ricerca
La ricerca ?na propria %u201Cquery by form%u201D. Quando si clicca su ricerca i campi della maschera si svuotano e diventano verdi. Si possono scrivere dei parametri e inviare la ricerca. In questo modo vengono cercati i record che rispondono ai requisiti inseriti. Si noti che la ricerca avviene per uguaglianza, non per affinit?operatore '=' , non operatore 'LIKE') e che la ricerca funziona attraverso AND logici (non OR).
Se il risultato ?no solo la maschera mostrer?l record ricercato, se sono molti mostrer? risultati nella vista tabella.
E' possibile infine aiutare la ricerca mediante i campi con suggerimenti, impostabili dall'amministrazione della tabella. In questo caso mentre si digiter?n un campo appariranno dei suggerimenti. Questo pu?sere utile in campi significativi come la denominazione di un bene o il titolo di una notizia.
FIGURA RICERCA
4. Introduzione all'amministrazione del front-end
FIGURA AMMINISTRAZIONE
L'amministrazione del front-end ?efinita da un diritto slegato dai gruppi. Si tratta del %u201Clivello%u201D:
livello 1 %u2013 utente
livello 2 %u2013 amministratore locale o tutor
livello 3 %u2013 amministrazione generale o superadmin
Gli utenti amministratori (livello 2 e 3) hanno accesso all'amministratore mediante il link %u201Camministrazione%u201D presente in tutte le pagine il alto a destra.
Alcuni menu sono visibili solo al superadmin, e sono
1.il DUMP dei database (db regole e db dati)
2.La creazione e amministrazione dei gruppi/registri
3.La creazione di altri utenti superadmin e di utenti tutor (livello 2).
4.Le variabili di sistema
I tutor (livello 2) possono invece operare sui log, e modificare le appartenenze degli utenti a gruppi. Possono %u201Cpromuovere%u201D altri utenti a livello 2, ma non 3.
5. Amministrazione delle tabelle e viste
5.1.Il sistema gruppi registri in pratica
Come la scheda ?l cuore del front-end lato utente, il menu dei gruppi registri lo ?er la parte di amministrazione. Quando si accede al menu registri, appare una tabella riassuntiva con i registri/gruppi presenti al momento. Il link %u201CCrea nuovo gruppo%u201D fa proprio quello che ci si aspetta, con la possibilit?i scrivere un nome per il nuovo gruppo, una descrizione e %u201Cclonare%u201D le impostazioni di altro gruppo. Questo pu?sere comodo per non dover riconfigurare tutte le opzioni per le tabelle da zero, ma partire da un modello di configurazione esistente. Una volta creato il nuovo gruppo risulter?ompletamente indipendente dagli altri, compreso quello dal quale ?tato clonato. E' possibile anche eliminare i gruppi, tranne il gruppo predefinito. Quando si eliminano gruppi con utenti, questi verranno finiranno nel gruppo predefinito.
FIGURA TABELLA DI AMMINISTRAZIONE
Dalla tabella html che mostra i gruppi visibile nella figura si pu?cedere mediante il link %u201Camministrazione%u201D alle funzioni pi?teressanti del front-end. Si ha qui l'amministrazione delle tabelle del database per il gruppo preso in esame. Si ricorda che nella logica del frontend le impostazioni sulle tabelle di database per un gruppo non influenzeranno in maniera alcuna le impostazioni per gli altri gruppi. Da questa visualizzazione ?ossibile aver un quadro della situazione: le tabelle identificate dal link blu sono quelle sulle quali ?tata operata una qualche modifica, mentre quelle rosse sono quelle senza ancora impostazione da parte dell'amministratore. E' qui avere anche una panoramica veloce di quali tabelle sono accessibili in lettura, scrittura, modifica e cancellazione, nonch?l numero delle sottomaschere impostate. In coda sono visibili le viste con le loro impostazioni. Le viste create con MySQL 5 nel front-end appaiono e sono trattate in maniera simile alle tabelle vere e proprie, tranne alcuni dettagli che saranno discussi nel paragrafo 5.5.
In alto a sinistra c'?nvece un link %u201CFunzioni rapide%u201D che permette di operare modifiche su tutte le tabelle contemporaneamente. Cliccando sul link di una tabella si accede alla configurazione della stessa per il gruppo in oggetto.
5.2.Impostazioni generali di tabella
Come presente in figura si pu?servare che l'amministrazione delle tabelle per i gruppi funzionano mediante una pagina con linguette. La prima linguetta riguarda le impostazioni generali.
Qui ?mpostabile
L'ordinamento dei record2
Pu?sere impostato uno dei campi della tabella e la presentazione ascendente o discendente.
Tabella visibile si/no (SELECT)
L'inserimento di nuovi record (INSERT)
La modifica dei record (UPDATE)
La cancellazione dei record (DELETE)
La possibilit?i esportazione dei dati presenti in tabella da parte degli utenti di questo gruppo.
Per confermare l'operazione si deve esplicitamente cliccare su %u201CSalva impostazione generale%u201D.
5.2.1. Impostazione allegati e link
Come si pu?tare dalla figura precedente ci sono ulteriori impostazioni nella sezione %u201CAllegati e link%u201D. Nel database Mibac e attraverso il front-end ?nfatti possibile collegare a qualunque tabella degli allegati e dei link. Questi saranno poi mostrati nella scheda utente. E' qui possibile configurare la possibilit?i leggere, scrivere ed eliminare allegati e link per la tabella in oggetto per questo gruppo.
5.3.Impostazione dei campi
La seconda linguetta dell'amministrazione tabella per gruppo ?'impostazione dei campi (vedi figura). Per ogni campo ?ossibile impostare campo visibile 3(si|no): se si sceglie %u201Cno%u201D il campo non apparir?ella scheda; campo obbligatorio , come suggerisce la dicitura, impone al dipendente di compilare il campo. In caso contrario un messaggio %u201Calert%u201D avviser?he ?mpossibile salvare l'inserimento o la modifica. Campo con ricerca permette di usare il campo per la ricerca; imposta i suggerimenti invece, permette di mostrare, mentre si scrive in un campo, un elenco dei valori gi?resenti. E' molto utile su alcuni campi per la ricerca (come i titoli o le denominazioni). Visibile in vista tabella permetter?i mostrare il campo nella vista tabella (indipendentemente dalla vista scheda).
Per quanto riguarda i tipi di input, a seconda della tipologia di campo sono possibili solo alcune impostazioni. In linea generale il front-end permette di impostare regole pi?strittive del database, e non viceversa. Questo significa che, per esempio, se un campo ?tato impostato nel database come numerico, il front-end non permetter?i impostarlo come testo. Nel caso di testo lungo invece sar?ossibile impostare dal front-end il campo come testo corto o testo lungo. A seconda delle scelte fatte in questa maschera di amministrazione si pu?terminare come il gruppo dovr?edere la scheda per la tabella in oggetto. I tipi di input per i tipi di campi principali, in base alla definizione SQL del database, sono:
caso numero (INTEGER) %u2013 numero intero
caso numero con virgola (FLOAT) %u2013 numero con virgola
caso booleano (in MySQL TINYINT(1) ) - booleano vero|falso
caso testo (VARCHAR o CHAR) %u2013 testo libero corto, password
caso testo lungo (TEXT) %u2013 testo lungo, testo corto, testo formattato HTML (mediante un richtext editor)
caso data e ora (DATETIME o TIMESTAMP) %u2013 data e ora formattata, data formattata (con ausilio di un popup calendario con %u2013 eventualmente- anche l'ora)
caso data (DATE) %u2013 data formattata (con ausilio di un popup calendario)
Sono sempre presenti infine tre tipi di campi molto importanti, tipici del front-end :
Nascosto
Indica un valore nascosto che pu?sere una costante o una variabile. Le variabili disponibili sono descritte in un popup e sono:
%nick
Nickname dell'utente che ha fatto login
Email dell'utente che ha fatto login
%uid
Identificativo numerico dell'utente che ha fatto login
%nome
Nome dell'utente che ha fatto login
%cognome
Cognome dell'utente che ha fatto login
%nomecognome
Nome e cognome (separati da spazio) dell'utente che ha fatto login
%cognomenome
Cognome e nome (separati da spazio) dell'utente che ha fatto login
%gid
Identificativo numerico del gruppo a cui appartienet l'utente che ha fatto login
%gruppo
Nome del gruppo a cui appartiene l'utente che ha fatto login
%now
Data attuale in formato aaaa-mm-gg
%timestamp
Data ed ora attuale in formato aaaa-mm-gg HH:mm:ss
%istitutocomp
Identificativo numerico dell'istituto a cui appartiene l'utente che ha fatto login
Valori definiti
Con questo tipo di input ?ossibile inserire una lista di valori predefinita. Nella scheda apparir?ome un menu a tendina. E' anche possibile inserire accoppiate valore=>etichetta. Un popup guida l'amministratore alla sintassi corretta.
Valori definiti da tabella.
E' forse questo il pi?portante tipo di input. Permette infatti di mostrare i valori codificati da un'altra tabella. Ad esempio nel campo codiceComune (numerico) ?redisposto un collegamento alla tabella %u201Ccomune%u201D mediante una query SQL. Il risultato ?n men?tendina che avr?ome valore il codiceComune numerico, ma come etichetta visibile all'utente i nomi dei comuni mostrati in chiaro. E' necessario richiamare due campi nella query SQL : il codice e la descrizione. E' possibile scrivere la query a mano oppure avvalersi del popup %u201CQuery Editor visuale%u201D. Questa funzione ?tile soprattutto nel caso di campi che sono anche chiave esterna (segnalata in blu nel front-end). E' possibile scrivere a mano le query anche con l'uso di WHERE e JOIN, funzioni di CONCAT e simili. E' possibile, per ragioni di sicurezza, scrivere solo query di tipo SELECT. E' infine possibile testare con il pulsante %u201Ctest%u201D la correttezza delle proprie query.
Una volta impostati i campi ?ecessario salvare le impostazioni con il tasto in fondo alla pagina.
5.4. Le sottomaschere
Le sottomaschere sono un utile strumento, indispensabile per gestire sul front-end le relazioni %u201Cmolti a molti%u201D. Sono visibili dalla vista scheda mediante un box con dei pulsanti bianchi (si veda la figura).
FIGURA PULSANTI SOTTOMASCHERE POPUP.
5.5. Impostazione delle viste SQL
6. Livelli di amministrazione e gestione degli utenti
7. Il sistema di log e ripristino operazioni
8. Le variabili di ambiente
9. Esportazione dati e backup database
Appendice 1
Sono qui citate le applicazioni sviluppate da terze parti attualmente in uso in qualche misura nel frontend. E' riportata anche la tipologia di licenza delle applicazioni suddette.
FCKeditor - http://www.fckeditor.net/
Rich text editor in javascript
Licenza LGPL - http://www.opensource.org/licenses/lgpl-license.php
Prototype http://prototype.conio.net/
Libreria di funzioni javascript
Licenza MIT - http://www.opensource.org/licenses/mit-license.php
Scriptaculous http://script.aculo.us/
Libreria di funzioni javascript
Licenza MIT - http://www.opensource.org/licenses/mit-license.php
DHTMLxGrid http://www.scbr.com/docs/products/dhtmlxGrid/
Generatore di tabelle dinamiche in javascript nella vista tabella
Licenza GPL - http://www.gnu.org/licenses/gpl.html
JPGraph http://www.aditus.nu/jpgraph/
Libreria per generazionie di grafici in PHP nelle statistiche
Licenza QT Free Licensee - http://www.trolltech.com/products/qt/licenses/
JsCalendar http://sourceforge.net/projects/jscalendar/
Generatore di calendari in javascript
Licenza GPL - http://www.gnu.org/licenses/gpl.html
© 2021 MiC - Pubblicato il 2020-10-27 22:27:10 / Ultimo aggiornamento 2020-10-27 22:27:10
