Utilizzo dei Framework Java Server Faces ed Hibernate per lo sviluppo di un servizio internet per i cittadini del Comune di Grosseto

Transcript

1 Università degli Studi di Pisa Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Triennale in Informatica Utilizzo dei Framework Java Server Faces ed Hibernate per lo sviluppo di un servizio internet per i cittadini del Comune di Grosseto Tutore Aziendale Dott. Ludwig Bargagli Candidato Giulio Rossetti Tutore Accademico Prof. Vincenzo Gervasi Addì 12 Ottobre 2007

2 2

3 Capitolo 1 Introduzione L oggetto di questa relazione è il progetto di tirocinio svolto presso il Comune di Grosseto nel periodo che va dal 12/03/2007 al 25/07/2007. Il lavoro di progettazione, sviluppo e test del codice prodotto è stato eseguito negli uffici del SED (il centro servizi informatici del comune) sotto la supervisione del dott. Ludwig Bargagli. Durante il tirocinio ho realizzato un applicazione per la gestione degli oggetti smarriti sul territorio comunale che verrà utilizzata da parte della Polizia Municipale e dal Provveditorato. Tale applocazione nasce per rendere più agevole la raccolta dei dati riguardanti le denunce di smarrimento e ritrovo degli oggetti nel territorio provinciale: offre infatti uno sportello online tramite cui il cittadino può comunicare direttamente con gli impiegati della pubblica amministrazione per effettuare denunce di smarrimento e ricerche nel catalogo degli oggetti smarriti e ritrovati. Inoltre gli impiegati della Polizia Municipale e del Provveditorato possono, tramite un ulteriore interfaccia web loro dedicata, controllare lo stato delle denunce, consultare l archivio delle stesse, e tenere traccia della dislocazione degli oggetti ritrovati nei depositi atti a tale scopo. Alcuni di questi servizi erano già in passato resi fruibili da un applicazione web realizzata in tempi brevi per la necessità di averla disponibile nell immediato: per questo motivo il servizio fornito risultava incompleto e non esente da alcuni problemi di gestione e di lentezza nell esecuzione in caso di un moderato sovrannumero di richieste contemporanee. Ho quindi riprogettato da zero una nuova versione dell applicazione tenendo conto delle necessità degli utenti finali, cercando di renderla più intuitiva possibile per limitare le difficoltà di utilizzo, e allo stesso tempo migliorando la capacità del servizio stesso nei casi di richieste multiple. Altro motivo per 3

4 4 CAPITOLO 1. INTRODUZIONE cui si è resa necessaria la riscrittura dell applicazione è che era stata realizzata con tecnologie che non ne consentivano più una facile manutenzione e aggiornamento, rendendola di fatto inutilizzabile per la gestione degli archivi ormai memorizzati nel database con tempi di accesso accettabili. Proprio per non perdere gli archivi già presenti, e poter in tal modo operare una sostituzione a caldo del precedente servizio, ho mantenuto la struttura delle tabelle del database: questa scelta ha comportato delle limitazioni in fase di progettazione e creato la necessità di valutare varie soluzioni per la gestione degli accessi al database. Tali alternative sono riportate nella sezione IV di questa relazione. Il servizio web realizzato consta quindi di due parti: un interfaccia di amministrazione e una per la fruizione del servizio da parte del cittadino. Il deployment dell applicazione è stato effettuato su una macchina avente come sistema operativo Linux Ubuntu Server e Apache Tomcat come Servlet/JSP container. Tale macchina risiede all interno della rete aziendale e per tale motivo è stato necessario configurare una macchina posta in una DMZ come reverse proxy (Apache http server) per rendere il servizio fruibile su internet. 1.1 Organizzazione della relazione La relazione qui presentata è strutturata in modo da dare una visione d insieme dell applicazione realizzata. Per mostrare con maggiore chiarezza le parti principali del servizio verranno presentate nel seguito di questa introduzione le tecnologie utilizzate, si passerà poi ad analizzare la parte riguardante l interfaccia grafica (sezione I), la logica di backend (sezione II), la struttura del database (sezione III), i casi di studio relativi alle varie versioni dell applicazione realizzate (sezione IV) ed una postfazione contenente le considerazioni sul tirocinio svolto e la bibliografia essenziale (sezione V). Ogni sezione tecnica è introdotta da un paragrafo di descrizione della parte dell applicazione presa in esame e si completa con la discussione delle metodologie di implementazione focalizzando l attenzione sui problemi incontrati durante lo sviluppo e sulle soluzioni proposte. Inoltre nei casi in cui ho dovuto operare delle scelte tra varie tecnologie propostemi o da me presentate ho presentato le motivazioni che mi hanno indotto a discriminare tra le varie alternative.

