Newsgroup: it.comp.lang.javascript
Titolo: [?] Validazione client-side

Immagino che più o meno abbiamo tutti la nostra function per validare i
vari campi.
Ipotesi: compatibilità xhtml + (ovviamente) cross-browser
Esempio: obbligo="true" => indica che il campo deve essere compilato
Possibilità:
a) obbligo="true" nel tag => NON viene validato xhtml (evito di espandere
la dtd perché w3 non valida)
b) getAttribute/setAttribute: Testato su 
www.criosoftware.it
, va eseguito
window.onload e non è il massimo (viene scatenato al termine del
caricamento delle immagini). Opera ha qualche problema. 
c) soluzione simil-.net: per ogni campo genero un hidden con name uguale
(con aggiunta di prefisso o suffisso), disabled (così non lo passa via
form) e come value elenco dei valori (es. value="obbligo='true'
OnlyNumber='true'"). La mia function cercherà per ogni elemento della form
se esiste il corrispondente hidden.
Vi vengono in mente altre soluzioni? (la c tra l'altro fatta in .net è
comoda perché creo l'oggettino server-side e si occuperà lui di generare
tutto, alla fin fine nel codice metterò nel tag un bel obbligo="true")
 
-- 
"Affacciati affacciati benedici, guardaci
 guardaci...guardaci!
 Tanto sono quasi duemila anni che stai a guardare!"
									    E.B.

se esiste il corrispondente hidden.
Un solo hidden disabled, come value una stringa di caratteri, la
posizione del carattere nella stringa corrisponde all'indice del campo
da validare nell'elenco della form, se il carattere e' + il campo e'
obbligatorio se e' - non lo e'.
'bye

 obbligatorio se e' - non lo e'.
Sě, ma era un esempio; per esempio una textarea potrebbe avere un qualcosa
del tipo (invento): "obbligo='true' minLength='4' maxLength='100'
AllowedChar='[A-Z][0-9]-_' format4Sql='true'" ...
-- 
"E' l' ignoranza che crea l'intolleranza
 di gente cieca e senza coscienza"
									  S.S.S.

AllowedChar='[A-Z][0-9]-_' format4Sql='true'" ...
Qualcosa del tipo:
<input type="hidden" name="obbligo" disabled="disabled" value="+--"/>
<input type="hidden" name="minLength" disabled="disabled"
value="8|4|-"/>
<input type="hidden" name="maxLength" disabled="disabled"
value="16|100|-"/>
<input type="hidden" name="AllowedChar" disabled="disabled" value=""/>
<input type="hidden" name="AllowedChar" disabled="disabled"
value="[A-Z][0-9]-_"/>
<input type="hidden" name="AllowedChar" disabled="disabled" value=""/>
<input type="hidden" name="format4Sql"disabled="disabled"
value="true|true|true"/>
<input name="n1" type="password"/>
<textarea name="n2"></textarea>
<input name="n3" type="text"/>
etc.
'bye

 Qualcosa del tipo:
[CUT]
Perché a te piace di più che non un input unico per ogni controllo e un
parsing del value?
Anche perché magari su 30 campi solo 5 hanno l'obbligo, solo 3 hanno un
maxlength, solo 4 hanno un filtro sui caratteri ammessi. Come suggerisci te
dovrei mettere una hidden AllowedChar per ogni input (filtro l'input per
type=text/textarea in questo caso? E per le checkbox e radio come mi
comporto)?
Così a naso a me pare più comoda la regola uno-a-uno (per ogni input, o per
ogni gruppo di radio, 1 hidden corrispondente)
-- 
"That until there is no longer first class
And second class citizens of any nation
Until the colour of a man's skin
Is of no more significance than the colour of his eyes
Me say war"
B.M.

 ogni gruppo di radio, 1 hidden corrispondente)
Ve la butto lě. E farsi un XML separato che definisca le regole di
validazione delle form client side?
l'(X)HTML rimane pulito pulito, fai tutte le relazioni che vuoi, mantieni
una separazione codice/comportamento, e puoi darlo in mano anche ad un
designer.
-- 
ZER0
~ .. six thousand and forty three days, seven hours, fifty one minutes, eleven seconds.
That is when the world ended.

 designer.
