Definizione e Validazione di Form Web

Transcript

Definizione e validazione di form – Dispensa corso DHTML EspertoWeb – Francesco Leonetti
JAVASCRIPT
DEFINIZIONE E VALIDAZIONE DI MODULI WEB (FORM)
Dispensa corso DHTML a cura di Francesco Leonetti
[email protected]
Copyright 2002, EspertoWeb - www.espertoweb.it
1
INDICE
INTRODUZIONE, 3
DEFINIZIONE DI UN MODULO, 5
DEFINIZIONE DEI CAMPI DI UN MODULO, 9
CONTROLLO DEI CAMPI DI UN MODULO, 14
2
INTRODUZIONE
Con questa dispensa voglio spiegare come si costruiscono pagine come questa:
http://www.espertoweb.net/dhtml/esempi/registrazione.htm
Le pagine web generalmente offrono contenuti all’utente.
Con DHTML abbiamo visto come sia possibile costruire i contenuti in modo dinamico ed
interattivo (livelli, stili, animazioni, onclick, etc…).
Ma alle volte è utile consentire anche all’utente di trasmettere contenuti al sito ovvero al
responsabile del sito.
Il modo più semplice ed immediato per realizzare questa funzione è attraverso il link: “scrivici”
associato ad un email, come in questo esempio:
<A HREF=”mailto:[email protected]”>Scrivici</a>
Il click sul link “scrivici” realizzato in quel modo farà aprire automaticamente il programma di
posta elettronica dell’utente e presenterà la finestra di editing di un nuovo messaggio con
precompilato il campo email del destinatario (in questo esempio “[email protected]).
L’utente scriverà l’oggetto e il testo del messaggio e quindi lo invierà.
In pratica il link di tipo “mailto:” è una sorta di scorciatoia alla funzione “Scrivi Messaggio” del
programma di posta elettronica.
Questo metodo va benone ed è infatti diffusissimo su praticamente tutti i siti web.
Ci possono essere però casi in cui non si intende ricevere un generico messaggio attraverso
l’email, ma si vuole vincolare l’utente a fornire un insieme di dati strutturati, alcuni dei quali
addirittura obbligatori.
Pensiamo ad esempio ad un sito che fornisce servizio di assistenza e supporto tecnico via web.
Per garantire la massima efficienza del servizio e delle comunicazioni si vogliono limitare allo
stretto necessario le interazioni tra l’utente e l’operatore.
Per fare ciò si possono preventivamente chiedere all’utente dei dati necessari alla diagnosi di
un qualunque problema in aggiunta alla descrizione del problema specifico che l’utente vuole
porre.
Ad esempio si deve sempre indicare il sistema operativo che si usa, la sua versione, la
configurazione del computer, etc.. e infine la generica descrizione del problema.
Se in un sito del genere si lasciasse solo la possibilità di inviare un generico email si potrebbero
avere scambi di messaggi come questo:
Utente: “come mai non riesco ad aprire il file musica.rm che mi avete inviato?”
Operatore: “su quale computer sta cercando di aprire questo file?”
Utente: “uso un Macintosh”;
Operatore: “che versione di sistema operativo usa?”
Utente: “Apple OS X”;
Operatore: “che versione di realplayer usa?”
Utente: “Realplayer 8 Basic per OS 9”;
3
Operatore: “non è la versione adatta, deve scaricare Realplayer 8 Basic per OS X”
Se invece si fornisse all’utente su una pagina web un “modulo” da compilare di questo tipo:
Nome: ______________________________
Cognome: ___________________________
Configurazione Computer: ___________________________
Sistema Operativo: ___________________________
Versione Sistema Operativo: ___________________________
Descrizione del problema: ___________________________
_________________________________________________
_________________________________________________
_________________________________________________
e quindi con un click si potesse inviare (sempre per email, per ora) questo modulo
all’operatore, lo scambio di messaggi sarebbe riducibile a:
(l’operatore riceve un email corrispondente ad un modulo compilato via web con i seguenti dati
Nome: Ciccio
Cognome: Polenta
Configurazione Computer: Apple Macintosh G4
Versione Sistema Operativo: OS X
Descrizione del problema: non riesco ad aprire il file musica.rm che mi avete inviato)
L’operatore risponde:
Operatore: “probabilmente non ha scaricato una versione di realplayer compatibile con il
sistema operativo, verifichi di avere realplayer 8 Basic per OS X”
Utente: “grazie, problema risolto scaricando RealPlayer 8 Basic per OS X”.
Mizzica! :)
I moduli web possono inoltre servire per raccogliere informazioni anagrafiche di un utente che
vuole rimanere informato via email delle novità del sito, etc. etc..
In tutti questi casi c’è la necessità di costruire un modulo che consenta una raccolta strutturata
e controllata di dati invece del generico campo aperto dell’email.
In questi casi si rende utile il tag FORM per la definizione del modulo e i vari tag INPUT per la
definizione degli elementi del modulo (detti “campi”).
Ancora pià utile si rende Javascript e il DHTML per la validazione immediata dei valori immessi
nei campi in modo da evitare per esempio che come CAP si indichi un valore non numerico, o
che si lasci in bianco il campo del “Cognome” (se ritenuto necessario), etc. etc.
All’inizio quando fu introdotto DHTML fu considerato utile solo per validare i form!
4
Vediamo quindi come sfruttare questa utilità.
DEFINIZIONE DI UN MODULO
Il modulo (in inglese: form) si definisce con il tag <FORM> ed evidentemente si chiude con il
tag </FORM>.
Il tag <FORM> prevede una serie di argomenti opzionali:
NAME
nome identificativo del modulo, torna utile quando via Javascript si dovranno
modificare o verificare i valori degli elementi contenuti
METHOD
indica il modo con cui i dati devono essere trasmessi al sito, può essere
POST o GET (lo spiego meglio in seguito)
ACTION
indica l’azione che deve essere compiuta quando l’utente conferma
l’invio del modulo
ENCTYPE
indica il formato con cui i dati devono essere trasmessi
Non è necessario indicare tutti questi parametri, anzi è addirittura possibile specificarne
alcuno, in questo caso il tag <FORM> assume solo significato “coreografico” :)
Nel tag <FORM> si possono inoltre inserire codici Javascript per intercettare eventi quali
“onclick”, etc…, in particolare torna utile intercettare l’evento “onSubmit” che si verifica
quando l’utente conferma l’invio del modulo e consente quindi di chiamare una funzione
Javascript prima di procedere con quanto specificato nel parametro ACTION.
Per comprendere meglio il significato dei parametri METHOD, ACTION e ENCTYPE è bene
definire meglio a quale scopo e in quale contesto operativo il tag FORM è stato introdotto nel
codice HTML.
Noi qui ne vedremo un uso limitato all’invio “strutturato” di una email (l’ACTION cioè sarà solo
del tipo mailto:[email protected]) ma in realtà i dati raccolti tramite FORM vengono più
spesso inviati ad una “procedura” sul server che si incarica di prendere i dati, elaborarli ed
eventualmente conservarli in un database oltre che fornire un qualche feedback all’utente.
Ma il DHTML non ci consente di mettere le mani sul server per costruire “procedure” che siano
in grado di trattare i dati che provengono da FORM.
Con DHTML possiamo costruire le FORM, validare i dati e al più farceli spedire via email.
5
Lo schema seguente spiega il contesto in cui operano le ACTION gestibili in DHTML e quelle che
invece richiedono smanettamenti sul lato server (su cui i corsisti di PHP e mySQL sguazzano).
<FORM ACTION=”mailto:[email protected]”>
ACTION=”mailto:[email protected]”
modulo web (form)
A: [email protected]
browser web
client email
nuova email
PC dell’utente
In DHTML cioè il massimo che possiamo fare è invocare il programma di posta elettronica
dell’utente inviando ad esso i dati e l’email del destinatario. Dovrà essere poi l’utente, che
troverà comunque tutti i campi compilati, a confermare l’invio effettivo dell’email.
Con DHTML non possiamo uscire dal lato utente.
Nella situazione più tipica invece i dati del FORM vengono inviati non al client di posta
elettronica ma ad una procedura che risiede sul server e di cui nell’ACTION si riporta l’indirizzo:
<FORM ACTION=”http://www.espertoweb.net/modulo.php”>
ACTION=” http://www.espertoweb.net/modulo.php”
modulo web (form)
browser web
feedback
PC dell’utente
modulo.php
database
SERVER
6
In questo esempio si vede bene come il FORM continua a servire per la costruzione del
modulo, ma i dati vengono trasmessi ad un file sul server il quale si occuperà di elaborarli e
fornire una eventuale pagina di feedback all’utente del tipo “Grazie! dati ricevuti”.
Il DHTML continua ad essere utile anche in questo caso per fare in modo che i dati che
vengono trasmessi siano già in qualche modo controllati.
Inutile ad esempio far fare al server il lavoro di verifica della compilazione dei campi obbligatori
o dell’inserimento di valori corretti.
Con DHTML possiamo verificare noi se il campo “Cognome” è stato compilato senza scomodare
il server che magari dopo aver verificato che manca il cognome deve fornire una pagina di
feedback che invita a ritornare sul modulo.
Insomma, non facciamo fare al server cose che possiamo fare noi. Lui ce ne sarà grato (e
anche l’utente che risparmia tempo del modem).
Se questo schema ci è chiaro possiamo ora meglio comprendere anche il significato dei
parametri METHOD e ENCTYPE.
Il parametro METHOD indica in che modo i “campi” del FORM devono essere inviati alla
procedura indicata dall’ACTION (sia essa una procedura sul server o il programma di posta
elettronica). I modi possibili sono due: POST e GET.
Il metodo POST “impacchetta” i dati e li trasmette alla procedura dell’ACTION come unico
blocco. Spetta poi alla procedura aprire il pacchetto e ricostruire la struttura originaria dei dati.
Il metodo GET invece aggrega la struttura dei dati e i rispettivi valori immessi dall’utente in
coda all’indirizzo della procedura indicata dall’ACTION. Sarà sempre compito della procedura
recuperare dal proprio indirizzo questi dati.
Per vedere un esempio di FORM che trasmette dati con METHOD=”get” andiamo per esempio
al seguente indirizzo: http://www.google.it.
E’ il famoso motore di ricerca. Il campo in cui possiamo scrivere il nostro criterio di ricerca è
proprio un campo di una FORM al cui ACTION è associato il nome di una procedura sul server.
Provate a scrivere “espertoweb” come criterio di ricerca e quindi cliccate sul pulsante “Cerca
con Google”.
Ora osservate non tanto il contenuto della pagina quanto l’indirizzo della pagina che vi è stata
restituita: http://www.google.it/search?q=espertoweb&hl=it&lr=
Analizzando questo indirizzo possiamo dedurre che la procedura indicata nell’ACTION del
precedente FORM si trova sul server “http://www.google.it” e si chiama “search”, in pratica il
suo indirizzo completo è: “http://www.google.it/search”.
Il “?” che segue indica che il precedente FORM usa METHOD=”get” per trasmettere i dati. Ed
infatti troviamo il nome del campo (in questo caso il campo si chiama “q”) seguito dal valore
inserito dall’utente (“=espertoweb”), il carattere “&” separa i dati degli altri campi
eventualmente inviati dal FORM. In questo caso troviamo il campo “hl” che ha valore “it”
(“hl=it”) e il campo “lr” a valore nullo (“lr=”). Intuisco che il campo “hl” servirà per indicare
alla procedura la lingua dell’interfaccia (it dovrebbe stare per “italiana”). Invece “lr” non ho
idea di cosa sia. Per capirlo dovrei analizzare il codice della procedura “search” ma questo non
è consentito se non all’autore della procedura che ha possibilità di mettere le mani sul server.
Sulla base di tali dati la procedura “search” ha costruito dinamicamente il contenuto della
pagina che stiamo osservando.
La domanda ora è: quando usare POST e quando GET?
Per i nostri scopi (DHTML) è opportuno usare sempre e solo il METHOD=”post”. E’ addirittura
obbligatorio se uno dei campi del modulo è del tipo “testo libero”.
7
Il metodo GET ha infatti il vantaggio di essere più efficiente del fratello POST, ma ha un limite
imposto dalla lunghezza dell’indirizzo di una pagina, oltre 256 caratteri non si può andare.
Chiarito (spero) cosa si intende per METHOD e appreso che per i nostri scopi useremo sempre
METHOD=”post” vediamo ora cosa si intende per ENCTYPE.
Normalmente questo parametro non viene indicato. Lo si indica solo quando si vuole definire
esplicitamente il formato con cui i dati devono essere trasmessi (al programma di posta
elettronica se si usa ACTION=mailto:etc o alla procedura sul server) e viene preso in
considerazione sole se si è impostato METHOD=”post”. Se si è impostato METHOD=”get” tutto
ciò che specifichiamo come ENCTYPE viene ignorato.
La specifica del formato è conforme alla convenzione MIME la cui trattazione esula dagli scopi
del corso e della dispensa.
A noi ci basta sapere che se si vuole fare in modo che i dati vengano rappresentati nel formato
più chiaro e intellegibile da occhio umano, perché magari devono essere inseriti nel corpo della
email conseguente a ACTION=mailto:, allora dobbiamo indicare ENCTYPE=”text/plain”.
Se in qual caso non indicassimo questo formato rischieremmo di ricevere i dati rappresentati in
modo piuttosto criptico.
In tutti gli altri casi normalmente va benone il formato standard e quindi non è necessario
specificare il parametro ENCTPYE.
In definitiva ecco come potrebbe aprirsi il tag FORM per definire un modulo i cui dati devono
essere trasmessi per esempio al mio email:
<FORM ACTION=”mailto:[email protected]” METHOD=”post” ENCTYPE=”text/plain”>
….
….
</FORM>
(l’ordine con cui sono inseriti gli argomenti del tag FORM è indifferente).
In seguito vedremo come si completa il tag per fare in modo che i dati vengano controllati
prima di procedere con l’ACTION al seguito del click di conferma dell’utente.
Ora vediamo cosa si può mettere al posto di quei puntini di sospensione per costruire gli
effettivi elementi del modulo: i campi.
8
DEFINIZIONE DEI CAMPI DEL MODULO
Dopo il tag FORM può seguire un qualunque codice HTML tranne che un altro tag FORM.
E’ possibile così costruire ad esempio una tabella, metterci delle immagini etc... ma non è
possibile inserire all’interno di un tag FORM un altro tag FORM.
Tutti i tag che definiscono dei campi di INPUT vengono associati al tag FORM aperto sino a
quando si incontra il suo </FORM>.
Se un campo di INPUT viene inserito dopo il tag </FORM>, il campo corrispondente non viene
considerato parte del FORM e non verrà trasmesso tra i dati dell’ACTION.
I tag che definiscono campi di un FORM sono:
INPUT
TEXTAREA
SELECT
Il tag INPUT a sua volta si distingue in vari tipi specificato dall’argomento TYPE.
Il tag INPUT non ha un corrispondente </INPUT>, mentre è previsto </TEXTAREA> e
</SELECT>.
Tutti i tag che definiscono i campi del FORM prevedono l’argomento NAME il quale serve sia ad
etichettare il dato che viene trasmesso con l’ACTION, sia per controllare e/o impostarne il
valore via Javascript.
Passiamo in rassegna i vari valori di TYPE per il tag INPUT:
<INPUT TYPE=”text”>
Definisce un campo atto a contenere testo e/o numeri.
Prevede i seguenti argomenti opzionali:
SIZE
indica la larghezza del campo
MAXLENGTH indica il numero massimo di caratteri ammessi per quel campo.
Se l’utente digita il numero di caratteri specificato da quel valore
la pagina si rifiuta di inserirne altri.
Esempio:
Nome: <INPUT TYPE=”text” NAME=”nome_utente” SIZE=”30” MAXLENGTH=”100”>
<INPUT TYPE=”password”>
E’ identico a TYPE=”text” solo che i caratteri immessi non vengono resi visibili nel campo ma
sostituiti da un pallino.
Esempio:
Password: <INPUT TYPE=”password” NAME=”pwd_utente” SIZE=”30” MAXLENGTH=”100”>
9
<INPUT TYPE=”radio”>
Si usa quando si deve far selezionare all’utente uno ed uno solo tra due o più valori
simultaneamente proposti.
In corrispondenza dal tag viene mostrato un pallino, inzialmente bianco.
Quando l’utente clicca sul pallino, questi viene evidenziato e i pallini del tipo “radio” che hanno
lo stesso nome di quello cliccato vengono resi bianchi.
In pratica un input di tipo “radio” non è mai da solo, deve esserci almeno un altro con il suo
stesso nome. Quando il modulo viene inviato viene fatto corrispondere al nome comune dei
vari tag input di tipo “radio” il valore corrispondente al pallino in quel momento selezionato.
Parametri opzionali:
VALUE
indica il valore che deve essere fatto corrispondere al campo se questo
pallino è selezionato
CHECKED
se presente il pallino viene mostrato selezionato, normalmente
quando la pagina viene caricata tutti i pallino sono deselezionati (bianchi)
Esempio:
Sesso: <INPUT TYPE=”radio” NAME=”sesso_utente” VALUE=”M” CHECKED> M
<INPUT TYPE=”radio” NAME=”sesso_utente” VALUE=”F”> F
Notate come i due “radio button” abbiano lo stesso nome “sesso_utente”.
Il CHECKED sul primo “radio button” fa sì che la pagina quando viene caricata mostri quel
pallino già preselezionato.
Quando l’utente invierà il modulo verrà fatto corrispondere al campo “sesso_utente” il valore
corrispondente all’argomento VALUE del pallino in quel momento selezionato.
E’ possibile definire nello stesso modulo più gruppi di “radio button”.
I “radio button” dello stesso gruppo si distinguono dal NAME comune.
<INPUT TYPE=”checkbox”>
Si usa quando si vuole consentire all’utente di selezionare un valore affiancato ad un box “di
spunta”.
L’utente clicca sul box per “spuntarlo” e allo stesso modo può togliere la “spunta”. Se il campo
rimane “spuntato” il valore corrispondente viene passato quando il modulo è confermato.
VALUE
indica il valore che deve essere fatto corrispondere al campo se questo
box è spuntanto. Se non si inserisce viene fornito il valore “on”.
CHECKED
se presente il box viene mostrato già spuntato, normalmente
quando la pagina viene caricata tutti i box non sono spuntati.
Esempio:
Interessi:
<INPUT TYPE=”checkbox” NAME=”libri”> Libri
<INPUT TYPE=” checkbox” NAME=”musica”> Musica
10
<INPUT TYPE=”hidden”>
“Hidden” significa “nascosto. La definizione di campi nascosti si usa per consentire il passaggio
alla procedura che elabora il modulo (mailto: o una procedura sul server) un valore di servizio
nascosto all’utente ma che è utile per la procedura.
Ad esempio potrei passare la data in cui il modulo è stato compilato (non lasciando quindi che
sia l’utente a scriverla) o il nome del modulo o altre informazioni automatiche.
VALUE
indica il valore che deve essere fatto corrispondere al campo.
Esempio:
<INPUT TYPE=”hidden” NAME=”nome_modulo” VALUE=”registrazione al sito”>
Quando il form verrà confermato sarà disponibile anche il campo “nome_modulo” impostato
con valore “registrazione_sito”. Dell’esistenza di questo campo l’utente non è consapevole.
<SELECT>
Si usa questo tipo di campo quando si vuole consentire all’utente la selezione di un solo valore
tra un insieme predefinito di valori mostrati in una tendina “pull-down” e non attraverso dei
“radio button”.
Concettualmente infatti la selezione di un valore effettuata via SELECT è identica a quella fatta
cliccando su un pallino di una lista di “radio button”.
La differenza è data dal fatto che i valori opzionali vengono mostrati in una tendina che l’utente
può “tirare giù” (pull-down) cliccando sul campo.
I possibili valori da cui far scegliere si indicano attraverso il tag OPTION, il quale ha senso solo
all’interno di un tag SELECT.
Vediamo un esempio:
Indica la tua zona di provenienza:
<SELECT NAME=”zona”>
<OPTION>Nord
<OPTION>Centro
<OPTION>Sud
<OPTION>Isole
</SELECT>
Notate che il tag <OPTION> non richiede obbligatoriamente un </OPTION>.
L’utente cliccando sul campo vedrà la lista di opzioni e potrà selezionarne una.
Se non viene specificato in OPTION un VALUE, verrà passata alla procedura come valore del
campo SELECT il testo immediatamente successivo al tag <OPTION> selezionato. Se invece si
vuole esplicitare un valore diverso dall’etichetta mostrata all’utente, è possibile includere il
parametro VALUE all’interno del tag OPTION, come in questo esempio:
<OPTION VALUE=”n”>Nord
<OPTION VALUE=”c”>Centro
<OPTION VALUE=”s”>Sud
<OPTION VALUE=”i”>Isole
</SELECT>
11
In questo esempio l’utente vedrà la stessa lista di opzioni del precedente esempio, ma quando
avrà selezionato una voce, il valore corrispondente non sarà quello indicato dall’etichetta
visibile all’utente ma quello indicato dal parametro VALUE. Sarà questo valore ad essere
passato alla procedura in corrispondenza del campo dal nome indicato dal parametro NAME del
tag SELECT.
Se l’utente cioè seleziona “Centro”, il campo “zona” avrà valore “c” in questo esempio, avrà
valore “Centro” nell’esempio precedente.
Se non si specifica diversamente il primo valore della lista di opzioni viene visualizzato
all’utente come valore di default per quel campo. E’ possibile derogare questo comportamento
indicando esplicitamente il valore che deve essere preselezionato di default, come in questo
esempio:
<OPTION>Nord
<OPTION>Centro
<OPTION SELECTED>Sud
<OPTION>Isole
</SELECT>
il parametro SELECTED nel tag OPTION farà in modo che il valore “Sud” verrà mostrato come
opzione preselezionata di default per il campo “zona”.
<TEXTAREA>
Si usa questo tipo di campo quando si vuole offrire all’utente la possibilità di scrivere un testo
libero composto da più righe.
ROWS
altezza del campo (numero di righe)
COLS
larghezza del campo (numero di colonne)
Se il valore immesso dall’utente nel campo supera il numero di righe indicato, verrà
automaticamente visualizzata una barra di scorrimento.
Il valore del campo <TEXTAREA> è rappresentato dal testo incluso tra il tag <TEXTAREA> e il
suo </TEXTAREA>
Esempio:
Note e commenti:<br>
<TEXTAREA COLS="40" ROWS="10" NAME="note">scrivi qui un tuo commento</TEXTAREA>
Verrà mostrato un campo ampio 40 colonne e alto 10 righe al cui interno sarà contenuto il
testo “scrivi qui un tuo commento” a cui l’utente può sovrapporsi per scrivere il proprio.
Tale testo verrà passato come valore al campo “note” che rappresenta il NAME del campo
TEXTAREA.
12
<INPUT TYPE=”submit”>
Il campo di tipo “submit” rappresenta il pulsante da far premere per confermare l’invio del
modulo.
VALUE
rappresenta l’etichetta da mostrare sul pulsante.
Esempio:
<INPUT TYPE=”submit” VALUE=”Invia”>
Verrà mostrato il tipico pulsante grigio con su scritto “Invia”.
Il click su questo pulsante effettuerà l’esecuzione della ACTION indicata nel tag FORM, a meno
che in esso non sia contenuto anche un onSubmit=”….”. In questo caso, prima verrà
eseguito quanto riportato in onSubmit e, se tutto è andato bene, si procede con quanto
indicato da ACTION.
<INPUT TYPE=”reset”>
E’ analogo al pulsante di tipo “submit” solo che il suo click non produce l’esecuzione della
ACTION ma una semplice “pulitura” del contenuto dei campi.
Utile per consentire all’utente di annullare quanto ha scritto sui campi per ricominciare da
capo.
VALUE
rappresenta l’etichetta da mostrare sul pulsante.
Esempio:
<INPUT TYPE=”reset” VALUE=”Annulla”>
Verrà mostrato il tipico pulsante grigio con su scritto “Annulla”.
Il click su questo pulsante svuoterà i campi del modulo facendo restare sulla stessa pagina.
13
CONTROLLO DEI CAMPI DI UN MODULO
Una volta costruito un modulo, ogni suo elemento è riferibile via Javascripot attraverso un
riferimento DOM.
Consideriamo ad esempio il seguente modulo:
<form ACTION="mailto:[email protected]" METHOD="POST" ENCTYPE="text/plain"
name="modulo_dati" onsubmit="controlla_dati();return tutto_ok">
<input type=”hidden” name=”nome_modulo” value=”registrazione”>
Nome: <input type="text" name="nome" size="40"><br>
Cognome: <input type="text" name="cognome" size="40"><br>
E-Mail: <input type="text" name="email" size="40" onFocus="mostra('guida_email');"
onBlur="nascondi('guida_email');"><br>
Età: <input type="text" name="eta" size="40"><br>
Sesso: <input type="radio" name="sesso" value="M">Maschio <input type="radio"
name="sesso" value="F">Femmina<br>
Interessi: <br>
<input type="checkbox" name="sport">Sport <input type="checkbox" name="libri">Libri
<input type="checkbox" name="cinema">Cinema <input type="checkbox"
name="musica">Musica<br>
Zona di provenienza: <select name="zona">
<option value="Nord">Nord
<option value="Centro">Centro
<option value="Sud">Sud
<option value="Isole">Isole
</select><br>
Note e commenti: <br>
<textarea cols="40" rows="10" name="note">scrivi qui un tuo commento</textarea>
<input type="submit" name="invia" value="Invia">
</form>
Come vedete è stato definito un modulo di nome “modulo_dati” (parametro NAME del tag
FORM) e ad ogni campo è stato fornito un nome.
I singoli campi sono riferibili in questo modo:
nome_modulo.nome_campo.proprietà_campo
dove a nome_modulo bisogna sostituire il nome dato al modulo (parametro NAME del tag
FORM), e a nome_campo il nome dato al campo (parametro NAME del tag INPUT o SELECT o
TEXTAREA), a proprietà_campo la particolare proprietà di quell’elemento che ci interessa
riferire. In genere la proprietà più riferita è il valore del campo, che è dato dalla sua proprietà
value.
Nel modulo dell’esempio precedente il valore del campo “cognome” è riferibile come:
modulo_dati.cognome.value
il valore del campo “note” come:
modulo_dati.note.value
Un discorso a parte meritano i campi di tipo “checkbox” e “radio”.
14
Per verificare lo stato di un box di spunta (checkbox) si deve riferire la proprietà checked del
campo corrispondente.
Ad esempio:
modulo_dati.libri.checked
se la proprietà è true, vuol dire che il box “libri” è “spuntato”, altrimenti è stato lasciato in
bianco.
Per i radio button (i pallini) la cosa è analoga, tranne che il nome del campo identifica un array
e non una variabile singola.
Se ho ad esempio una serie di pallini (campi di INPUT TYPE=”radio”) che sono tutti dello stesso
nome (come deve essere) per vedere quale pallino è cliccato, controllo la proprietà checked,
del pallino corrispondente. Tale pallino è riferibile come elemento dell’array che definisce il
campo, numerando gli elementi partendo da zero.
Ad esempio:
modulo_dati.sesso[0].checked
indica lo stato del primo pallino dei due pallini chiamati “sesso” (quindi indica lo stato del
pallino con VALUE=”M”)
analogamente
modulo_dati.sesso[1].checked
indica lo stato del secondo pallino dei due pallini chiamati “sesso” (quindi indica lo stato del
pallino con VALUE=”F”)
e cos’ via…
Bene, ora che sappiamo come riferire gli elementi di un modulo grazie al DOM e a Javascript,
possiamo procedere con la validazione dei campi prima della conferma del suo invio.
Questa cosa è realizzata inserendo nel tag FORM l’intercettamento dell’evento onSubmit:
onsubmit="controlla_dati();return tutto_ok"
controlla_dati() è una funzione definita nella sezione HEAD e che andremo tra un po’ a
scoprire.
Quando l’utente clicca sul pulsante di tipo “submit” prima di eseguire quanto indicato dal
parametro ACTION (che in questo esempio prevede l’invio dei dati del modulo ad un email,
chiamando il client di posta elettronica dell’utente) verrà eseguita la funzione controlla_dati().
Come vedete subito dopo c’è un “return tutto_ok”.
tutto_ok è una variabile globale (definita anch’essa nello script della sezione HEAD) introdotta
per indicare se l’esito del controllo dei dati è andato a buon fine. Se tutto è andato bene
tutto_ok avrà valore true, altrimenti sarà false.
Con l’istruzione return tutto_ok viene restituito al modulo l’esito dell’elaborazione di
onSubmit. Se l’esito è negativo non viene eseguita l’ACTION e tutto rimane come stava.
E’ importante specificare questo valore di “return” perché altrimenti dopo aver eseguito quanto
indicato da onsubmit verrebbe comunque attivata l’ACTION indipendentemente dall’esito della
funzione “controllo_dati”
15
Prima di procedere con l’analisi della funzione “controllo_dati” vi faccio notare la presenza nel
tag INPUT del campo e-mail della gestione di due eventi nuovi: onFocus e onBlur:
onBlur="nascondi('guida_email');">
l’evento onFocus viene generato quando l’utente clicca sul campo in questione.
L’evento onBlur viene generato quando l’utente lascia il campo, cliccando per esempio da
qualche altra parte.
Con questo esempio ho voluto mostrare come sia possibile, intercettando questi due eventi,
eseguire azioni Javascript che possano guidare l’utente nella compilazione del modulo.
Vedete infatti che ho specificato in onFocus il richiamo della funzione mostra(‘guida_email’)
che non è altro che una funzione che visualizza un livello che ho chiamato ‘guida_email’
inzialmente tenuto nascosto (guardate la dispensa sui livelli se qualcosa vi sfugge).
Analogamente in corrispondenza di onBlur chiamo una funzione che ha il compito di
nascondere il livello dato come parametro.
Vediamo subito dunque come sono scritte queste funzioni e la funzione controlla_dati e come
tutta la pagina web si realizza.
16
Ecco quanto contenuto nella sezione HEAD della pagina di esempio per la definizione delle
variabili globali e delle funzioni Javascript:
<script language="JavaScript">
var tutto_ok = false;
function controlla_dati() {
//controllo la validità dei campi:
var errore=false;
var msg='';
if (modulo_dati.nome.value=="") {
msg = msg + 'Devi inserire il nome\n';
errore=true;
}
if (modulo_dati.cognome.value=="") {
msg = msg + 'Devi inserire il cognome\n';
errore=true;
}
if (modulo_dati.email.value=="") {
msg = msg + 'Devi inserire un email\n';
errore=true;
} else {
if (modulo_dati.email.value.indexOf ('@', 0) == -1) {
msg = msg + "hmmm... controlla meglio l'email, non mi sembra
valido...\n";
errore=true;
}
}
if (isNaN(modulo_dati.eta.value) || modulo_dati.eta.value=="" ) {
msg = msg + "Devi inserire un'età\n";
errore=true;
};
if (!modulo_dati.sesso[0].checked && !modulo_dati.sesso[1].checked) {
msg = msg + "Devi indicare il sesso\n";
errore=true;
};
if (!modulo_dati.sport.checked && !modulo_dati.libri.checked &&
!modulo_dati.cinema.checked && !modulo_dati.musica.checked) {
msg = msg + "Devi indicare almeno un interesse\n";
errore=true;
};
var commenti=modulo_dati.note.value.toLowerCase();
if ((commenti.indexOf('schifo',0) != -1) || (commenti.indexOf(‘brutt’,0) != -1)) {
msg = msg + "dai.. non può farti così schifo questo modulo... :)\n";
errore=true;
};
17
if (errore) {
alert(msg);
tutto_ok=false;
} else {
tutto_ok=true;
};
}
function mostra(livello) {
var oggetto_livello=document.all[livello];
oggetto_livello.style.visibility="visible";
}
function nascondi(livello) {
oggetto_livello.style.visibility="hidden";
}
</script>
Dunque spiego prima la logica generale, dopo entro nei dettagli.
Innanzitutto fuori dalle funzioni dichiaro la variabile globale tutto_ok
var tutto_ok=false;
inzialmente impostata a valore false, perché assumo con un velo di pessimismo che all’inizio le
cose non siano a posto :)
Il significato di questa variabile dovrebbe essere chiaro, abbiamo detto è il valore di questa
variabile che l’onSubmit restituisce subito dopo aver chiamato la funzione “controlla_dati” e
sulla base della quale si stabilisce se l’ACTION del FORM debba essere eseguita o meno.
Nella funzione controlla_dati, introduco un’altra variabile logica, chiamata errore la quale
servirà ad indicare se durante le varie verifiche di validità dei valori dei campi ci sia stato
qualche valore non ammissibile. Qui, per compensazione, sono ottimista e assumo che all’inizio
non ci siano errori:
var errore=false;
Oltre a rilevare se ci sia stato o meno un errore, mi piace fornire all’utente un’indicazione
precisa e completa del campo contenente un valore non ammesso o lasciato vuoto.
A questo scopo definisco un’altra variabile che chiamo msg, alla quale di volta volta
concatenerò una stringa corrispondente al messaggio che voglio comunicare all’utente a
seguito dell’errore. All’inizio questa stringa è vuota:
var msg=’’;
Tutto ciò che segue non fa altro che verificare i valori dei campi ed eventualmente impostare la
variabile errore a false e concatenare alla variabile msg il relativo messaggio.
Dopo questo blocco di verifica sui campi, con un’istruzione if verifico se la variabile errore è
true allora mostro con un alert il messaggio da dare all’utente e imposto la variabile globale
tutto_ok a false (in modo da inibire l’esecuzione dell’ACTION del FORM), altrimenti imposto la
variabile globale tutto_ok a true.
18
In pratica possiamo mostrare lo schema logico della funzione in questo modo:
var errore=false;
var msg='';
/*
ISTRUZIONI CHE VERIFICANO LA VALIDITA’ DEI VALORI DEI CAMPI
QUESTE ISTRUZIONI IMPOSTANO IL VALORE DELLA VARIABILE
errore PER INDICARE SE CI SIA STATO O MENO QUALCOSA CHE NON VA
E RIPORTANDO NELLA VARIABILE msg IL DETTAGLIO DI QUELLO CHE NON
E’ ANDATO.
*/
if (errore) {
alert(msg);
tutto_ok=false;
} else {
tutto_ok=true;
};
}
Ok, ora vediamo come il blocco intermedio verifica la validità dei campi.
Per verificare l’obbligatorietà di compilazione dei campi di tipo “text” non si deve fare altro che
controllare che la proprietà “value” del campo non sia vuota. Insomma che l’utente ci abbia
scritto qualcosa.
E’ quello che fanno i seguenti if:
errore=true;
}
errore=true;
}
Se il value del campo cognome del modulo modulo_dati è nullo (==””) allora imposto a
true la variabile errore (per indicare che qualcosa è andato storto) e concateno alla variabile
msg la stringa corrispondente al messaggio relativo che voglio comunicare all’utente. La
stringa termina con il carattere speciale \n per fare sì che l’eventuale successiva stringa venga
mostrata a capo e non in sequenza.
E così, via procedo in modo analogo per controllare l’esistenza di un valore in tutti quei campi
che ho stabilito debba essere obbligatorio compilare per confermare l’invio del modulo.
19
Per controllare il valore del campo email ho voluto andare oltre la verifica della sua semplice
presenza, ma addirittura verificare se l’email indicato è sintatticamente valido.
Il controllo di sintassi di un’email è un po’ più complesso di quello qui presentato.
Sintatticamente infatti in un email devono essere riconoscibili:
account_utente@dominio_server
dove dominio_server a sua volta si struttura in:
nome_dominio.suffisso_dominio
Ma non voglio qui complicarmi troppo la vita, mi accontento di verificare che nell’email ci sia
almeno il carattere ‘@’, perché se non c’è quello allora necessariamente l’email non sarà
valido. E’ pur vero che non è sufficiente che ci sia ‘@’ per garantire la validità sintattica di un
email, ma per ora accontentiamoci di questo. Sempre meglio di niente :)
Tra l’altro un email potrebbe essere sintatticamente valido ma corrispondente a nessun utente
(ad esempio scrivo: gennarino_esposito@casa_mia.it). Questo tipo di verifiche evidentemente
non sono neanche fattibili via Javascript.
Analizziamo dunque il dettaglio della verifica del campo email:
errore=true;
} else {
valido...\n";
errore=true;
}
}
Il primo if controlla se il valore del campo sia nullo e allora in questo caso abbiamo già un
errore e si dice all’utente di non fare troppo il bischero e scrivere un email. Se altrimenti il
primo if è andato bene non ci accontentiamo, con un secondo if verifico se nel valore c’è il
carattere ‘@’.
Qui abbiamo una cosa nuova: indexOf.
indexOf è un ‘metodo’ degli oggetti di tipo stringa. E’ in pratica una funzione applicabile ad
una stringa. La stringa a cui si applica è quella che ospita la funzione stessa.
Questa funzione analizza la stringa e cerca il carattere o la sequenza di caratteri (parola)
indicata come parametro, a partire dalla posizione nella stringa indicata da un secondo
parametro.
In definitiva:
modulo_dati.email.value.indexOf ('@', 0)
prende la stringa rappresentata dal valore immesso nel campo email e, a partire dalla
posizione 0 (dall’inizio quindi), cerca il carattere ‘@’. Se lo trova restituisce la posizione in cui è
stato trovato, altrimenti restituisce il valore -1.
20
Se ad esempio il campo email contenesse il valore:
[email protected]
modulo_dati.email.value.indexOf ('@', 0) restituirebbe il valore 4, che è la posizione in cui
si trova il carattere ‘@’ partendo da 0.
Se sulla stessa stringa applicassi: modulo_dati.email.value.indexOf ('@', 6) il valore
restituito sarebbe –1, perché a partire dal carattere in posizione 6 della stringa non c’è alcun
‘@’.
Se invece il valore fosse:
ciccio_polenta
modulo_dati.email.value.indexOf ('@', 0) restituirebbe subito il valore –1, perché non
trova il carattere ‘@’ partendo dal carattere in posizione 0.
In questo modo si può verificare la presenza di caratteri o parole all’interno di una stringa.
Per verificare invece che in un campo sia stato immesso un valore numerico e non magari una
stringa, analizziamo l’if successivo che controlla il valore immesso nel campo “età”:
errore=true;
};
(nota che il campo si chiama “eta”, non si possono usare vocali accentate per nomi di variabili
o funzioni Javascript).
Come vedete nella condizione dell’if appaiono due espressioni unite dall’operatore logico or
(||). La prima espressione: isNaN(modulo_dati.eta.value) usa una funzione predefinita di
Javascript che consente di valutare se un determinato valore non sia un numero.
isNaN infatti è una forma contratta per Is Not a Number (non è un numero) e restituisce
valore true se il parametro fornito non è un numero, false altrimenti.
Quindi isNaN(modulo_dati.eta.value) restituisce true se il valore contenuto nel campo eta
non è un numero, false altrimenti.
Nel caso in cui il campo è da ritenersi obbligatorio, devo considerare non valido il campo non
solo nel caso in cui non ci sia un valore non numerico, ma anche quando non ci sia nulla. Per
questo la condizione completa da verificare è:
(isNaN(modulo_dati.eta.value) || modulo_dati.eta.value=="" )
la quale è true quando il valore del campo eta non è un numero o (||) quando il valore del
campo eta è nullo.
In questo caso imposto opportunamente la variabile errore e la variabile msg.
21
Il controllo che segue mostra un esempio di riferimento a campi di tipo “radio”.
In questo caso voglio verificare che l’utente abbia cliccato su un pallino e non li abbia lasciati
entrambi bianchi. Per fare ciò devo controllare che almeno una proprietà checked degli
elementi dell’array corrispondente al campo sia true:
errore=true;
};
osservate la condizione che unisce in and (&&) le espressioni
!modulo_dati.sesso[0].checked e !modulo_dati.sesso[1].checked
ricordo che l’operatore ! sta per “negazione” logica.
La condizione quindi discorsivamente è questa:
non è vero che modulo_dati.sesso[0].checked sia vero e (&&) non è vero che
modulo_dati.sesso[1].checked sia vero.
Insomma questa condizione si verifica se non c’è neanche un checked di un pulsante radio a
true.
L’if che segue controlla se almeno un checkbox sia stato spuntato. Anche per un campo di tipo
checkbox è la proprietà checked ad indicare se il campo è spuntato o meno.
Il codice dovrebbe quindi essere ora abbastanza chiaro:
errore=true;
};
In pratica la condizione si verifica se non c’è neanche un checkbox con la proprietà checked a
true..
L’ultimo if di controllo su quanto immesso dall’utente nel campo note è solo un pretesto
dimostrativo per introdurre un’altra utile funzione (metodo) degli oggetti stringa.
Per una mia fisima infatti non voglio far inviare commenti che contengono parole in cui ci sia la
parola “schifo” come schifo, schifoso, schifosissimo, etc.. o parole in cui ci sia “brutt” come
brutto, brutta, bruttissimo, etc.. :)
Ecco il codice:
if ((commenti.indexOf('schifo',0) != -1) || (commenti.indexOf(‘brutt’,0) != -1)) {
errore=true;
};
ho introdotto una variabile che ho chiamato commenti a cui assegno il valore del campo note
trasformato però tutto in caratteri minuscoli. E’ proprio questo ciò che fa la funzione
toLowerCase() applicata alla stringa.
La variabile commenti quindi dopo questa istruzione contiene quanto immesso dall’utente nel
campo ma tutto in minuscolo. In questo modo potrò controllare anche la presenza di parole
22
quali “SCHIFO” o “SCHifo” o “ScHiFo” perché comunque grazie a toLowerCase() verrà
trasformato in “schifo”.
In modo analogo esiste la funzione toUpperCase() che trasforma tutto in … indovinate un po’.
Per cercare la presenza delle parole da me indesiderate non mi resta quindi che applicare
l’ormai nota funzione indexOf alla variabile commenti.
La condizione infatti verifica con un OR (||) se la variabile commenti contiene la stringa
‘schifo’ o contiene la stringa ‘brutt’. Se non la contiene, indexOf restituisce valore –1, se il
valore restituito da indexOf è diverso da –1 (!=-1) vuol dire che la contiene e allora no,
errore! :)
Fine del blocco di validazione dei campi.
Segue il codice che definisce le due funzioni mostra e nascondi che agiscono sul livello
passato come parametro e che ben conosciamo dalle precedenti dispense.
Ecco in definitiva il codice completo della pagina, compreso del controllo del livello gestito da
onBlur e onFocus sul campo email:
(http://www.espertoweb.net/dhtml/esempi/registrazione.htm)
<html>
<head>
<title>FLEO: modulo registrazione</title>
<script language="JavaScript">
var tutto_ok = false;
var errore=false;
var msg='';
errore=true;
}
errore=true;
}
errore=true;
} else {
valido...\n";
errore=true;
}
}
errore=true;
};
23
errore=true;
};
errore=true;
};
if ((commenti.indexOf('schifo',0) != -1) || (commenti.indexOf('brutt',0) != -1)) {
errore=true;
};
}
if (errore) {
alert(msg);
tutto_ok=false;
} else {
tutto_ok=true;
};
function mostra(livello) {
oggetto_livello.style.visibility="visible";
}
function nascondi(livello) {
oggetto_livello.style.visibility="hidden";
}
</script>
</head>
24
<body>
<b>Registrati al nostro Club:</b>
<br><br>
<form ACTION="mailto:[email protected]" METHOD="POST" ENCTYPE="text/plain"
name="modulo_dati" onsubmit="controlla_dati();return tutto_ok">
<input type="hidden" name="nome_modulo" value="registrazione">
Nome: <input type="text" name="nome" size="40"><br>
Cognome: <input type="text" name="cognome" size="40"><br>
onBlur="nascondi('guida_email');"><br>
Età: <input type="text" name="eta" size="40"><br>
Sesso: <input type="radio" name="sesso" value="M">Maschio <input type="radio"
name="sesso" value="F">Femmina<br>
Interessi: <br>
<input type="checkbox" name="sport">Sport <input type="checkbox" name="libri">Libri
<input type="checkbox" name="cinema">Cinema <input type="checkbox"
name="musica">Musica<br>
Zona di provenienza: <select name="zona">
<option value="Nord">Nord
<option value="Centro">Centro
<option value="Sud">Sud
<option value="Isole">Isole
</select><br>
Note e commenti: <br>
<textarea cols="40" rows="10" name="note">scrivi qui un tuo commento</textarea>
<input type="submit" name="invia" value="Invia">
</form>
<DIV ID="guida_email" STYLE="position=absolute;top=100;left=300;visibility=hidden">
<table border="0" bgcolor="#99ffff">
<tr><td>
mi raccomando scrivi un email valido!
</td>
</tr>
</table>
</DIV>
</body>
</html>
Notate la presenza del campo “hidden”, nascosto, il cui valore ritroverete nell’email che vi
arriverà quando proverete la pagina.
Ovviamente per provare la pagina nell’ACTION indicate il vostro email, in modo da rendervi
conto di come i dati inseriti nel modulo arrivino all’email specificato.
Quando cliccherete sul pulsante di submit dovete ovviamente trovarvi connessi ad internet e
vi si aprirà un box col quale vi si chiede di confermare l’invio dei dati via email.
Questo box appare automaticamente quando si esegue un ACTION di tipo mailto:, confermate
il tutto e vedrete il vostro client di posta elettronica spedire un messaggio (dopo aver richiesto
ulteriore conferma).
Tale messaggio verrà recapitato all’indirizzo indicato nell’ACTION.
25
L’utente finale potrebbe rimanere disorientato dalle richieste di conferma di questo email,
sarebbe opportuno prepararlo alla cosa avvisandolo con delle piccole istruzioni scritte nel
modulo, magari in vicinanza del pulsante di submit.
Come ho detto all’inizio, un modo più evoluto di elaborare i dati raccolti da un modulo consiste
nel richiamare nell’ACTION una procedura sul server, come una pagina in PHP per esempio.
Chi fosse interessato a queste linea evolutiva non ha che da rimanere nei nostri corsi :)
26

Definizione e Validazione di Form Web

Transcript

Documenti analoghi

1 inserire un dhtml in un documento gli errori piu

sizzix.co.uk

DX-CLUSTER IQ8BB-6

Software di supervisione Vijeo Citect

Maria Sharapova campionessa a Parigi

Clicca qui per scaricare l`articolo in pdf.

Dispensa Culina Logistics, lo specialista del fresco

POESIE PER ARNALDO POMODORO

scarica pdf - Dentro Le Mura