Il passaggio di tutti gli oggetti dell’ SDG dal BMF 2.x al 3.0 ha costituito un’ ampia parte di questo lavoro di tesi. Infatti, come si ´e potuto osservare dagli elenchi del precedente paragrafo, il numero di report ´e molto elevato (circa 140) ed inoltre ciascuno di essi ´e
costruito legando tra loro pi´u oggetti.
In fase di realizzazione del nuovo SDG ´e stata seguita una procedura di conversione di tali oggetti costituita da alcuni passi che si sono ripetuti ed applicati a ciascuno di essi.
Per ogni report da realizzare:
1. in primo luogo si sono individuati tutti gli oggetti che lo
costituiscono: c’ ´e sempre almeno un pulsante ed una tabella o un grafico, ma nella quasi totalit´a dei casi il report si compone anche di un filtro per l’ effettuazione di ricerche ed altri oggetti.
2. si ´e realizzato l’ oggetto pulsante che permette di accedere al report facendo il save as di uno gi´a esistente e cambiandone il nome (´e stato dato lo stesso che avevano nel vecchio SDG), il link ed il campo di configurazione Json. Tale campo, nel caso di questo tipo di oggetto, va a determinare il nome con il quale il pulsante sar´a visto nel men´u. Per quanto riguarda il link, esso determina quali oggetti si andaranno a visualizzare selezionando il pulsante, e nel nuovo BMF ha una forma del tipo #dispatcher/idObject= seguito dall’ elenco degli oggetti separati dal carattere &.
3. utilizzando la Navigazione sito si ´e associato il pulsante al men´u principale oppure ad una men´u folder secondaria mantenendo la stessa posizione assunta nel vecchio sistema.
4. si ´e realizzato l’ oggetto filtro facendo il save as di uno gi´a
esistente, assegnandogli lo stesso nome che aveva nel vecchio sistema e valorizzando in modo adeguato il campo Json. Qui vengono
determinati i campi su cui si effettua la ricerca: si settano la label e l’ id del campo, si determina se mantenere il parametro il sessione o meno ed infine si deve specificare il tipo del campo, tipicamente un testo, una data o un elenco a tendina (combo). In quest’ ultimo caso ´e stato creato anche l’ oggetto select che va a prelevare i valori da
inserire nella combo ed ´e stato passato come parametro di
configurazione. In caso di assenza di un filtro nel report questo punto ´e ovviamente stato saltato.
5. si ´e realizzato l’ oggetto tabella facendo il save as di una gi´a
esistente e assegnandogli il corretto nome, specificando il DB sul quale viene effettuata la query che preleva i dati e valorizzando i campi Query e Json. Per quanto riguarda la query ´e stata sempre riportata la medesima query per vista che caratterizzava l’ oggetto nel vecchio sistema. Con la configurazione Json sono state definite tutte le altre caratteristiche della tabella: nomi di ciascuna colonna, su quali campi effettuare l’ order by, su quali calcolare il totale o la percentuale. In alcuni casi ´e possibile che i valori di qualche campo siano cliccabili per accedere ad una tabella secondaria: questo viene realizzato associando un riferimento ipertestuale a quel campo all’ interno della query. Un riferimento ipertestuale ´e un link HTML che, in generale, permette di collegare una pagina web ad un’ altra oppure a un’ immagine, un documento o altri tipi di file andando a specificare all’ interno del link l’ indirizzo dell’ oggetto che si vuole raggiungere. Poich´e le nuove regole sulla composizione dei link descritte al punto 2 valgono anche per i riferimenti ipertestuali, questi si sono dovuti portare nella forma < ahref = ”#dispatcher/idObject = ...” >< /a >. Poi si ´e realizzata la tabella secondaria seguendo lo stesso procedimento appena
descritto.
6. in caso di presenza di un GroupButton nel report si ´e realizzato il corrispondente oggetto ancora una volta con la tecnica del save as e specificando il nome e le caratteristiche di ciascun pulsante facente parte del gruppo nel campo Json: la label ed il link. In genere i GroupButton sono inseriti nei report per poter accedere ad una tabella secondaria che fornisce informazioni di maggiore dettaglio oppure per poter effettuare una nuova ricerca.
7. in caso di presenza di albero nel report si ´e creato il corrispondente oggetto TREE specificandone il nome e la radice dell’ albero ed il tipo nel campo Json. Ad ogni nodo dell’ albero ´e in genere associato un link e quindi, come per i riferimenti ipertestuali, questi sono stati modificati e portati nella forma richiesta dal nuovo sistema. Ai link
degli alberi ´e possibile accedere dall’ apposito template Associa link a struttura.
8. in caso di presenza di un grafico nel report si ´e creato il
corrispondente oggetto CHART usando sempre la tecnica del save as e andando a modificare il nome, la query che genera il grafico e specificando nel campo di configurazione Json il tipo (in genere torta o istogramma), come costruire gli xasses e yasses e se si volesse o meno la legenda.
9. dopo aver finito la realizzazione di ciascun report si ´e verificato il loro corretto funzionamento dopo aver fatto il reload del sito per rendere effettive le modifiche.
Non ´e stato in realt´a necessario creare de novo tutti gli oggetti perch´e alcuni erano gi´a esistenti, ma mal configurati (cio´e seguendo le regole del vecchio sistema). In questi casi ´e stato necessario solo verificare che la query fosse corretta e modificare il campo Json direttamente sull’ oggetto esistente.
Di seguito sono mostrati alcuni esempi di report realizzati:
Figura 19: Report Confronti Attivit´a
Figura 21: Report Attrazione
Figura 23: Report Attrazione: dettaglio regione Toscana
Figura 25: Report Prestazioni Erogate