Modifica dei contenut

L’oggetto di tipo TEIFormBean viene utilizzato anche durante il procedimento inverso, per scomporre il documento XML e insererire al suo interno i contenuti dei campi di input popolati dall’utente.

Dopo aver recuperato il documento dal database, o dopo che vi è stato aggiunto (nel quale caso i dati vengono sia salvati sul database sia presentati all’utente, compiendo i procedimenti descritti di seguito) viene eseguita l’operazione di unmashal.

Da questa operazione viene ottenuto l’albero degli oggetti valorizzati, i cui dati vengono passati nuovamente all’oggetto di tipo TEIFormBean: questo ha il compito di contenerli per presentarli all’utente in maniera tale che possa visualizzarli (nelle pagine dedicate alle epigrafi) o modificarli (nelle pagine per modificare le informazioni sulle epigrafi).

Come per l’aggiunta delle informazioni, anche per la modifica delle informazioni c’è bisogno di un metodo che prepari la form da riempire da parte dell’utente.

A differenza del caso precedente la form deve essere pre-compilata con le informazioni da modificare, in maniera tale che l’utente possa accedere agevolmente alle informazioni da gestire in maniera conforme a quella dell’inserimento. Questo richiede

Tesi Magistrale di _{​Teresa Meini}

dei passaggi in più rispetto all’aggiunta semplice di contenuti visti nel capitolo _​7.1

Aggiunta dei contenuti_​.

La prima operazione da compiere è recuperare l’id dell’epigrafe, visualizzabile anche nella barra degli indirizzi, tramite la classe service adibita allo scopo.

Senza la presenza dell’id all’interno dell’url non sarebbe possibile per la classe service ritrovare il documento interessato all’interno del database.

Una volta recuperato il documento XML come stringa, è possibile eseguire l’operazione di unmarshal per popolare l’oggetto TEIFormBean, che sarà aggiunto al ModelMap e inviato alla parte view. 109

A seguire vengono inviate le informazioni per popolare i menù a tendina e i campi di scelta radio, con una differenza rispetto alla situazione precedente, data l’esigenza di presentare all’utente i menù a tendina mantenendo la scelta selezionata in precedenza. Per fare ciò sono stati necessari una serie di controlli di tipo _{​if-else lato ​back-end} sempre in linguaggio Java all’interno di un metodo statico a parte.

Quando nella lista di elementi viene trovata la corrispondenza con una scelta effettuata questa viene presentata all’utente come prima opzione, ovvero quella selezionata, mentre le altre possibili opzioni vengono riportate successivamente.

Per dare un esempio pratico, possono esserci diverse tipologie di epigrafi che un utente potrebbe aver scelto in precedenza: sconosciuta, avviso, segnaletica e commemorativa. Nel caso in cui si voglia modificare una epigrafe salvata precedentemente come appartenente alla categoria “commemorativa”, seguendo questa serie di controlli l’opzione commemorativa sarà mostrata come la prima selezionata nel menù a tendina e le altre compariranno in ordine come opzioni successive.

Fatto ciò, le informazioni vengono inviate alla pagina JSP che ha il compito di gestirle e presentarle correttamente.

Le pagine JSP che si occupano di presentare la form per modificare i dati sono simili a quelle che gestiscono la form per l’aggiunta di nuove informazioni, ma con la differenza che il valore salvato all’interno dell’oggetto di tipo TEIFormBean viene inserito nel campo che gestisce quell’informazione tramite l’attributo value, in maniera tale di presentarle a video all’utente.

109 _{Pagina per approfondire la classe ModelMap:}

Tesi Magistrale di _{​Teresa Meini}

Nel caso degli elementi ripetuti, è stato necessario aggiungere la libreria JSTL core 110

alla pagina per compiere operazioni più complesse, permettendo anche qui di sfruttare algoritmi di tipo if-else, scrivere comportamenti che si distinguono a seconda dei casi, eccetera.

Oltre alle dinamiche già esposte nella sezione _​7.1.2.1 Inserimento di informazioni

potenzialmente illimitate per clonare le informazioni era necessario un meccanismo per

presentare gli elementi potenzialmente illimitati già inseriti capace di mantenerne la natura clonabile, e di conservare la possibilità di rimuoverli così come di aggiungerli. Vengono quindi per prima cosa stampati a video gli elementi valorizzati con gli input dell’utente; dopo di essi vengono aggiunti altri campi di input nella maniera già specificata.

Per evitare che i due procedimenti vadano in conflitto, gli input inseriti in precedenza e ri-presentati all’utente possiedono un id ancora differente rispetto a quelli dello stesso tipo clonabili e potenzialmente illimitati; condividono anch’essi però lo stesso nome per permettere il corretto funzionamento della form.

7.2.1 Ancora sulla modifica dell’xml

All’interno del documento XML viene inserita la codifica che permette di tracciare le modifiche apportate al documento, ovvero la lista degli eventi _{​change ​}effettuati:

<revisionDesc>

<listChange>

<change when="2017-02-16+01:00" who="teresa"/> </listChange>

</revisionDesc>

figura 7.2.1.1

Qualunque iscritto all’interno del portale può modificare le epigrafi già presenti; non avrebbe avuto senso cambiare il tag _{​change ogni qualvolta un utente cambia le} informazioni, dato che i tag _{​listChange ​}sono ideati per storicizzare la lista dei cambiamenti compiuti all’interno di un documento XML.

110 _{Per approfondire quali operazioni avanzate permette di compiere questa libreria:} http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/c/tld-summary.html​.

Tesi Magistrale di _{​Teresa Meini}

Quindi l’applicazione utilizza degli stratagemmi basati sull'utilizzo di input nascosti in maniera tale da costruire una listChange che è possibile recuperare e modificare all’occorrenza.

In questa maniera, all’interno del documento XML prodotto alla fine di ogni modifica, sarà sempre presente la lista esatta delle persone che hanno partecipato all’inserimento delle informazioni.