- Name: Luca Giuliani
- Matricola: 11103259
- Email: luca37@libero.it
NOTA: Ho spostato la documentazione sui vari tipi di QML su:
Didattica.FormatiXmlPerQuiz
Questa pagina sarà da ora dedicata solo alle varie versioni del client e alla storia delle loro modifiche...
Scaletta particolareggiata delle parti rimanenti:
EDITOR
- Completare produzione XML per tutte le forme, con la nuova versione di XML
- Completare caricamento XML per tutte le forme, con la nuova versione di XML
- Attivare le voci di menù: Nuovo Quiz e Nuovo esame
- Salvataggio ed esportazione. Differenziarli per bene e completarli
- Look interfaccia client da rivedere
- Sistemare interfaccia assegnazione punteggio al Quiz
- Sistemare interfaccia ricerca ed importazione Quiz
- Decidere e aggiungere interfaccetta di catalogazione dei quiz
- Attivare segnalazione di errori e warning per: tutte le forme, int. valorizzazione, int. catalogazione
- Completare interfacce di editing per tutte le forme
- Aggiungere campi per la catalogazione dei quiz a ciascuna forma
- Algoritmi di generazione di un nome univoco per le immagini conservate lato server
ELIMINAZIONE BUG CONOSCIUTI
- Bug nel sistema di Memorizzazione delle frasi di uso frequente
- Bug della barra di scroll non aggiornata
FORM HTML
- Look da rivedere
HELP
- Sistema di Help per l'utilizzo dell'editor, secondo specifiche Sun
- Files di help per l'utilizzo delle form dei Quiz (Lato server. Destinate allo studente)
GESTIONE PLUGIN
- Completare sistema di gestione plugin
- Implementare semplice meccanismo di importazione plugin in locale
PRESENTAZIONE
- Splash screen con logo
- Internazionalizzazione delle voci di menù, secondo le specifiche Sun
FACOLTATIVE
- Drag and drop sulla pila delle forme e dalla barra delle forme alla pila
- Meccanismo di importazione plugin via Internet da ipotetico
SitoMadre (ho già un mini client ftp operativo...)
STORIA DELLE MODIFICHE:
In aggiornamento...
Versione 13f:
Un pò di bug in meno...
Versione 13e:
L'esame NON PUO' essere un file xml con i link ai quiz che lo
compongono, perchè ciò ci espone ad un preciso rischio:
Supponiamo che l'esame A e l'esame B utilizzino il Quiz 1, e che quindi
contengano un link ad esso... se un prof modifica il Quiz1 le
modifiche si ripercuotono su entrambi gli esami, che non saranno più
ciò che il loro creatore voleva che fossero.
Lo scenario di utilizzo del SW deve quindi diventare questo:
Il prof può creare singoli quiz e aggiungerli alla "banca dati" del
sistema, ossia essi saranno memorizzati in singoli file xml in precise
posizioni all'interno di un albero di directory che li mantiene
suddivisi per categoria (ricordiamo che questo ha lo scopo di
velocizzare le ricerche del singolo quiz, perchè se li mettessi in un
unica directory. ovviamente per cercare i quiz di un particolare tipo
sarei obbligato a scandirli tutti).
Una volta che il prof decida di creare un nuovo esame, potrà inserirvi
sia nuovi quiz creati sul momento, sia quiz tratti dalla "banca dati".
Tutti i quiz che comporranno il suo esame potranno essere modificati
liberamente in qualsiasi modo MA nel momento in cui il file esame
verrà salvato i quiz che lo compongono diventeranno interni ad esso
(ossia il file xml dell'esame incorporerà i quiz che lo compongono
invece di avere solo dei link ad essi) in modo che le modifiche ai
quiz non alterino la banca dati.
Versione 13d:
Stò implementando il meccanismo di caricamento di un esame creato in
precedenza e precedentemente memorizzato su Hd. (Il caricamento
dell'esame comprende anche il caricamento di tutti i quiz associati ad
esso).
Per prima cosa il sistema dovrebbe effettuare una scansione della
directory OUTPUT\ESAMI\ e presentare all'utente delle informazioni su
tutti gli esami contenuti in essa, in modo che esso posssa selezionare
l'esame desiderato. Queste informazioni sono nei file xml degli esami e
quindi devono essere reperite.
Dato che gli esami potrebbero essere molti e di grosse dimensioni, ho
utilizzato il SAX, che non carica l'intero file dell'esame in memoria,
ma si limita a scandirlo, attivando degli eventi qundo incontra
particolari campi (ad esempio quando incontra il tag "AUTORE") .
Dopo la scansione, quindi, sono in possesso di tutte le info
desiderate. La mia intenzione sarebbe di presentarle all'utente in una
griglia che ha per indici di colonna i dati più salienti
(AUTORE,CREATOiL,NOMEFILE,...) e come righe le relative info.
Cliccando una volta su una riga, sotto la griglia comparirebbero
maggiori informazioni oppure/inoltre si attiverebbe un
pulsante "DETTAGLI..." con cui l'utente potrà chiedere tutte le
informazioni sull'esame senza ancora caricarlo. Un pulsante "CARICA" ed
un altro "ANNULLA" completano l'opera. Una volta che il prof seleziona
l'esame questo viene caricato in memoria insieme a tutti i quiz.
Ho implementato un prototipo di sistema di salvataggio dell'esame.
Prima vengono salvati i singoli file dei quiz che compongono l'esame:
Ciscuna Forma genera un albero DOM, popolandolo con l'input proveniente
dall'interfaccia di editing (ossia dai dati del singolo quiz inseriti
dal prof), quindi l'albero dom viene tradotto in una stringa xml.
Ricordiamo che, come già anticipato su Web Didattica, s'era deciso di salvare i file xml
in una struttura di directory tale da facilitare il loro successivo
reperimento. A questo scopo il sistema crea (se essa già non esiste)la directory
".\OUTPUT\QUIZ\NOMEMATERIA\NOMEFORMA", (per "NOMEMATERIA" e "NOMEFROMA" si intendono,
rispettivamente, il nome della materia a cui appartiene la forma e il suo nome)
quindi viene generato un nome casuale
univoco per il futuro file xml che può così essere salvato alla
posizione (ad esempio) ".\OUTPUT\QUIZ\ARCHITETTURA\AUTOMILINEARI\342132.xml"
La generazione automatica di un nome casuale per il Quiz è necessaria per ragioni
di comodità (non si può pretendere che l'utente stia a fornire un nome
diverso per ciascuno dei molti quiz che compongono l'esame), mentre è
ragionevole chiedergli di assegnare un nome all'esame stesso.
Per ciascun quiz, viene quindi creata e salvata la relativa stringa
xml, alla posizione stabilita.
Dopo il primo salvataggio il sistema memorizza in ciascuna Forma il
nome di file che gli è stato associato, in modo tale che ai successivi
salvataggi della stessa sessione di lavoro, i vecchi file xml di
ciascun quiz possano venire sovrascritti.
A questo punto viene generato la struttura DOM dell' esame. Essa viene
popolata con il contenuto delle forme "Proprietà Generali" e
"Intestazione" e infine con i link ai quiz che compongono l'esame, che
si trovano già sull'HD. Il risultato sarà una cosa del tipo:
<?xml version="1.0" ?>
<ESAME>
<PROPGENERALI>
sottotag vari...
</PROPGENERALI>
<INTESTAZIONE>
sottotag vari...
</INTESTAZIONE>
<QUIZ>
<LINK url="quiz\Universali\8140251.xml" />
<LINK url="quiz\Universali\6544215.xml" />
<LINK url="quiz\Universali\4649556.xml" />
</QUIZ>
</ESAME>
Salvato alla posizione ".\OUTPUT\ESAMI\nomeEsame.xml"
NB:(Il formato è del tutto provvisorio, ci stiamo ancora lavorando!!!)
Il salvataggio dell'intero esame potrebbe impiegare alcuni secondi
(dipende dalle dimensioni dell esame) per cui ho implementato una
barra di progresso stile windows che ne illustra l'andamento (funziona
ma ha qualche problemuzzo di refresh)
Osservazione: Nel momento in cui l'esame sarà salvato in remoto (per ora è in
locale) i link dovranno però essere rimappati (per evitare
possibili sovrascritture di file.
Osservazione: Il numero che forma il nome casuale del quiz potrebbe esseree preceduto dal nome
dell'autore del
Quiz stesso. (ad es.) ".\OUTPUT\QUIZ\ARCHITETTURA\Sterbini_342132.xml"
Ho implementato una semplice classe che fà uso di una tavola hash
serializzata, per gestire un sistema di preferences utente.
All'avvio il sistema caricherà le preferences e si setterà di
conseguenza. Queste saranno poi salvate automaticamente alla chiusura.
Ho pensato che sarebbe estremamente semplice offrire (in futuro) ad ogni utente la
possibilità di poter memorizzare le proprie preferences! In questo
caso le info verrebbero criptate e protette con un controllo
login-password in modo che nessuno possa modificare quelle di un
altro. Un possibile utilizzo potrebbe essere quello di permettere
all'utente di indicare file xsl alternativi per ciascuna forma.
Mi spiego: Il nostro sistema prevede che l'anteprima Html, sia
realizzata a partire dall'xml, attraverso una trasformazione xsl che
la porta in html. Ciascuna Forma possiede il proprio file xsl di
default incorporato nel file JAR che la implementa, ma nulla vieta di
indicarne un altro. Ad esempio l'utente può indicare che l'anteprima
della forma Automa debba essere ricavata con il file myAutomaInHtml.xsl, e
memorizza la coppia ("automa","path del file
MyAutomaInHtml.xsl") nel file dei
settaggi.
Versione 13:
Ho implementato gli algoritmi per le operazioni principali sulle
forme: Creazione, editing, anteprima e salvataggio.
L'anteprima in xml, è realizzata raccogliendo l'input dell'utente dall'interfaccia
di editing e creando con queste informazioni un documento DOM, che viene poi tradotto
in una struttura XML. L'anteprima in Html, è realizzata appicando in aggiunta alle
operazioni precedenti una trasformazione XSL che produce il codice Html.
(ho impostato l'editor
per visualizzare il sorgente html anzichè processarlo, perchè per ora è più conveniente)
La trasformazione xsl di default per ogni forma sarà contenuta nel file "default.xsl"
contenuto del pacchetto della forma stessa. L'utente non potrà modificare questo file,
ma volendo potrebbe proporne uno alternativo.
Queste operazioni sono state realizzate con l'uso delle librerie Xalan e Xerces del
gruppo Apache. Ho abilitato anche il salvataggio delle forme, a scelta in Xml o in Html.
Per ora il client ha solo la forma "Testo Semplice". Non appena avremo definito bene
la struttura delle altre, le aggiungerò all'interfaccia.
Versioni da 0 a 12
Meglio non parlarne....
Related topics