| A questo punto il form può attivarsi correttamente e passare la convalida dei dati, che nel nostro caso, come abbiamo visto, è stata fatta lato client (soluzione preferibile). Possiamo quindi occuparci delle due fasi successive: salvataggio e reindirizzamento. In linea con l'impostazione precedente, anche la query di salvataggio, sia essa di tipo insert o di tipo update, deve essere costruita dinamicamente. Il controllo sull'obbligatorietà non è più necessario, in quanto già soddisfatto in fase di convalida, quindi possiamo occuparci una-tantum di altre eventuali conversioni come ad esempio il formato delle date. Per la tabella child, se esiste, è consigliabile eliminare e riscrivere i record, sia in modalità aggiungi che in modalità modifica. Nel primo caso ovviamente non si elimina nulla ma, dato che il numero delle righe inviato in modalità modifica può essere differente da quello di partenza, questa soluzione è più pulita e comporta un notevole risparmio di codice. Ma resta un piccolo problema da risolvere per il caso delle due tabelle uno-a-molti, ed è il seguente. Ci troviamo in modalità aggiungi, visualizziamo ad esempio tre pannelli per immettere i dati di tre camere, immettiamo i dati, poi cambiamo idea, selezioniamo 2 dalla listbox e la terza camera scompare. Selezionando di nuovo 3, vediamo che i dati della terza ancora ci sono (ed è ovvio, siamo nella stessa interfaccia). Tutto ciò è corretto: l'utente salva esattamente ciò che vede in quel momento. Ora, supponiamo di essere in modalità modifica, sempre con tre camere. Se vogliamo salvare le modifiche, poniamo, togliendo l'ultima camera, il gioco riesce: in fase di salvataggio, il programma elimina le tre camere e reinserisce le prime due. Ma cosa accade se vogliamo cancellare la seconda e lasciare intatta la terza? Come di consueto, suddividiamo il problema in problemi più semplici (regola numero 3). In primo luogo, dobbiamo mettere a fianco di ogni camera un'icona cestino cliccabile, che ci permetta di intervenire. Questa icona è cliccabile, ma non può né deve eliminare la camera: questo deve avvenire solo quando si salva il form; se io rinuncio a salvare, tutto deve restare come prima. Posso però nascondere il pannello (display:none) cliccando sul cestino. Ma quando salvo il form, quest'evento deve essere intercettato, altrimenti il programma legge 3, convalida i dati di tre camere e le salva tutte e tre, visibili o no. Per questo motivo ogni pannello-camera deve avere una casella di input hidden, per cui avremo un array di caselle di input, che fungano da interruttore: la casella nascosta è vuota all'inizio, e non influisce sul funzionamento attuale; diventa on quando noi facciamo click sul cestino, ritorna vuota se noi utilizziamo la listbox. Aggiungiamo quindi questa condizione sia allo script di convalida, sia in fase di salvataggio. L'espediente è ancora imperfetto: la listbox mostra ad esempio 3 invece di 2, non possiamo applicare l'evento onchange al 3, perché è il valore corrente, quindi per arrivarci dobbiamo scegliere un altro numero, poi tornare al 3, ma comunque lo scopo principale è salvaguardato: l'utente salva ciò che vede. A salvataggio avvenuto cosa accade, dal momento che ci troviamo ancora nello stesso file? Se non facciamo nulla, riappare il form compilato con i nuovi valori e pronto per un nuovo salvataggio, a prescindere dal tipo di operazione che abbiamo effettuato (aggiunta o modifica). Ma l'utente può essere tratto in inganno e non sapere o non ricordare cosa ha fatto. Un'alternativa potrebbe essere occultare il form e visualizzare un messaggio che dice "i tuoi dati erano corretti e il form è stato inoltrato". Se il form è uno strumento di lavoro, la soluzione migliore è visualizzare -almeno parzialmente- l'elenco cui appartiene la riga aggiunta o modificata, con un pulsante modifica per ogni riga, e un pulsante unico aggiungi, entrambi per aprire un nuovo form. Per fare questo dobbiamo effettuare un reindirizzamento ad un altro file? La risposta è no: si costruisce l'elenco in alternativa al form, nello stesso file. Il perché e il come lo spiegherò quando ne avrò il tempo. Se invece dobbiamo dire all'utente che l'invio è andato a buon fine, allora conviene adottare una soluzione intermedia tra le due indicate, entrambe non pienamente soddisfacenti: dato che il form è ancora al suo posto, visualizzare il messaggio, ma anche il form, ma con tutti gli input disabled e senza più pulsanti.
|