Uhm...la logica mi piace.
Volevo perň farlo in 
asp.net
. Ti viene in mente come?
Ossia: partendo da un qualcosa del tipo (server-side)
 <miooggetto type="text" name="txt" id="txt1" obbligo AllowedChar="[0-9]"/>
Come posso effettuare il render()? 
Dovrei in teoria generare l'xml in ram e inviarlo al client (ma non saprei
come), oppure dal client richiamare una pagina dinamica che lo genera
onsubmit (ma ricadrei nel tranello xmlhttprequest)...
Ti viene in mente una qualche idea cross-browser?
Mettendo anche di avere un xml statico sul server come lo leggo dal client?
Non devo comunque passare dall'oggetto xmlhttp? (la validazione client
vorrei farla se supporta javascript, non anche se supporta xmlhttp)
-- 
"Emancipate yourselves from mental slavery;
None but ourselves can free our minds"
									    B.M.

E per le checkbox e radio come mi comporto)?
E' da studiare.
'bye

 Perche a parte AllowedChar scrivi di meno. 
Ma rimane il fatto che se su 30 campi ne devo vidimare 5 sono costretto ad
elencarli tutti e 30 nei value...
Non so, forse aveva ragione il Buddha e la verità sta nel mezzo?
Del tipo: per i boolean un campo hidden unico con elenco valori dei campi,
per i testuali invece hidden solo laddove serve?


 vorrei farla se supporta javascript, non anche se supporta xmlhttp)
perchè non utilizzi xforms? Dovresti trovare del codice open.

 Non devo comunque passare dall'oggetto xmlhttp? 
Nope. L'XmlHttpRequest è arrivato dopo. Anche prima era possibile leggere
file xml.
-- 
ZER0
~ .. six thousand and forty three days, nine hours, twelve minutes, five seconds.


 Ossia: partendo da un qualcosa del tipo (server-side)
Io ho sviluppato un applicazione in php dove mi costruivo un xml fatto 
in questo modo:
<object name="....">
	<type>...</type>
	<value>....</value>
	<maxChar>...</maxChar>
	<required>y</required>
	<validation>/.../</validation>
</object>
Questo xml lo uso per generare i form automaticamente. In questo modo 
posso fare anche validazioni particolari (quel campo va a finire dentro 
una espressione regolare) ecc ecc.
Se devo fare una select o un radio il value lo scrivo cosě: val1|val2|val3
Ciao
-- 
Andrea Azzini
Metal is more than a religion, is the only way to live.
                                 Manowar

Ti viene in mente una qualche idea cross-browser?
Al momento non mi vengono idee particolari di tipo cross-browser solo
lato client.
'bye

 perchè non utilizzi xforms? Dovresti trovare del codice open.
Uhm...preferirei fare tutto io, non ho mai usato questi oggettini di terze
parti
-- 
"Ho smesso di fumare.
 Vivrò una settimana di più.
 E in quella settimana pioverà a dirotto"
									    W.A.

 file XML generi un javascript di questo tipo:
[CUT]
Molto carino
però a questo punto che me ne faccio dell'xml? Glielo piazzo direttamente
nel tag server-side come dicevo all'inizio (tanto devo generare comunque
dinamicamente javascript...)
Mi piace perché non usa getAttribute (e quindi non va eseguita
window.onload, che era un po' troppo "tardi" per i miei gusti)


 browser con supporto XML anche solo per una banale validazione.
Dici quindi di creare una stringa xml e poi darla in pasto a un
xmlDocument? Tipo la soluzione di Agostino (lui genera un oggetto, te un
xml). Ho capito bene?


 xml). Ho capito bene?
