IL DATA BINDER IN SPRING MVC
Prima di analizzare il binder tramite il form di inserimento, facciamo di nuovo alcune importanti considerazioni. Introduciamo ancora una volta quello che è lo schema fondamentale di Spring MVC.
Abbiamo visto come i diversi strati che ne compongono l’architettura ci permettono di ottenere delle informazioni compatibili con i nostri browser, partendo dai dati all’interno del DBMS. Passando poi per lo strato di persistenza e di servizio dove se necessario, essendo lo strato di Business Logic, subiscono delle modifiche. Si arriva poi allo strato di presentazione che grazie al Controller vengono scambiati questi dati in formato ancora grezzo con il View Resolver tramite modello, per arrivare infine alla pagina JSP che formatta i dati li passa al Dispacher Servlet e quest’ultimo fornisce la risposta al client. Fino adesso abbiamo visto come sia possibile, attraversando tutti gli strati, leggere e filtrare i dati provenienti dal DBMS, filtri creati attraverso Store Procedure e un potente meccanismo come le lambda che ti ricordo si attivano utilizzando l’istruzione Stream().
COMPONENTI USATE NEL PROGETTO
Nel progetto ho usato l’ultima versione di Bootstrap disponibile, che nel momento in cui ti scrivo è la 5.3 e fontawesome che entrambi consentono di creare interfacce utenti gradevoli. Se vuoi saperne di più su Bootstrap 5 ti consiglio di leggere i miei post sull’argomento. Come detto, finora ci siamo occupati di leggere e filtrare e dati, in questa sezione ci concentreremo sulle altre tre operazioni fondamentali, ossia creazione, update e delete. Ti parlerò in modo particolare dell’inserimento dati, come potrai constatare scaricando i sorgenti l’update e la cancellazione non introducono novità.
NB: Prima di scaricare i progetti o meglio il progetto di tuo interesse a fine sezione di questo articolo, assicurati di aver aggiornato le Store Procedure pubblicate nel precedente post all’indirizzo https://marcoalbasini.it/2023/12/spring-mvc-il-progetto-per-mysql/ Il codice SQL lo trovi a fine sezione.
CREAZIONE DELLA VISTA DI INSERIMENTO DATI ARTICOLO
Aggiungiamo una nuova vista, quindi come prima operazione andiamo ad aggiornare il nostro file tiles.xml.
Il nostro Controller dovrà ritornare il name insArticolo che estende la baseLayout. Il file JSP che creeremo sarà insarticolo.jsp. Ti riporto un estratto di questo file, è fondamentale inserire la seguente Tag Library
<%@ taglib prefix=“form” uri=“http://www.springframework.org/tags/form”%>
che ci consente di usare i form di Spring che, come vedremo, sono fondamentali; infatti, ci consentono di utilizzare quello che comunemente si chiama Data Binder, che è fondamentalmente la capacità dei nostri form di raccogliere le informazioni nei vari campi di input e trasferirle al Controller.
Nell’estratto della pagina jsp viene utilizzata la Tag Library che ti ho mostrato precedentemente utilizzando il metodo POST in quanto stiamo inviando i dati al server. Poi c’è l’elemento più importante, il modelAttribute che sarà il nome della classe che conterrà i nostri dati, nel nostro caso questa classe è la classe di dominio Articoli. Al momento ogni controllo ha una label cablata nel codice, questo non è corretto e vedremo come sia possibile evitare ciò per favorire l’internalizzazione.
CREAZIONE METODO GET NEL CONTROLLER
Quando si parla di inviare dati di un form al nostro Web Server per inserire i dati dobbiamo capire quali sono le fasi che si susseguono in questa operazione. Nella prima fase l’utente effettua una richiesta al Web Server al fine di ottenere un form vuoto e pronto per la compilazione, utilizzando il protocollo http e il metodo GET. Una volta che abbiamo inserito i dati si arriva alla fase numero due che, mediante protocollo http ma questa volta in POST, invia i dati al server per essere salvati.
Tra la prima e la seconda fase possono esserci step intermedi come la validazione dei dati che abbiamo inserito e di cui ci occuperemo prossimamente. Iniziamo ad analizzare la prima fase attraverso il Controller.
Anziché utilizzare la notazione @RequestMapping specificando il path e il metodo GET possiamo utilizzare la notazione equivalente @GetMapping che, come dice il nome, si occupa di gestire il metodo http GET del form. Analizziamo il codice. Creiamo una classe articolo vuota che passeremo alla vista per essere riempita durante la fase di POST. Dobbiamo preoccuparci poi di caricare i dati da mostrare nel form da due tabelle. La tabella delle categorie merceologiche e la tabella iva. Per fare ciò, non mi dilungo nella spiegazione, il procedimento è sempre lo stesso, si creano le classi di dominio, le opportune interfacce e le relative implementazioni nello strato di repository e in quello di servizio, facendo l’opportuno Code Injection come già abbiamo visto fare in precedenza.
PASSARE I DATI DAL CONTROLLER ALLA VISTA
Questi dati vengono estrapolati nel controller attraverso lo strato di servizio per popolare le due liste. Passiamo poi i vari dati alla vista tramite il model. Una cosa importante che ti faccio notare è l’ultima riga prima del return. insArticolo è lo stesso nome che abbiamo dato a livello di pagina jsp nel modelAttribute, questo è fondamentale perché così facendo stiamo passando la classe articolo al nostro form per poi essere popolata con il meccanismo del data binder. Ora andiamo a vedere nella pagina JSP come vengono utilizzate le due liste per popolare i rispettivi controlli.
Come vedi le combo box (controlli select) vengono popolate con i dati che abbiamo passato tramite il modello in items.
CREAZIONE METODO POST NEL CONTROLLER
Occupiamoci ora della seconda fase, abbiamo compilato il form e adesso dobbiamo inviarlo al nostro Web Server. Ti ricorderai che lato DBMS abbiamo creato delle apposite Store Procedure, una di queste si occupa di inserire o aggiornare i dati nella tabella ARTICOLI, la discriminante è il codice articolo, se non è presente si procederà con l’inserimento, altrimenti con l’update. È importante capire il meccanismo di data binder, ossia della capacità di Spring MVC di raccogliere i dati compilati nel form, valorizzare una classe che nel nostro caso sarà la classe Articoli e passare tale classe nei vari strati per poi ricavare le informazioni con i metodi getter e inserire le informazioni nel database. Creiamo un nuovo metodo nel Controller, riporto il codice.
Del BindingResult ce ne occuperemo dopo, focalizziamo la nostra attenzione sulla notazione @ModelAttribute il suo parametro insArticolo già lo conosciamo. È importante sottolineare che questo parametro deve essere lo stesso di quello fornito nel metodo che si occupa di gestire la fase GET. In particolare quando tramite modello restituiamo alla vista la classe articolo vuota il parametro è sempre insArticolo. Inoltre, la stessa insArticolo deve essere presente a livello di vista quando specifichiamo il methodAttribute. La notazione @PostMapping comunica a Spring MVC che siamo nella fase di POST, ovviamente l’URL deve rimanere lo stesso visto nella fase GET. Tramite il @ModelAttribute stiamo ottenendo una classe Articoli di nome articolo valorizzata in fase di POST.
IL PATH
Utilizziamo poi lo strato di servizio di cui abbiamo fatto il Code Injection per passare al metodo InsArticolo la nostra classe valorizzata. Alla fine con un redirect ritorniamo sulla lista articoli passando al filtro il CodArt in modo da avere una sola riga che verifica se l’articolo è stato inserito. La classe articoli vuota passata a Spring MVC nel metodo GET viene riempita tramite il path a livello di form in cui vengono specificati i campi privati della nostra classe articolo. Con il path diciamo che il nostro controllo dovrà inserire il dato compilato sul campo privato della classe di dominio articolo avente il medesimo nome. È fondamentale rispettare questa convenzione.
USO DELLA NOTAZIONE @INITBINDER
La @InitBinder ci permette di creare una mappatura di quei campi che sono autorizzati al Data Binder, oppure si dichiara in maniera esplicita quei campi esclusi dal Data Binder. Abbiamo un doppio approccio o autorizziamo tutti i campi permessi nel meccanismo di data binder oppure neghiamo esplicitamente quali sono i campi non consentiti. È nel metodo che si occupa della fase di POST che poi andremo a controllare se ci sono state violazioni del meccanismo di binding.
DOWNLOAD CODICE DELL’ARTICOLO
Il progetto AlphaShopV2.zip è per il DBMS SQL Server mentre AlphaShopV3.zip è per MySQL.
Scrivi un commento