5 Capitolo 2 Requisiti del progetto 2.1 Dettagli precedente versione del servizio Realizzata nel 2003, la precedente versione del servizio era implementata in Java (J2EE 1.3) secondo il paradigma JSP Model 1 e implementava le chiamate al database (Oracle) tramite l ausilio di driver jdbc. Tale implementazione prevedeva l uso per la parte di View di pagine JSP (Java server pages) e per la parte relativa al Controller di Servlet. La sua limitata manutenibilità è dovuta al pesante uso di scriptlet e procedure Javascript nelle pagine JSP che rendono, in molti casi, poco leggibile i sorgenti realizzati e inoltre quasi del tutto assente la separazione della logica applicativa da quella di presentazione. Un inconveniente di questa versione è senza dubbio la scarsa possibilità di riuso del codice che mi ha costretto ad una fase di reverse engineering prima di poter iniziare a strutturare la nuova versione. 2.2 Nuova implementazione I requisiti tecnici che sono stati richiesti esplicitamente per la realizzazione del progetto sono i seguenti: Implementazione del pattern MVC (JSP Model 2) Uso del Framework Java Server Faces (nella implementazione MyFaces fornita da Apache) Gestione della stampa dei report in PDF Gestione delle informazioni riguardanti le inserzioni tramite 5

6 6 CAPITOLO 2. REQUISITI DEL PROGETTO Integrazione con sistema di autenticazione di tipo Single Sign On Portabilità su più modelli di database Studio di fattibilità per il possibile impiego del Framework Hibernate Inoltre sono state aggiunte, durante la fase di sviluppo, altre modifiche che hanno portato alla realizzazione di quattro differenti versioni del progetto: La versione attualmente in uso (che soddisfa i requisiti richiesti) Una versione facente uso di EJB3 Una versione in cui la parte di business logic è realizzata (per alcuni servizi) tramite l uso del Framework Hibernate Una versione in cui la parte di business logic è realizzata (per alcuni servizi) tramite l uso del Framework ibatis Le ultime tre versioni sono state realizzate solo come caso di studio per verificare la possibilità di introdurre nel progetto finale le tecnologie di volta in volta analizzate. In seguito verrà motivata la decisione per cui non sono state introdotte nella versione definitiva. Inoltre la versione definitiva dell applicazione è stata resa disponibile, oltre che come applicazione web monolitica, anche come portlet per il CMS (Content Management System) Jetspeed2 distribuito da Apache. La procedura è stata scritta per integrarsi con il sistema di autenticazione (Single Sign On) dell ente che permette l accesso ai servizi tramite l uso di un unico identificativo e di un unica password oppure tramite l uso di smart card come la carta di identità elettronica (cie) o carta nazionale dei servizi (cns). Per lo sviluppo ho fatto uso principalmente di strumenti Open Source e di Software Libero. L ambiente di sviluppo utilizzato è stato Eclipse (ver ), con installato il plugin MyEclipse (ver GA) per lo sviluppo di applicazioni enterprise. Altre librerie utilizzate sono Tomahawk (package aggiuntivo di componenti per MyFaces). La fase di deployment è stata effettuata sul servlet container Apache Tomcat (ver ). Il progetto è stato sviluppato su Linux (inizialmente su Fedora Core 6 e successivamente su Ubuntu Feisty 7.04).

7 2.2. NUOVA IMPLEMENTAZIONE 7 Nel prossimo capitolo illustrerò le varie tecnologie utilizzate per la realizzazione del servizio (ed il principale pattern di programmazione seguito), in seguito entrerò nello specifico proponendo i dettagli implementativi del servizio realizzato.

8 8 CAPITOLO 2. REQUISITI DEL PROGETTO

