L'operazione più comune in un sito web è la creazione di un form. Un form può avere due
finalità:
- Inviare dati che, senza essere memorizzati in un database, sono utilizzati per operazioni successive (esempio,
inviare una e-mail, indirizzare a una pagina web).
- Aggiungere dati in un database, oppure aggiornare dati preesistenti.
Occupiamoci per il momento della prima condizione di questo secondo caso: aggiunta in un database.
Una visione semplicistica del compito istintivamente sarebbe portata a procedere in questo modo:
si crea un form in una pagina HTML, e lo si spedisce ad una pagina ASP o PHP, che processa i dati inviati,
ne controlla la validità, e li inserisce nel database.
Semplice, ma sbagliato. La prima azione -creare una pagina HTML- contraddice già la
nostra regola numero 5: il
codice non deve contenere duplicazioni. Ora, dichiarare nomi e caratteristiche dei campi in un form per
scrivere in un database quando queste informazioni sono già presenti nel database,
costituisce appunto una duplicazione del codice, oltre ad essere potenziale fonte di errori involontari.
Se infatti si cambia qualcosa nel database, dobbiamo intervenire nella pagina HTML per riflettere tali
cambiamenti. Inoltre, la seconda condizione (modifica) che per forza di cose richiede
una pagina dinamica, sarebbe a sua volta un ulteriore duplicato.
Sia ASP che PHP contengono istruzioni in grado di aprire una tabella e leggere i nomi dei campi e le loro
proprietà. La sintassi cambia leggermente nei due linguaggi, ma le proprietà che ci interessano sono sempre le
stesse: nome del campo, tipo di campo (numerico, carattere, blog, logico, data, etc...), lunghezza massima
consentita, obbligatorietà. Cioè, tutte le informazioni che dovremmo scrivere nel form in HTML.
Avendo disponibili queste proprietà, che è possibile prelevare anche se la tabella è
vuota, noi siamo in grado di costruire la label di ogni campo, il tipo di input, il tipo di
convalida, e inibire i tasti che immettono caratteri non consentiti. Passiamo in rassegna le problematiche,
una ad una:
- Label
Se siamo noi a creare il database, è buona norma evitare sigle astruse e scrivere
invece in chiaro i nomi dei campi. Quindi, ad esempio, non DATARIF, ma data_di_riferimento,
non CODCLI, ma codice_cliente. Se invece il database esiste già e contiene appunto sigle
astruse, si può sempre costruire una query che con gli alias traduca in italiano i singoli campi: il
risultato finale sarà comunque lo stesso.
- Tipi di campo
Possono variare da database a database, così come ogni database può
trattarli in maniera differente, ma si possono raggruppare in insiemi. Per ognuno di questi insiemi è
possibile ricorrere a un differente tipo di input, come illustra la tabella seguente:
| Testo con un limite massimo | casella di input con la proprietà maxlength settata sulla
lunghezza massima consentita per il campo, e lunghezza fisica calcolata sempre su questo valore, per offrire
visivamente un'idea approssimativa dell'input consentito |
| Testo lungo senza limite | textarea |
| Data, oppure data e ora | gruppo di caselle di input che contenga le istruzioni necessarie per
scartare le date non valide. Oppure, uno dei tanti tool provvisti di calendario |
| Numero | Casella di input, anche con allineamento a destra e, intercettando il tipo di numero
(intero, con decimali, o valute), abbinato possibilmente a qualche script in grado di inibire alla fonte i
tasti non consentiti |
| Flag | checkbox |
- Obbligatorietà
Intercettando se il campo corrispondente ammette valore NULL, e dato per
scontato che l'obbligatorietà a livello di database coincide con quella dell'input, si tratta di
dotare visivamente di asterisco i campi obbligatori e produrre per il form uno script client di convalida
appoggiato all'evento onsubmit. Tale script, anche se statico, deve essere creato dinamicamente, ed
occorre forzare l'ingresso del server occultando la parola script. Quindi
<%="<script>"%> in ASP, <?="<script>"?> in PHP.Casi particolari,
come l'indirizzo e-mail, richiedono un trattamento aggiuntivo, in quanto oltre
all'obbligatorietà occorre verificare anche la presenza e la posizione della chiocciola (@) e del
punto.
Rigorosamente, tutte le caselle di input avranno come name e id il
nome del campo, cioè la proprietà name prelevata. I vantaggi più evidenti di questo
modo di procedere sono tre:
- Non abbiamo bisogno di scrivere le query, nè quella per costruire il form, nè quella
per salvarlo: è sufficiente creare un ciclo che interroghi la tabella estraendo i nomi dei campi.
- Se si apportano modifiche al database, non è necessario rimettere mano
al codice (regola numero 6).
- Il codice è astratto rispetto all'oggetto che tratta, quindi può essere
riutilizzato con altri database.
Infine: che dire dell'action? Non c'è motivo di
indirizzare il form verso un'altra pagina. Sono rare le circostanze in cui questo è consigliabile
(regola numero 1); nella
stragrande maggioranza dei casi, il file deve essere sempre lo stesso, e contenere il codice javascript
di convalida e le istruzioni per il salvataggio all'inizio, la parte visibile alla fine. Solo
quando l'operazione si è conclusa positivamente si inserisce eventualmente il reindirizzamento.
Si tratta di una prassi consolidata che nel nostro caso, affiancata al prelievo
dalla struttura del database, presenta un vantaggio aggiuntivo non secondario.
Come abbiamo detto all'inizio, il form può servire per aggiungere o modificare dati.
L'interfaccia da utilizzare deve essere assolutamente la stessa per entrambi i casi. Lo stato aggiungi
o modifica
proviene dalla pagina che chiama il form; la differenza consiste solo nel fatto che il primo stato non richiede
alcun parametro, il secondo richiede l'ID della riga da modificare.
Dopo di che, se ci troviamo in modalità modifica, la query che genera il form sarà la stessa
che recupera i dati della riga corrispondente.
Quindi nel primo caso i valori di input saranno vuoti oppure di default, nel secondo saranno valorizzati.
Ma ai nostri fini non cambia nulla, se non il fatto che il form deve comunicare a se stesso in quale
modalità si trova: come vedremo più avanti, anche la routine di salvataggio può essere una
sola, pur contemplando questa differenza.
|