No.
Io dicevo di scrivere le regole di validazione in un XML a sč, e lato
server unirlo per generare il relativo codice client per fare quel genere
di operazioni.
In sostanza, client-side otterresti - ad esempio - il codice fornito da
Agostino, di XML non ne avresti traccia.
In .NET puoi anche "integrare" questo passaggio nel render degli elementi,
la mia logica astraeva il linguaggio usato, in modo da separare la
scrittura dei tag FORM dalle regole di validazione. Evitando perņ, che
quest'ultime fossero "embedded" nel codice serverside, ma si trovassero
elegantemente separate in una struttura XML leggibile e modificabile a
prescindere dal codice server.
-- 
ZER0
~ .. six thousand and forty three days, nine hours, forty nine minutes, fifty five seconds.


 Agostino, di XML non ne avresti traccia.
Ah ok. Però a questo punto non mi convince molto il perché dell'xml
separato...
Cioé: ho capito quel che dici, ma alla fin fine il 99% del lavoro è nel
codice serverside per generare il javascript, il semplice file xml è banale
(e devo comunque andare a leggerlo quando valido).
Cioé: tra vantaggi e svantaggi a me sembra meglio la soluzione degli
attributi nel tag server-side.
Vero però che in questo modo è possibile modificare attributi senza
ricompilare.


 attributi nel tag server-side.
Come ti ho scritto poc'anzi:
"la mia logica astraeva il linguaggio usato"
"In .NET puoi anche "integrare" questo passaggio"
-- 
ZER0
~ .. six thousand and forty three days, ten hours, fifteen minutes, twenty eight seconds.


 la dtd perché w3 non valida)
Io userei questa possibilità qui! Anzi, l'idea è ottima e vorrei preparare 
qualcosa, magari insieme a voi che fate di javascript il vostro pane 
quotidiano!
Qui ho messo una paginetta di prova iniziale per far capire il concetto come 
l'ho visto io.
http://www.visuddhi.com/vstuff/visuddhivalida.htm
Sviluppiamo l'idea?
visuddhi 

 
http://www.visuddhi.com/vstuff/visuddhivalida.htm
Sfortunatamente il title è usato. Almeno, Firefox me lo mostra giustamente.
-- 
ZER0
~ .. six thousand and forty three days, fourteen hours, thirty three minutes, fifty five seconds.
That is when the world was ended.

 giustamente.
E usando l'alt? A me valida lo stesso.
visuddi 

 E usando l'alt? A me valida lo stesso.
Ho spostato il concetto ed una prova effettiva e valida su:
http://www.visuddhi.com/vstuff/visuddhivalida.asp
Nell'esempio la validazione di un valore numerico obbligatorio tra 4 e 100 e 
di una mail non obbligatoria.
visuddhi 

 se su browser tipo NS4.x ottengo una piccola bruttura :)
uhm..in che senso?
se estendi la dtd che usi per validare però validi secondo lo ZERO 
standard...non xhtml.
O ho capito un'altra cosa?

 standard...non xhtml.
Nono.. Anche di questo è stato discusso nei post sopracitati.
Se estendi la DTD di XHTML quel che vuoi, stai sempre agendo su tale DTD, e
quindi il documento viene validato come un documento XHTML secondo la DTD
usata (Strict, Transitional, 1.1..). Stiamo parlando di "estensione", bada
bene.
Del resto, è questa la forza di XHTML/XML. Il fatto che, come linguaggio,
sia flessibile e liberamente estendibile. La DTD di XHTML 1.1 rappresenta
più delle precedenti, questo tipo di approccio.
La sfortuna è che - purtroppo - i browser attuali considerano internamente
XHTML come HTML vecchia maniera, e non come un linguaggio XML. Il che crea
non poche difficoltà nel poter usare tutti i vantaggi appena descritti.
-- 
ZER0
~ .. six thousand and forty four days, three hours, fourteen minutes, twenty four seconds.
That is when the world ended.

 quotidiano!
Uhm...
alt serve per i browser per i non vedenti, mi chiedo cosa possa leggere un
browser di quel tipo se riempio i tag input di alt...


 E usando l'alt? A me valida lo stesso.