9 Capitolo 3 Tecnologie 3.1 Pattern MVC Model-View-Controller è il nome di un design pattern di fondamentale importanza per la realizzazione di applicazioni con interfacce grafiche nei linguaggi Object-Oriented (OO). Tale pattern obbliga il programmatore a scindere in modo netto i livelli fondamentali dell applicazione, i componenti software che implementano il modello delle funzionalità business (model), quelli che si preoccupano di realizzare la logica di presentazione (view) e i componenti che utilizzano tali funzionalità (controller). Il sempre più diffuso uso di questo pattern ha fatto si che negli ultimi anni fiorissero numerosi framework, soprattutto per il web, atti a fornire agli sviluppatori la possibilità di realizzare applicazioni sempre più aderenti a tale modello con una sempre maggiore facilità e flessibilità d uso. Alcuni dei più famosi framework che applicano tale pattern, attualmente disponibili per Java enterprise sono Java Server Faces, Struts e Velocity. Per rendere gestibile in modo efficiente lo sviluppo e la manutenzione del codice è quindi stato deciso di seguire un approccio basato sulla strutturazione del progetto secondo il pattern MVC. La parte di View e di Controller, conformemente al JSP model 2, è stata quindi realizzata tramite Java Server Faces (nell implementazione MyFaces di Apache) mentre il Model tramite JavaBeans. 3.2 Java Server Faces Il framework utilizzato ai fini della realizzazione della logica di presentazione è stato JSF. JSF applica sistematicamente il pattern MVC, rappresenta inoltre uno 9

