La classe EventLogEditor

Come accennato nella Sezione 3.3.3, questa classe denisce la struttura di una particolare nestra interna del sistema: è una estensione della classe Java JInternalFrame, classe che a sua volta denisce generiche nestre interne di una GUI sviluppata a partire dalla classe Java JFrame (che nel nostro caso è la classe EventLogManagerVIew, che appunto estende la classe JFrame per denire la nestra principale dell'applicazione). Estendendo questa classe si è potuto denire il contenuto di questa nestra interna e le sue proprietà.

Un esempio di nestra di editor è mostrata in Figura 4.1.

La nestra contiene innanzitutto un editor di testo, per il caricamento e la modica di documenti in formato testuale, implementato utilizzando la libre- ria esterna RSyntaxTextArea decritta nella Sezione 2.2.4.2. Questa libreria, come ampiamente descritto nella sezione citata, fornisce un editor completo per la gestione e modica di molti linguaggi di programmazione e mette a disposizione molte funzionalità, come l'evidenziamento della sintassi del co- dice tramite colorazione (syntax highlighting) con la possibilità di scegliere un tema personalizzato per lo stile del font e dei colori del codice, il raggrup-

pamento del codice (code folding), il bilanciamento delle parentesi (bracket matching), l'indentazione automatica (auto-indentation), l'evidenziamento di tutte le occorrenze di un identicatore, variabile o funzione presente nella posizione del cursore, numeri di linea a lato dell'editor, evidenziamento di li- nea, illimitata registrazione delle operazioni di "Annulla" (Undo) e "Ripeti" (redo) attraverso l'utilizzo congiunto della classe RUndoManager (classe ap- partenente a questa libreria che estende e migliora il funzionamento di quella delle API Java UndoManager) e non ultima una gestione ottimizzata della lettura e scrittura di uno streaming di dati (rappresentanti un documento testuale letto o scritto da/su un le) in modo da trasformare correttamente i vari delimitatori di linea e riga, gli spazi e le tabulazioni da una sorgente ad un'altra senza perdita di informazioni.

La libreria RSyntaxTextArea fornisce anche altre funzioni che descrivere- mo però nelle successive sezioni per mantenere la divisione tematica scelta per questa parte del documento. Per ora ci siamo limitati a tutte le funzionalità messe a disposizione e attivate per la gestione dei documenti di testo.

Quello che è stato necessario è stato semplicemente l'inserimento nella classe EventLogEditor dell'editor fornito da questa libreria, ovvero un og- getto della classe RSyntaxTextArea, estensione della classe RTextArea che a sua volta estende quella Java JTextArea (per una totale integrazione e compatibilità con le API Java), e l'attivazione su di esso delle proprietà desiderate:

1 // set the text area properties

2 textArea.getDocument().putProperty("owner", this); 3 // use XML syntax highlighting

5 // set code folding

6 textArea.setCodeFoldingEnabled(true); 7 // set antialiasing

8 textArea.setAntiAliasingEnabled(true); 9 // set auto indentation

10 textArea.setAutoIndentEnabled(true); 11 // set auto close mark-up tags 12 textArea.setCloseMarkupTags(true); 13 // set no line wrap

14 textArea.setLineWrap(false); 15 // set tab pixel dimension 16 textArea.setTabSize(4);

17 // get the selected theme file and apply it to the text area 18 try {

19 String themePath = "/themes/eclipse.xml";

20 Theme theme = Theme.load(getClass().getResourceAsStream(themePath));

21 theme.apply(textArea);

22 } catch (IOException e) {

23 // no need to do anything, the editor will automatically have the default theme 24 }

25 // change the theme font and font size

26 textArea.setFont(new Font("Courier", Font.PLAIN, defaultFontSize));

Quelle mostrate sono le impostazioni personalizzate per il nostro sistema, per le quali abbiamo cambiato il valore di default. Quelle non elencate nel codice sono funzionalità della classe RSyntaxTextArea per le quali il valo- re di default era adeguato ai nostri scopi e quindi non è stato modicato. Mostreremo nelle successive sezioni altre proprietà attivate sul questo editor. La classe EventLogEditor fornisce dunque all'utente un ambiente di ge- stione e scrittura codice ottimale, ma c'è molto sotto quello che vede l'utente che questa classe fornisce all'intero sistema per una perfetta interconnessione tra le sue varie funzionalità.

stato dell'editor e del suo contenuto, in modo da poter informare le altre componenti dell'applicazione in qualsiasi momento queste desiderino dello stato attuale in cui si trova.

Vediamo ora di seguito quali sono le informazioni registrate dalla classe EventLogEditor per quanto riguarda la gestione dei documenti:

1. Questa classe permette di registrare in una variabile booleana lo stato "modicato" del contenuto dell'editor, indicando con il valore true quando il documento è stato modicato dopo l'ultima salvataggio dello stesso in un le esterno all'applicazione, con false quando questo è la rappresentazione di una versione identica presente su un le esterno. 2. Questa classe permette di registrare in una variabile booleana lo sta-

to di "validato" del contenuto dell'editor, indicando con il valore true quando il documento è stato controllato e correttamente validato se- condo le speciche dello standard XES (codicate nel le XSD dello standard, utilizzato per la suddetta validazione), con false quando, rispetto all'ultima validazione eettuata, il documento è stato modi- cato e quindi deve essere controllato di nuovo (questo accade anche quando il documento aperto non è ancora mai stato validato e quindi risulta da controllare).

3. Questa classe ricorda la sorgente esterna (il le) dal quale il suo con- tenuto è stato caricato, o la destinazione sulla quale viene eettuato il salvataggio dello stesso e sul quale fare i salvataggi successivi (è ovvio che le due cose coincidono ad un certo punto della sessione, la sorgente

zione del primo salvataggio diventa a sua volta anche la sorgente del documento). Grazie ad una variabile testuale memorizza il percorso nel le system del le associato a questo oggetto, in modo da poter fornire costantemente un riferimento a quest'ultimo.

Vedremo nelle successive sezioni le altre informazioni registrate dall'edi- tor, nel momento in cui andremo a trattare l'analisi del suo contenuto.

Per ciascuna di queste informazioni, la classe mette a disposizione dei metodi per la lettura (metodi get) e per l'aggiornamento (metodi set), in modo che le altre componenti che interagiscono con essa possano leggere gli stati di loro interesse ed eventualmente modicarli, a seguito delle loro operazioni.

La classe inoltre permette l'installazione di un listener sull'editor: un og- getto della classe EventLogEditorDocumentListener, implementazione del- la classe DocumentListener descritta nella Sezione 3.3.4.1, che resta in ascol- to sul contenuto dell'editor e modica lo stato di quest'ultimo in base alle azioni dell'utente all'interno di esso.

Questo listener alla prima modica del documento da parte dell'utente, imposta lo stato dell'editor a modicato, sia a livello dell'impostazione vista in precedenza, sia a livello graco: inserisce infatti accanto al nome della - nestra un asterisco, per indicare che il documento è stato modicato rispetto alla versione salvata e necessita di essere salvato di nuovo se non si vuole perdere le modiche eettuate. Oltre a questa modica, il listener imposta il contenuto dell'editor come non validato, in quanto modicato rispetto all'ul- tima modica e quindi da controllare nuovamente per accertarne la validità. Inne, il listener elimina alcuni riferimenti dell'editor ad oggetti ad esso col-

legati, quali report di analisi, ltri, pannelli aperti, e così via. Vedremo più nel dettaglio questa parte nella sezione dedicata all'analisi dei log.

Dopo aver descritto questa classe e le funzionalità messe a disposizione del sistema, nelle successive sezioni passeremo a vedere come queste siano importanti per la gestione dei documenti e come si integrino con l'interfaccia graca dell'applicazione.