Che stile, che classe!
Sto arrovellandomi per trovare, tra le tante soluzioni, quale sia la più elegante per risolvere il problema della validazione dei form.
Il problema è sempre lo stesso. Come indicare che un campo è obbligatorio, oppure deve contenere un numero intero, oppure una textarea deve avere al massimo un certo numero di caratteri?
Be' se fossimo in un mondo perfetto la soluzione ci sarebbe già, e si chiamerebbe HTML 5. Guardate ad esempio cosa hanno pensato bene quelli del WHATWG nella specifica Web Forms 2.0 sull'argomento validazione. Però in un mondo perfetto non siamo...
Ad esempio per specificare un campo obbligatorio cosa c'è di meglio di un attributo "required"? Poi basterebbe l'utilizzo di una semplice funzione JavaScript per controllarne la correttezza, come descritto per esempio nell'articolo JavaScript triggers di Peter-Paul Koch.
E allora il problema qual'è? La soluzione sembra già a portata di mano. Ebbene il problema è il seguente: la specifica HTML attuale, con l'ausilio dei famigerati DTD HTML, non permettono l'introduzione di attributi "alieni" all'interno di un elemento HTML.
Questo si guardi bene potrebbe essere contestato. Che fastidio potrebbe dare un attributo in più se gli attributi necessari fossero già presenti? Semplicemente il browser che non ne capisca il significato potrebbe scartare l'attributo, come già fanno adesso tutti i browser creati fino a questo momento!
Però il problema rimane. Una buona soluzione deve funzionare anche in caso di necessità di validazione HTML. Bisognerebbe trovare una soluzione di classe... che dico di classe, di "class"!
Vediamo come potremmo fare:
-
<input type="text" class="required integer">
Vi sembra brutto? Voi mi direte: l'attributo "class" serve ad altro, non è corretto utilizzarlo in questo modo. E invece io dico: cosa vuol dire "appartenere ad una classe"? Non significa che questa classe debba avere soltanto delle implicazioni sul modo in cui l'elemento viene visualizzato. Anzi è consigliato che il nome della classe ne sappresenti il significato e non l'aspetto. Ad esempio classe "errore" e non classe "rosso", perché magari un errore sarà sempre mostrato in rosso ma la classe ne deve indicare il significato e non l'aspetto, che devono rimanere indipendenti.
E qui volevo arrivare! Utilizzare una classe per indicare una caratteristica strutturale dell'elemento non va in conflitto con il fatto di specificare come quell'elemento deve essere visualizzato. Ad esempio io potrei volere che tutti i campi obbligatori abbiamo lo sfondo giallo, mentre tutti i campi interi abbiano un bordo rosso:
-
input.required { background-color: yellow; }
-
input.integer { border: solid 1pt red; }
E nello stesso tempo una funzione JavaScript potrebbe controllarne la validazione:
-
function validate(node)
-
{
-
try
-
{
-
if (containsClass(node, "required"))
-
checkRequired(node);
-
if (containsClass(node, "integer"))
-
checkInteger(node);
-
alert("ok");
-
}
-
catch (e)
-
{
-
alert(e.message);
-
}
-
}
-
function checkRequired(node)
-
{
-
if (!node.value)
-
throw { message: "valore mancante", target: node };
-
return null;
-
}
-
function checkInteger(node)
-
{
-
if (node.value && isNaN(parseInt(node.value, 10)))
-
throw { message: "non è un intero", target: node };
-
return null;
-
}
-
function containsClass(node, className)
-
{
-
return node.className.indexOf(className)>= 0;
-
}
Si veda bene che questo codice non vuol essere lo script migliore che si possa scrivere per gestire la validazione di un campo, ma solo un esempio su come semplice possa essere l'utilizzo di questo sistema. E le soluzione più semplici (a volte) sono le migliori:-) Questa come vi pare?
Naturalmente questo è solo l'inizio...
mi sembra una soluzione molto valida… l’idea mi piace… appena ho l’occasione la testo su un sito e potrò fare un feedback più puntuale…
solo una cosa, con js disabilitato cosa succede? come so che un campo è richiesto?
Con JavaScript disabilitato rimane unicamente la validazione lato server. La validazione dovrebbe essere principalmente lato server, dato che comunque può accedere al sito qualsiasi agente, browser o programma di qualsiasi tipo che spedisce dei dati di cui non è possibile sapere la validità a priori.
Poi via JavaScript è possibile inserire un controllo per migliorare l’interazione con l’utente. Ad esempio se un campo obbligatorio non è presnet perché dovrei spedire l’intera richiesta al server se posso eseguire un controllo preventivo lato client?
perfettamente d’accordo: la validazione js non sostituisce quella lato server, serve solo a ottimizzare l’”esperienza” dell’utente…
come giustamente dice bigliard alleggerire la comunicazione client/server quando si può.. un po’ come per l’ajax: perchè ricaricare tutta la pagina quando l’informazione da veicolare è piccola e risibile?
infatti ti volevo chiedere proprio questo: non varrebbe la pena di gestire le form via ajax?
un po’ come fa google: inserisco l’username e, se risponde alle necessità minime (tipo lunghezza minima o massima consentite), controllo subito lato server se è disponibile, in modo da avere un feedback immediato.
e aggiungo: mi trovo perfettamente d’accordo anche sul discorso classe=logico e non aspetto… anche perchè pensando a un restyle di un sito (mantenendo il tuo esempio) non è detto che l’errore rimanga rosso.
sì, in molte occasioni l’utilizzo di Ajax può migliorare sia l’interazione con l’utente che l’utilizzo delle risorse di rete. Ad esempio in un form di login o nell’esempio che facevi tu… bisogna avere solo un po’ di fantasia per sbizzarrirsi:-)