Fare si può fare, ma in verità io sono sempre stato restio a utilizzare
questo tipo di approcci; perché mi sembra di "snaturare" un po' il codice.
L'alt serve ad altro, così come il title.. tempo addietro si discusse di un
articolo che utilizzava altri attributi degli elementi per fare questo
genere di cose; se googleggi un po' forse lo trovi.. io ero discretamente
contrario.
Preferisco fare la generazione dei controlli server side, oppure scrivermi
semplicemente a mano i vari check. O nel caso di campi di un certo tipo,
realizzare dei wrapper.
Anche la possibilità di estendere la DTD, in verità, la uso poco.
Un tempo aggiungevo le regole direttamente sul tag. Ma alla fine mi sono
accorto che "sporcavo" il codice di markup. Stavo mischiando il
"comportamento" con il "contenuto". Da lì decisi di spostarmi a realizzare
wrapper, e utilizzare altri approcci.
Nota:
Nei browser gecko è tutt'altra storia. Sviluppando solo su loro (es XUL) è
possibile utilizzare XBL e avere un codice veramente pulito, con una
separazione davvero netta.
-- 
ZER0
~ .. six thousand and forty four days, three hours, twenty six minutes, thirty seconds.
That is when the world ended.

 più delle precedenti, questo tipo di approccio.
ah ho capito che intendi , forse ti riferivi alla modularità di xhtml.
nel caso di estendere la dtd ho subito pensato di mettere una dtd 
inline..e googleggiando ho visto che forse ti riferivi a quello...
questo thread sulla validazione client-side cmq secondo me affronta un 
problema che bene o male tutti affrontiamo.
sto leggendo con interesse le riflessioni che saltano fuori.
il mio contributo è: usare xform che sarebbe lo standard o quantomeno 
usarne i principi dato che chi ha steso la specifica ha affrontato 
questi problemi in molto tempo e forse hanno delle teste migliori delle 
nostre.
inoltre, vi sono alcuni application server tipo coldfusion che 
inseriscono delle istruzioni di validazione...si potrebbe copiare da 
loro...oppure come diceva Cristiano fare simil .NET.
Mettendo sul piatto della bilancia un po' tutte le cose...e non da 
ultimo eventuali problemi di deploy e quindi di ricompilazioni e domande 
in carta bollate magari di riavviare il server per il cambio di una 
classe java (se si opta per generazione solo lato server), secondo me la 
cosa più figa sarebbe definire un xml esterno ...mentre la piu' pratica 
e funzionale sarebbe quella di definire l'oggetto come proposto da 
Agostino ovvero:
var vForm={
  formName1:{
	txt1:{
		obbligo:true,
		AllowedChar:"[0-9]"
		//...
	},
	txt2:{
		obbligo:true
		//...
	}
  }
}
Magari se Cristiano poi posta la sua decisione finale dopo tutte le 
elucubrazioni che avrà fatto stanotte fa un favore a tutti
saluti

 elucubrazioni che avrà fatto stanotte fa un favore a tutti
Eh, il fatto che io stanotte abbia elucubrato su javascript ti indica che
ho bisogno di una donna ... :-)))
A naso integrerò in c# come normale attributo e invierò al client
l'oggettino che propone Agostino (che mi piace assai!). Sto per iniziare
questo sito, ma ci lavorerò alla prima occasione (registrazione utenti
immagino)


 Agostino 
Ma guarda che le due cose non sono separate. Come ho scritto nel post
relativo, l'XML serve solo per definire le regole di validazione e le
relazioni tra campi. Ma poi è ovvio che lato client si debba generare il
relativo codice javascript che "spiega" al browser tali relazioni e regole.
Certo,la cosa più figa sarebbe lavorare unicamente client-side con l'XML,
ma così facendo escludi tutti i browser che non hanno il supporto per i
documenti XML.
Cosa che, a ben vedere forse, si potrebbe anche fare. Del resto, ciò che
conta sono i controlli server side che devono esserci sempre.. i controlli
client side, in fondo, sono solamente facilities.
-- 
ZER0
~ .. six thousand and forty four days, four hours, forty seven minutes, sixteen seconds.


 browser di quel tipo se riempio i tag input di alt...
