Software di gestione moduli didattici per la formazione a distanza ver. 0.1
==================================================================
Copyright Aga informatica 1999.
DISCLAIMER
----------
Le seguenti note sono solo indicative e vanno prese così come sono; ovvero
come promemoria. Quando avrò un poco più di tempo provvederò a farne una
stesura completa ed esauriente, con tanto di discussione della logica dei
programmi, per la gioia ed il gaudio di tutti. Per ora accontentatevi...
Teoricamente potrebbe essere possibile compilarlo anche sotto NT, basta avere
gcc. Al posto di postgres si dovrebbe adattare il sorgente creando un piccolo
middleware per utilizzare SQL server od un DBMS generico.
NOTE
----
Per l'installazione del software cambiare l'install directory presente nel
Makefile e quindi dare il comando make install come root.
Per l'installazione dei tracciati, dopo aver installato Postgres 6.3,
creare il database corsi:
createdb corsi
creare le tabelle:
psql -e corsi < tracciato
impostare eventuali opzioni di sicurezza/accessi esterni in pg_hba.conf e garantire l'accesso
all'utente nobody, o comunque a quello per mezzo del quale vengono eseguiti
i CGI dall'http server tramite lo statement SQL:
GRANT ALL ON <tabelle> TO PUBLIC;
La struttura dei direttori deve essere siffatta:
<Root directory HTTP>---/corsi/----/cgi-bin/
|
|-/corso_<x1>
|
|-/corso_<x2>
|
|-/corso_<x3>
Ogni direttorio del corso deve avere un direttorio documenti ed eventualmente
un direttorio upload. Tali direttori devono essere protetti in lettura, ovvero
non possono essere letti da chiunque se non dal gruppo appartenente al personale
di servizio.
Il direttorio cgi-bin invece, oltre ad essere configurato dal server http come
direttorio di esecuzione CGI, deve avere l'accesso possibile oltre che dal personale
di servizio, anche dai membri dei corsi.
In cgi-bin andrà anche installato il direttorio HyperNews debitamente configurato.
Ricordarsi di compilare per ogni utente anche il corso del quale fa parte. Tale
indicazione deve essere uguale ai vari direttori dei corsi <x1>, <x2> o <x3> etc.
All'interno del direttorio documenti vi sono tanti direttori quanti i moduli
validi per il corso; ognuno è contraddistinto dal suo numero registrato sul
database con una "M" davanti. All'interno di ognuno di questi direttori, M1,M2,
M3 etc, vi sarà la pagina iniziale (index.htm) di presentazione e riferimento
ai vari materiali. I materiali presenti in tale direttorio possono essere files
di qualsiasi tipo. Infine oltre ai materiali vi sono anche i test necessari
per l'ingresso e passaggio da una unità didattica all'altra: test_a.htm, test_b.htm
test_c.htm... test_z.htm, dove test_a.htm è quello obbligatorio per l'ingresso
e test_z.htm è quello per verificare la conoscenza finale del modulo.o
<Root directory HTTP>--/corsi/--/corso_<x1>/upload/
|
/documenti/
|
|-/M1/..index.htm, materiali, test
|
|-/M2/
|
|-/M3/
I riferimenti alle class-room per i singoli moduli devono avere lo stesso
nome col quale il modulo stesso viene registrato nel database. Fare attenzione
perche' la cosa e' case sensitive.
TODO
----
*) Possibilità di gestione utente tutore, in modo che possa accedere liberamente
ad ogni corso, ad ogni modulo, ad ogni classroom, ad ogni test senza memorizzarne
risultati etc. Questa modifica è collegata alla memorizzazione delle informazioni
relative ad ogni singolo corso. E' da decidere se ci vuole una tabella in più
(corsi, con nome e descrizione) e dove mettere le informazioni di appartenenza
al corso: sul modulo o sull'utente. Se si mettono sull'utente è necessario
trovare un modo, nel caso del tutor, affinchè si possa ricostruire il path
completo del modulo. Probabilmente si dovrà unificare tutti i direttori documenti
dei vari corsi, e tener distinti i moduli, visto che ognuno è cmq diverso.
In tal modo probabilmente si avrà un unico direttorio "documenti" sotto "corsi"
e non tanti ognuno sotto corso_<xxx>, facilitando la composizione del path del
file da reperire, siano essi tests o materiali. In effetti visto che i moduli
sono n, non vi è motivo di tenerli separati per corso. Per coerenza l'unica
cosa che si può implementare è un campo in più sulla tabella moduli nel
quale evidenziare di quale corso fa parte ma sarebbe una informazione ridondante.
*) Interfaccia NSAPI per Netscape Fasttrack, in modo che l'autenticazione sia effettuata
controllando il database utenti postgres. Così facendo si evitano duplicazioni
di user-ID. Ovvio che tale interfaccia NSAPI, sarà valida solo per Fasttrack
server. Nel caso di altro http server, ad esempio Apache, la cosa è da studiare.
*) Verificare le potenzialità di HyperNews ed eventualmente cercare una message board
più flessibile per i nostri scopi. Attualmente il sistema di autenticazione
manuale incapsulato all'interno non è un gran ché; fare in modo che utilizzi
quello del browser. In genere per HyperNews, basta impostare un unico utente,
il creatore dei forum ed amministratore del sito.
*) Implementare un miglior metodo per far sì che i client non mettano in cache
i risultati dei vari cgi. Attualmente l'header expires non funziona molto bene,
infatti quando si torna indietro col browser, dice sempre che il documento
è spirato. Analogamente se si decide di stampare una qualsiasi pagina. Forse
tramite i cookies...
*) Maggior parametrizzazione per l'installazione, in modo da fare un bell'RPM
cosicchè si possa vendere il prodotto!
*) Maggior documentazione... ma questo si sapeva già...
*) Se possibile trovare un modo per togliere i pulsanti di azione dalle pagine
di ogni modulo (quelli per scaricare le lezioni, accedere ai tests ecc) e
sostituirli con hyperlink. Il problema è che si tratta di forms che spediscono
col metodo POST. Forse implementando una riga unica con i paramateri necessari
ci si può riuscire.
--Angelo
5fca30b8ed