10 10 CAPITOLO 3. TECNOLOGIE standard gestito da Sun (codice JSR 172). Di questo framework esistono varie implementazioni: oltre a quella della Sun le principali sono quelle di Oracle e Apache. Le Gui realizzate in JSF sono configurabili tramite un file XML (faces-config.xml) in cui vengono definite le pagine facenti parte della view (pagine JSP facenti uso esclusivamente di particolari taglibrary), le regole di navigazione tra di esse e i bean utilizzati per implementare la parte di controller. Ogni implementazione usa una servlet di base FacesServlet o un filtro il cui mapping è solitamente /faces/* o *.faces. 1 I principali vantaggi nell uso di questo framework risultano essere: Esistenza di componenti predefiniti che avvicinano la programmazione web a quella degli ambienti RAD, consentendo allo sviluppatore di realizzare in breve tempo interfacce web con la stessa semplicità offerta da ambienti come.net, semplicemente collegando elementi di business logic lato server tramite catene di eventi. Elementi GUI intelligenti in grado di validare in prima persona i dati inseriti dall utente e di archiviare e caricare on-demand il proprio stato da bean memorizzati lato server denominati model-object. Definizione di un nuovo paradigma di Event Handling che avvicina la programmazione in ambito web alla tipologia di gestione asincrona degli eventi utilizzata nelle applicazioni client-server. Indipendenza dal markup language: ogni modello di interazione lato server viene realizzato lato client tramite Renderer diversificati che producono un interfaccia utente in grado di soddisfare i requisiti funzionali del server al meglio delle possibilità della piattaforma utilizzata dall utente. 3.3 JasperReport Del progetto fa parte anche la gestione della stampa dei verbali delle denunce di smarrimento e ritrovo degli oggetti: per gestire la creazione di report in formato pdf ho utilizzato le librerie messe a disposizione da JasperReport poiché essendo rilasciate sotto licenza GPL sono liberamente utilizzabili e distribuibili. 1 In JSF le pagine JSP vengono, per convenzione, refenziate con estenzione.faces sul server. Tale convenzione di naming è introdotta per mostrare una separazione tra il precedente JSP Model 1 e il nuovo Framework pur mantenendo come base la stessa struttura di visualizzazione (entrambi utilizzano pagine JSP).

11 3.4. DATABASE 11 JasperReport è una libreria scritta in Java che permette di creare dei report in maniera semplice e di automatizzarne il popolamento. Il procedimento per la creazione del report, reso intuitivo dal tool ireport che consente di definire la struttura del documento in modo visuale, consta di poche semplici fasi: 1. Creazione della struttura del documento; 2. Definizione del DataSource da cui prelevare le informazioni per popolare il report; 3. Scrittura del codice necessario ad associare DataSorurce e struttura del documento. A seguito della prima fase verrà creato un file di tipo.jxrml che definisce, in xml appunto, la struttura definita in modo visuale. Tale file (che abbiamo deciso di salvare nella cartella WEB-INF/conf) contiene le associazioni necessarie per il popolamento del documento. I DataSource definibili sono di svariato tipo (è possibile, tra varie alternative, passare connessioni jdbc alle librerie jasperreport e associare al documento da popolare una query SQL), nel nostro caso abbiamo optato per un DataSource popolato dai campi di un Bean preesistente. 3.4 Database La precedente versione dell applicazione sfruttava come DBMS Oracle 9; per rendere possibile la distribuzione anche su DBMS OpenSource abbiamo strutturato la nuova versione dell applicazione in modo da garantire la compatibilità con MySQL e Postgres. Le tabelle hanno mantenuto la struttura della versione presente su Oracle per garantire la compatibilità con le pratiche precedenti alla nuova implementazione. E stata aggiunta una sola tabella per motivi che renderò noti nella sezione dedicata all analisi dello schema del database. 3.5 Log4J Sempre per rendere più facilmente gestibili future modifiche al codice tutto il progetto ho implementato funzionalità di logging tramite le librerie log4j fornite da Apache. In seguito verranno mostrati esempi di uso. Ho introdotto il logger non solo per rendere più rapida la fase di debug del progetto durante

12 12 CAPITOLO 3. TECNOLOGIE lo sviluppo ma anche per rendere la manutenzione (e le future modifiche) del servizio gestibile a chi non ha partecipato al suo sviluppo. 3.6 EJB3 A seguito della conclusione del progetto abbiamo valutato la possibilità di introdurre l uso di Enterprise Java Beans all interno del Model ed ho quindi realizzato una versione dello stesso in cui è utilizzata questa tecnologia: tale implementazione non verrà usata ed è stata introdotta solo per valutarne l usabilità. Le specifiche EJB intendono fornire una metodologia standard per implementare la logica di funzionamento delle applicazioni di tipo enterprise, applicazioni cioe che forniscono servizi via Internet. Esistono tre tipi di EJB: Entity, Session e Message Bean. Gli Entity hanno come fine la memorizzazione delle istanze degli oggetti sul server. Tali EJB di entità forniscono quindi la caratteristica della persistenza dei dati. I Session Bean gestiscono l elaborazione delle informazioni sul server. Generalmente sono una interfaccia tra i client e i servizi offerti dai componenti disponibili sul server. I Message Bean sono gli unici con funzionamento asincrono. Tramite il Java Message Service (JMS), si iscrivono a un argomento o a una coda e si attivano alla ricezione di un messaggio inviato all argomento o alla coda a cui sono iscritti. Non richiedono una istanziazione da parte dei client. Nella nostra applicazione abbiamo fatto uso di Session Bean, nello specifico degli Stateless Session Bean, per gestire le richieste al database da parte delle varie entità in gioco. Come specificato dal nome gli Stateless Session Bean non tengono traccia, a seguito della invocazione di un loro metodo, dello stato dell oggetto sul server; per ottenere una persistenza simile sarebbe stato invece necessario l impiego di Statefull Session Bean. Per permettere l uso di questa tecnologia è stato necessario configurare un application Server: i dettagli relativi alla scelta dell application server usato verranno trattati nella sezione dedicata alla implementazione del progetto contenente EJB3.

13 3.7. HIBERNATE Hibernate Hibernate è un middleware open source per lo sviluppo di applicazioni Java che fornisce un supporto di tipo ORM (object relational mapping); il suo compito è gestire la rappresentazione e il mantenimento su database relazionale di un sistema a oggetti Java. Distribuito sotto licenza LGPL, fornisce allo sviluppatore un mapping delle classi Java sulle tabelle del database e, sulla base di tale mapping, gestisce il salvataggio degli oggetti sul database. Inoltre si occupa del reperimento degli oggetti dal database, eseguendo automaticamente le query SQL necessarie a ottenere gli stessi e occupandosi del successivo instanzizione delle entità ottenute. L obbiettivo di questo middleware è esonerare il programmatore dal lavoro inerente la gestione della persistenza dei dati. Le strade per utilizzare Hibernate in un progetto sono due: 1. è possibile, contestualmente alla fase di progettazione, definire l uso di tale middleware nel progetto, in modo da strutturare il database nel modo ottimale per una gestione ad oggetti; 2. è altresìpossibile introdurre Hibernate in un progetto già in fase di sviluppo, il cui database non sia stato necessariamente studiato per una sua applicazione, effettuando un reverse engeneering delle tabelle su cui si decide di introdurre l uso del middleware. Hibernate è tipicamente usato sia in applicazioni Swing che J2EE facenti uso di servlet o EJB session beans. In un approccio MVC rientra nella parte dell applicazione dedicata al Model. A causa della decisione di non modificare in modo pesante la struttura del database preesistente, presa a seguito dell analisi dei requisiti, l introduzione di questo framework per la persistenza dei dati è stata valutata solo al termine della messa in opera dell applicazione. 3.8 ibatis Un approccio ulteriore per la gestione del Model, alternativo a quello offerto da Hibernate, è quello proposto da ibatis. Questo Framework non rientra nella categoria degli ORM, il suo fine è di rendere più facilmente manutenibile un applicazione che faccia uso di query SQL. Tramite l uso di alcuni file xml di configurazione, infatti, tale framework consente di disaccoppiare la logica applicativa dalle query al database facendo

14 14 CAPITOLO 3. TECNOLOGIE in modo da rendere una modifica relativa all SQL prodotto non influente, in modo strutturale, sul codice che ne fa uso. ibatis, inoltre, toglie al programmatore l onere della gestione delle connessioni al database rendendo possibile configurare nel dettaglio in un ulteriore file xml i dettagli con cui queste debbano avvenire.

15 Parte I La View 15

16

17 Capitolo 4 L interfaccia utente rivolta al cittadino 4.1 Analisi dei Requisiti Il servizio offerto ai cittadini ha come fine ultimo facilitare la presentazione delle denunce di smarrimento e la ricerca nel database delle pratiche avviate (sia per lo smarrimento che per il ritrovo degli oggetti). Considerando come base il servizio precedentemente esistente, ho quindi cercato di diminuire il numero di interazioni necessarie al cittadino per ottenere le informazioni ricercate. Per la parte di compilazione della denuncia di smarrimento è adesso necessario riempire un unico form con i propri dati mentre per effettuare la ricerca, dopo averne impostato i parametri, scegliere da una lista di possibili risultati quello da visualizzare. Rendendo minimali le procedure, si è quindi provato a spostare l operazione di dennucia di smarrimento dal classico servizio di ufficio, offerto dalla Pubblica Aministrazione, ad un servizio più snello e veloce affidato esclusivamente al cittadino. 17

18 18CAPITOLO 4. L INTERFACCIA UTENTE RIVOLTA AL CITTADINO 4.2 Descrizione L interfaccia pubblica del servizio consente la ricerca, da parte del cittadino, all interno del database degli oggetti che sono stati ritrovati nel territorio comunale. Precedentemente tale funzione prevedeva una ricerca vincolata a: Comune di smarrimento Categoria dell oggetto smarrito Sottocategoria Data di inserimento nel database Data di ritrovamento Tipologia di oggetto (Smarrito/Trovato) Per rendere più elastica la ricerca nella nuova versione ho sostituito archi temporali alle ricerche su singola data. Inoltre per evitare immissioni errate delle date stesse ho previsto per ogni campo data l inserzione tramite un calendario a popup. I campi riguardanti il Comune, le Categorie e le Sottocategorie prevedono una selezione da apposito menu drop down popolato al caricamento della pagina tramite tre diverse chiamate al database. I risultati della ricerca sono visualizzati in una tabella dinamica dalla quale è possibile raggiungere per ogni oggetto visualizzato una scheda dettagliata. Altra funzione resa disponibile dall interfaccia pubblica riguarda l inserimento da parte dell utente di segnalazioni di smarrimento di oggetti. Tali inserzioni nel database non vengono considerate attendibili fintanto che non sono validate da un operatore preposto allo scopo e quindi non compaiono subito come risultati di un eventuale ricerca.

19 4.2. DESCRIZIONE 19

20 20CAPITOLO 4. L INTERFACCIA UTENTE RIVOLTA AL CITTADINO 4.3 Dettagli implementativi form di Ricerca La form di ricerca presenta tre selectonemenu dedicati alla selezione del comune di interesse, della categoria e della sottocategoria dell oggetto da ricercare, quattro inputcalendar per consentire la ricerca in base all arco temporale di inserimento nel database e a quello di ritrovamento, due select- BooleanCheckbox per definire la tipologia di oggetti da ricercare (Ritrovati,Smarriti o entrambi) ed un commandbutton per eseguire il submit e la navigazione. 1 La pagina di visualizzazione risultati si compone di una datatable che visualizza l immagine (se presente), la descrizione, il luogo e la data di ritrovo di ciascun oggetto che soddisfi i criteri di ricerca. 1 I componenti elencati verranno esaminati nel dettaglio nella sezione successiva

21 4.3. DETTAGLI IMPLEMENTATIVI FORM DI RICERCA 21 Per comodità la capienza massima della tabella per pagina è fissata a 15 elementi, ciò ha comportato l uso di un componente datascroller per la generazione automatica di un indice di pagina riferibile alla tabella. Selezionando uno dei risultati si ottiene una scheda con i dettagli relativi all oggetto.

22 22CAPITOLO 4. L INTERFACCIA UTENTE RIVOLTA AL CITTADINO 4.4 Dettagli dei componenti utilizzati nel progetto selectonemenu: realizza un drop-down menu i cui valori sono caricati tramite il campo value, del componente figlio selectitems, collegato ad un metodo del bean che ha come valore di ritorno un ArrayList. Il valore scelto viene inserito nel bean tramite il campo value del componente. Nel caso del menu riguardante le categorie è stato inserito un campo valuechangelistener che consente di modificare il contenuto del menu delle sottocategorie nel momento in cui viene effettuato il refresh della pagina ad opera del commandbutton agente sul metodo specificato in tale campo. inputcalendar: questo componente sostituisce le l imputtext che precedentemente si occupavano di consentire all utente l immissione delle date di ricerca. Tale componente non necessita di controlli sui campi immessi (a differenza della precedente versione in cui tali controlli erano effettuati in Javascript) poiché valida ed invia solo le date scritte nel formato consentito (dd/mm/yyyy) e forza il refresh della pagina in caso contrario. E stato inoltre utilizzato il campo renderaspopup per consentire la scelta della data desiderata tramite un calendario visualizzato a seguito della pressione di un commandbutton disegnato dal componente. A causa del suo funzionamento il campo value di questo oggetto è utilizzato sia per accedere ai metodi di set che a quelli di get del bean usato, al momento del display infatti carica la data attuale tramite il get e al momento dell invio la aggiorna a quella desiderata tramite il set. selectbooleancheckbox: effettua il display di una checkbox, il campo value effettua il set utilizzando un valore di tipo boolean. commandbutton: il pulsante Cerca è utilizzato per realizzare sia la funzione di navigazione sia quello di ricerca. Il pulsante Sottocategorie si occupa di fare il refresh della pagina e di riottenere il valore del nuovo menu delle sottocategorie tramite il metodo AggiornaCategoria sulla cui azione è in attesa il listener del componente selectonemenu. Il pulsante pulisci si occupa solo di effettuare il refresh della pagina annullando tutte le scelte fatte precedentemente dall utente: ciò è reso possibile dal campo immediate settato a true il quale specifica che i metodi di set chiamati dai componenti debbano essere valutati ed eseguiti solo a seguito dell azione di navigazione.

23 4.5. PROBLEMI RISCONTRATI E SOLUZIONI PROPOSTE 23 DataTable 1 : componente dedicato alla costruzione dinamica di tabelle, similmente a selectitems riceve un ArrayList di cui si preoccupa di fare il display. Tramite i tag column è possibile specificare il numero delle colonne e il loro contenuto nonchè il loro titolo. Il campo rows fissa il numero di righe massimo visibile in una singola pagina della tabella. datascroller: referenziando il componente datatable si occupa del numero massimo di pagine su cui suddividere la tabella e di fornire dei link di navigazione tra le pagine stesse. commandsortheader: permette, tramite l implementzione di alcuni metodi di cui viene effettuato il binding nella datatable, di riordinare il contenuto della stessa relativamente alla colonna selezionata. graphicimage: effettua la visualizzazione di un immagine. inputfileupload: consente il submit di file da form. Per abilitare tale componente è necessario configurare alcuni filtri nel file web.xml per definire la dimensione massima dei file invia inputtext: componente usato per inserire testo nei form. outputtext: componente usato per visualizzare il contenuto dei campi dei bean nelle schede dettagliate, nei risultati delle ricerche e nella sezione di gestione dell applicazione. message: componente usato per effettuare la visualizzazione di messaggi di errore in caso di fallimento nella validazione dei dati inseriti nel form. inputhidden: componente usato per inserire valori nel form non visualizzati dall utente. 4.5 Problemi riscontrati e Soluzioni proposte Durante le fasi iniziali dello sviluppo si sono presentati numerosi problemi non legati strettamente al codice prodotto bensì all ambiente di sviluppo (in particolare al plugin MyEclipse) che proponeva librerie di MyFaces ferme alla versione e quindi solo in parte compatibili con le librerie di Tomahawk di 1 Successivamente all uso nel progetto ho scritto un articolo su questo componente e sulla flessibilità che offre per riordinare dinamicamente, tramite semplici passaggi, il suo contenuto (Tale articolo è stato pubblicato su Dev, numero 152 Agosto 2007 [13])

24 24CAPITOLO 4. L INTERFACCIA UTENTE RIVOLTA AL CITTADINO versione necessarie per l uso di parte dei componenti dei vari form. Con l aggiornamento di MyFaces alla versione i problemi di compatibilità sono stati risolti 2. Alcuni dei principali problemi incontrati sono stati: 1. Impossibilità di effettuare correttamente il submit a seguito dell inserzione dei componenti selectonemenu all interno del form. 2. Aggiornamento del selectonemenu delle sottocategorie in modo da consentire la visualizzazione delle sole sottocategorie inerenti alla categoria selezionata (funzione precedentemente realizzata in Javasript). 3. Errato rendering dei componenti inputcalendar a seguito dell impostazione del campo renderaspopup a true. 4. Formattazione delle date per la ricerca all interno del database. Per le problematiche precedentemente presentate ho applicato le seguenti modifiche alle librerie e/o ai file di configurazione: 1. Il problema era dovuto alla non corretta azione di set/get dei componenti in questione, per risolvere il problema ho aggiornato le librerie usate Ho realizzato l aggiornameto prevedendo il reload della pagina tramite un comandbutton apposito il cui metodo di riferimento viene monitorizzato dal campo valuechangelistener aggiunto nel componente selectonemenu riguardante le categorie. Inoltre durante il primo caricamento della pagina viene effettuata una doppia interrogazione al database in modo da avere a disposizione subito le sottocategorie della prima categoria della lista. <h:selectonemenu value="#{item.categoria} "valuechangelistener="#{categorielist. AggiornaCategoria}"> 2 A seguito di ricerche su forum di numerose comunità ho appreso che la retro compatibilità del package Tomahawk (l unica versione attualmente disponibile che rende correttamente utilizzabile inputcalendar e altri componenti in seguito utilizzati) è limitata alle versioni di MyFaces successive alla a causa di una modifica nella struttura interna che, nelle precedenti relase, prevedeva l inserimento di alcune classi di Tomahawk nel package di base. 3 Al termine della relazione si riporta per completezza la lista delle librerie utilizzate nel progetto (compresa versione)

25 4.5. PROBLEMI RISCONTRATI E SOLUZIONI PROPOSTE 25 <f:selectitems id="ls" value="#{categorielist.categorieitemlist}"/> </h:selectonemenu> <h:commandbutton value="sottocategorie" action="#{categorielist.aggiornacategoria}"> </h:commandbutton> <h:selectonemenu value="#{item.sottocategoria}"> <f:selectitems value="#{categorielist. subcategorieitemlist}"/> </h:selectonemenu> 3. A seguito del persistere del problema, dopo l aggiornamento delle librerie, un analisi del file web.xml di configurazione dell applicazione ha mostrato l errata compilazione dello stesso da parte dell ambiente di sviluppo (l errore è stato rintracciato grazie a interventi in merito sul sito del progetto Apache MyFaces, le impostazioni da inserire per il coretto funzionamento sono quelle di seguito riportate). <filter> <filter-name>myfacesextensionsfilter</filter-name> <filter-class>org.apache.myfaces.webapp. filter.extensionsfilter</filter-class> <init-param> <param-name>maxfilesize</param-name> <param-value>20m</param-value> </init-param> </filter> <filter-mapping> <filter-name>myfacesextensionsfilter</filter-name> <servlet-name>faces Servlet</servlet-name> </filter-mapping> 4. Per effettuare la ricerca su archi temporali ho utilizzato un oggetto di tipo SimpleDateFormat per definire il template per la data coerente a quello preesistente. Inoltre ho appurato che il database Oracle permette in una semplice query SQL di confrontare un campo di tipo Date correttamente con una stringa che rappresenta una data, ma che in caso di ricerca