Sicuro che legga l'alt e non il title? Io sapevo che l'alt (alternative) era 
in caso di visualizzazione senza immagini.
In ogni caso sarebbe da controllare se i browser per non vedenti leggano 
l'alt in un campo del form dove non dovrebbe esserci.
Non ultimo, in caso accessibilità (browser per non vedenti e non solo) non 
si utilizza nemmeno il javascript, quindi si può controllare e se le pagine 
sono generate lato server non inserisci tale codice che risulterebbe inutile 
a quel punto.
Proprio in relazione al discorso "browser per non vedenti" e quindi "siti 
accessibili" vorrei precisare che il javascript non va usato o meglio 
(altrimenti mi fucilate) non deve essere indispensabile per il corretto 
funzionamento del sito. Usato si ma con criterio.
visuddhi

 funzionamento del sito. Usato si ma con criterio.
Certo...in teoria (in teoria!) quanto sopra vale sempre, non solo per non
vedenti.
Tempo fa circolava in questo newsgroup una tipa non vedente, se c'è faccia
un fischio!


l'alt in un campo del form dove non dovrebbe esserci.
Sbagliato, se manca il label deve esserci un alt:
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-text-equivalent
# Use "alt" for the IMG, INPUT, and APPLET elements, or provide a text
equivalent in the content of the OBJECT and APPLET elements. 
In pratica:
"All INPUT elements are required to contain the alt attribute or use a
LABEL."
'bye

 file XML generi un javascript di questo tipo:
Come andiamo a compatibilità con questa sintassi? (penso soprattutto a IE5,
sia win32 che Mac, immagino i vari gecko + netscape 7.x la supportino
sicuramente)


 Come andiamo a compatibilità con questa sintassi? 
La prima parte è un semplice oggetto dichiarato tramite object initializer,
quindi nessun problema.
Problemi di compatibilità, invece, ne avrai per quanto riguarda lo
statement "in" nel secondo blocco di codice, che ti consiglio di
sostituire.
-- 
ZER0
~ .. six thousand and forty four days, seven hours, sixteen minutes, fifty eight seconds.


 sostituire.
:-O
Mi piaceva un sacco...una alternativa comoda quale potrebbe essere?
for...in va meglio? (escludendo ie5-net4)


for...in va meglio? (escludendo ie5-net4)
Credo tu possa usare anche qualcosa del tipo:
mf=eval("vForm."+fona);
 if(mf){
	mt=eval("mf."+fina);
	if(mt){
		if(typeof(mt.obbligo)!="undefined"){
			alert("test obbligo");
		}
		if(typeof(mt.AllowedChar)!="undefined"){
			alert("test AllowedChar: "+mt.AllowedChar);
		}
	}
 }
'bye

 for...in va meglio? (escludendo ie5-net4)
Ehm.. non c'incastra molto :) Forse non conosci l'operatore in questione:
"The in operator returns true if the specified property is in the specified
object."
In quel caso puoi benissimo sostituire un:
	if(fina in mf){
con
	if (typeof mf[fina]!="undefined")
o anche semplicemente con:
	if (mf[fina])
(dipende dai valori nulli che tu gli dai)
Idem ovviamente per:
	if ("AllowedChar" in mt)
etc.
La differenza sostanziale che c'è nell'usare l'operatore "in", è che
ottieni true anche se la proprietà è "undefined", ma dichiarata.
Esempio chiarificatore:
	var v;
	alert( typeof window.v!="undefined" ); // false
	alert( typeof window.w!="undefined" ); // false
	alert( "v" in window ); // true
	alert( "w" in window ); // false
-- 
ZER0
~ .. six thousand and forty four days, seven hours, fifty four minutes, four seconds.


 (e quindi, in un futuro piů o meno prossimo, potrebbero leggerlo)
Giusto!
visuddhi 

 equivalent in the content of the OBJECT and APPLET elements.
Grazie dell'indicazione. Ero convinto non venisse utilizzato!
(perché non inseriscono una attributo "libero" nel dtd, sarebbe utilissimo!)
visuddhi 

 (perché non inseriscono una attributo "libero" nel dtd, sarebbe utilissimo!)
Perché l'XHTML, in quanto linguaggio XML, si può estendere liberamente, e
quindi puoi inserire tutti gli attributi che vuoi nei tag che desideri,
estendendo opportunamente la DTD per la validazione.
E' per questo che non è contemplato un attributo libero. Il problema, come
ho ripetuto poc'anzi, è che i browser attuali *non* considerano l'XHTML
alla stregua di un linguaggio XML, bensì internamente lo re-interpretano
"alla vecchia maniera". E quindi perdi tutta una serie di vantaggi che "su
carta" avresti.
-- 
ZER0
~ .. six thousand and forty four days, seven hours, fifty seven minutes, thirty four seconds.


 	if (mf[fina])
E' eccezionale!
[CUT]
Capito tutto
grazie maestro...


 mf=eval("vForm."+fona);
Sě, puň essere una soluzione, ma eval mi ha sempre dato un po' di fastidio
(cosě, a pelle), tendo quindi a non usarlo se esiste un'altra soluzione.


Tu hai ragione, ma estendere l'XHTML non è poi così banale e alla portata di 
tutti. Poi, come hai ribadito, i browser non sempre si comportano come si 
deve.
In realtà non conosco affatto quali possano essere i problemi dato che non 
sono capace di estendere l'XHTML e quindi di fare delle prove ma mi fido 
sulla parola.
Se riesco ad inserire un attributo proprietario e lo dichiaro 
nell'estensione della DTD, riesco poi a gestirlo da javascript 
tranquillamente?
Un tag libero inserito nel DTD come specifica di default io lo trovo utile e 
comodo. In ambienti di sviluppo per software (non parlo di web ma di 
programmi desktop) spesso e volentieri si ha la possibilità di utilizzare 
una proprietà da usare a piacere anche se resta la possibilità di creare 
quante proprietà si vogliono. Viene fatto per semplificare e rendere 
"trasportabile" il codice anche verso altri in maniera automatica.
Con un tag libero potrei implementare il tutto solo inserendo un link al 
javascript e utilizzando il tag senza dover inserire la modifica al DTD.
visuddhi 

 "trasportabile" il codice anche verso altri in maniera automatica.
Non è del tutto vero. Una proprietà jolly, può assumere qualsiasi
significato dipendentemente da cosa decide lo sviluppatore in questione.
Quindi non ha una sua natura ben precisa. E' troppo generica. Il che è un
problema.
Molto meglio, invece, l'approccio usato per linguaggi XML.
Puoi estendere il linguaggio XML all'infinito, per ogni elemento o
attributo nuovo hai la DTD che ne definisce la natura.
La DTD in un linguaggio XML serve appunto per sapere come "leggerlo".
In questo modo qualsiasi applicativo sa cosa aspettarsi quando parserizza
un file XML con relativa DTD. Non sono attributi o elementi generici. Ma
attributi e elementi con un significato ben preciso, significato che è
specificato nella DTD.
Per questo la possibilità di estendere l'XHTML tramite DTD è un gran
vantaggio: perché per quanti attributi "custom" tu inserirai, ci sarà
sempre una "documentazione" sia per terzi (umani o applicativi) che
definirà le estensioni da te fatte. E non sarà un guazzabuglio di nuovi
attributi messi a casaccio senza né arte né parte.
In questo modo, veramente, hai un codice "trasportabile anche verso altri
in maniera automatica".
Una proprietà dove può virtualmente starci di tutto, non ha senso. Altri
programmi non saprebbero come interpretarla. E poi, avresti un'unica
proprietà. Se ti dovessero servire più dati da inserire, dovresti infilare
tutto là dentro (vedasi ad esempio il tuo approccio per title/alt), anche
se di natura diversa.
-- 
ZER0
~ .. six thousand and forty four days, eight hours, fifty five minutes, nineteen seconds.
