validation de formulaire

Pascal PONCET

01/07/2009 à 19:10

Mickaël Wolff a écrit :

C'est ce qui est sémantiquement le plus correct. À savoir que
l'attribut HTML class contient une liste de mots.

Bonjour Mickaël,

Je vais peut-être faire hurler, mais je ne crois pas qu'il soit
totalement "hérétique" de profiter de la tolérance (obligatoire) des
navigateurs pour utiliser des attributs personnalisés.

Par exemple, en conservant une sémantique correcte, un attribut
"subtype" pourrait faire l'affaire.
Exemple :
<input type="text" subtype="date_jjmmaaaa" name="birthdate">

Attention, seul IE reconnaîtra la propriété "formElement.subtype", donc
il faudra plutôt utiliser "formElement.getAttribute('subtype')" pour
récupérer la valeur.

Evidemment, le nec plus ultra serait de générer un document XHTML, avec
un espace de nommage spécifique et un attribut préfixé (cf XForms).

Cordialement,
Pascal

SAM

01/07/2009 à 20:41

Le 6/30/09 11:07 PM, J-F Portala a écrit :

Merci de ta réponse,
je t'avoue que je me sens un peu léger
par rapport au code que tu as écrit dans ton exemple.

Heu ...
ça ne me semblait pas très sorcier.
J'aurais peut-être dû le documenter ?

J'écris du javascript bien plus basique, et il faut que j'évolue.
Merci pour ton exemple.

Je pense que l'on est obligé de passer du javascript dans chaque élément si
on veut aller plus loin dans la validation, limiter une valeur
par un min ou un max, etc

Il peut paraitre plus simple de faire comme tu dis
surtout si on a une moulinette php qui ne sais faire que comme ça
-> appel à la BdD --> code HTML résultant --> JS additionnel
le tout en fonction de l'appel

Mais, possiblement, on peut faire évoluer cette moulinette pour tout
regrouper le JS dans le head.
Ha! ça doit être un peu + compliqué ?!

J'avais essayé de capter l'évenement onkeypress pour ne conserver que les
codes de touches qui allaient bien ( entier signé ou non, decimal...)
Là aussi on est obligé de mettre du javascript pour chaque champ.

Oui du moment qu'on veut que ça se passe illico sans AR au serveur.

Je travaille beaucoup à partir de tables mysql, où assez rapidement, il faut
faire un formulaire pour renseigner ou modifier les tables.
J'ai essayé de créer des fonctions comme celle ci pour saisir des entiers
par exemple.

Ouille! du php ! :-(

emberlificoté, me semble-ce.

Tout d'abord, voici qques exemples de JS de contrôle à la volée :
(de ce que je crois savoir,
onKeyPress ne retourne pas la même chose que onKeyDown)

1) Window IE only (?) :
======================
// chiffres seuls + touche Entrée :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || !(c<48 || c>57));"

// chiffres + Entree + backspace + fleches :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || c==8 || (c>36 && c<40) !(c<48 || c>57));"

// minuscules non accentuées + Entree + backspace + fleches :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || // touche Entrée
c==8 || // backspace
(c>36 && c<40) || // flêches up/down/left/right
(c>96 && c<123) // de 'a' à 'z'
);"

2) multi navigateurs :
===================== (avec autre méthode : par les RegExpressions)

// chifres + Entree + backspace + fleches :

onkeypress="
var k = (event.which | event.keyCode).toString();
// les keycodes acceptables :
var r = /(8|13|3[789]|4[089]|5[0-7])/;
k = !k.search(r); // ok ? true/false
// pour IE
event.returnValue = k;
// pour Firefox
return k;"

// minuscules non accentuées + Entree + backspace + fleches :

onkeypress="
var k = (event.which | event.keyCode).toString();
var r = /(8|13|3[789]|9[789]|1[01][0-9]|12[012])/;;
event.returnValue = k = !k.search(r);
return k;"

Le PHP possible :
================ (non testé - j'y comprends rien en php)

function AddInt (
$label,$name,$size,$unit='',$value='',$readonly=0,$submitúlse) {
$strread = ( $readonly == 0 )? "" : "readonly";
print("<div id="row">
<span id='label'>$label</span>
<span id='value'>
<input type='text' name='$name'
value='$value' $strread size='$size'");
if ( $submit )
{
print("
ONKEYPRESS="var c = event.keyCode;
event.returnValue = (c= || (c>47 && c<58));">
</span>");
}
else
{
print("
ONKEYPRESS="var c = event.keyCode;
event.returnValue (c > 47 && c <58);">
</span>");
}
if ( $unit != '' )
print("
<span id='unit'>$unit'</span>") ;
print("
</div>");
}

En espérant qu'au bout du compte on se se retrouve paq avec x divs de
même ID ? !

Je me rends compte que je suis quand même obligé de contrôler par javascript
si les valeurs sont correctes en plus du test par caractère. Cela fait deux
appels pour chaque champ.

Ou bien on se contente de la seule vérif de validité du champ ?
Comme ça ça évite à l'autre de s'énerver sur son clavier qui ne marche
plus ! ? ;-)

J'avais lu que dans html5, les types seraient contrôlés à la frappe clavier.

No sè.

Encore merci de ton aide

Oui, bon ... je sais pas.

--
sm

Le 6/30/09 11:07 PM, J-F Portala a écrit :

Merci de ta réponse,
je t'avoue que je me sens un peu léger
par rapport au code que tu as écrit dans ton exemple.

Heu ...
ça ne me semblait pas très sorcier.
J'aurais peut-être dû le documenter ?

J'écris du javascript bien plus basique, et il faut que j'évolue.
Merci pour ton exemple.

Je pense que l'on est obligé de passer du javascript dans chaque élément si
on veut aller plus loin dans la validation, limiter une valeur
par un min ou un max, etc

Il peut paraitre plus simple de faire comme tu dis
surtout si on a une moulinette php qui ne sais faire que comme ça
-> appel à la BdD --> code HTML résultant --> JS additionnel
le tout en fonction de l'appel

Mais, possiblement, on peut faire évoluer cette moulinette pour tout
regrouper le JS dans le head.
Ha! ça doit être un peu + compliqué ?!

J'avais essayé de capter l'évenement onkeypress pour ne conserver que les
codes de touches qui allaient bien ( entier signé ou non, decimal...)
Là aussi on est obligé de mettre du javascript pour chaque champ.

Oui du moment qu'on veut que ça se passe illico sans AR au serveur.

Je travaille beaucoup à partir de tables mysql, où assez rapidement, il faut
faire un formulaire pour renseigner ou modifier les tables.
J'ai essayé de créer des fonctions comme celle ci pour saisir des entiers
par exemple.

Ouille! du php ! :-(

emberlificoté, me semble-ce.

Tout d'abord, voici qques exemples de JS de contrôle à la volée :
(de ce que je crois savoir,
onKeyPress ne retourne pas la même chose que onKeyDown)

1) Window IE only (?) :
======================
// chiffres seuls + touche Entrée :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || !(c<48 || c>57));"

// chiffres + Entree + backspace + fleches :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || c==8 || (c>36 && c<40) !(c<48 || c>57));"

// minuscules non accentuées + Entree + backspace + fleches :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || // touche Entrée
c==8 || // backspace
(c>36 && c<40) || // flêches up/down/left/right
(c>96 && c<123) // de 'a' à 'z'
);"

2) multi navigateurs :
===================== (avec autre méthode : par les RegExpressions)

// chifres + Entree + backspace + fleches :

onkeypress="
var k = (event.which | event.keyCode).toString();
// les keycodes acceptables :
var r = /(8|13|3[789]|4[089]|5[0-7])/;
k = !k.search(r); // ok ? true/false
// pour IE
event.returnValue = k;
// pour Firefox
return k;"

// minuscules non accentuées + Entree + backspace + fleches :

onkeypress="
var k = (event.which | event.keyCode).toString();
var r = /(8|13|3[789]|9[789]|1[01][0-9]|12[012])/;;
event.returnValue = k = !k.search(r);
return k;"

Le PHP possible :
================ (non testé - j'y comprends rien en php)

function AddInt (
$label,$name,$size,$unit='',$value='',$readonly=0,$submitúlse) {
$strread = ( $readonly == 0 )? "" : "readonly";
print("<div id="row">
<span id='label'>$label</span>
<span id='value'>
<input type='text' name='$name'
value='$value' $strread size='$size'");
if ( $submit )
{
print("
ONKEYPRESS="var c = event.keyCode;
event.returnValue = (c= || (c>47 && c<58));">
</span>");
}
else
{
print("
ONKEYPRESS="var c = event.keyCode;
event.returnValue (c > 47 && c <58);">
</span>");
}
if ( $unit != '' )
print("
<span id='unit'>$unit'</span>") ;
print("
</div>");
}

En espérant qu'au bout du compte on se se retrouve paq avec x divs de
même ID ? !

Je me rends compte que je suis quand même obligé de contrôler par javascript
si les valeurs sont correctes en plus du test par caractère. Cela fait deux
appels pour chaque champ.

Ou bien on se contente de la seule vérif de validité du champ ?
Comme ça ça évite à l'autre de s'énerver sur son clavier qui ne marche
plus ! ? ;-)

J'avais lu que dans html5, les types seraient contrôlés à la frappe clavier.

No sè.

Encore merci de ton aide

Oui, bon ... je sais pas.

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Le 6/30/09 11:07 PM, J-F Portala a écrit :

Merci de ta réponse,
je t'avoue que je me sens un peu léger
par rapport au code que tu as écrit dans ton exemple.

Heu ...
ça ne me semblait pas très sorcier.
J'aurais peut-être dû le documenter ?

J'écris du javascript bien plus basique, et il faut que j'évolue.
Merci pour ton exemple.

Je pense que l'on est obligé de passer du javascript dans chaque élément si
on veut aller plus loin dans la validation, limiter une valeur
par un min ou un max, etc

Il peut paraitre plus simple de faire comme tu dis
surtout si on a une moulinette php qui ne sais faire que comme ça
-> appel à la BdD --> code HTML résultant --> JS additionnel
le tout en fonction de l'appel

Mais, possiblement, on peut faire évoluer cette moulinette pour tout
regrouper le JS dans le head.
Ha! ça doit être un peu + compliqué ?!

J'avais essayé de capter l'évenement onkeypress pour ne conserver que les
codes de touches qui allaient bien ( entier signé ou non, decimal...)
Là aussi on est obligé de mettre du javascript pour chaque champ.

Oui du moment qu'on veut que ça se passe illico sans AR au serveur.

Je travaille beaucoup à partir de tables mysql, où assez rapidement, il faut
faire un formulaire pour renseigner ou modifier les tables.
J'ai essayé de créer des fonctions comme celle ci pour saisir des entiers
par exemple.

Ouille! du php ! :-(

emberlificoté, me semble-ce.

Tout d'abord, voici qques exemples de JS de contrôle à la volée :
(de ce que je crois savoir,
onKeyPress ne retourne pas la même chose que onKeyDown)

1) Window IE only (?) :
======================
// chiffres seuls + touche Entrée :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || !(c<48 || c>57));"

// chiffres + Entree + backspace + fleches :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || c==8 || (c>36 && c<40) !(c<48 || c>57));"

// minuscules non accentuées + Entree + backspace + fleches :

onkeypress="var c = event.keyCode;
event.returnValue = (c= || // touche Entrée
c==8 || // backspace
(c>36 && c<40) || // flêches up/down/left/right
(c>96 && c<123) // de 'a' à 'z'
);"

2) multi navigateurs :
===================== (avec autre méthode : par les RegExpressions)

// chifres + Entree + backspace + fleches :

onkeypress="
var k = (event.which | event.keyCode).toString();
// les keycodes acceptables :
var r = /(8|13|3[789]|4[089]|5[0-7])/;
k = !k.search(r); // ok ? true/false
// pour IE
event.returnValue = k;
// pour Firefox
return k;"

// minuscules non accentuées + Entree + backspace + fleches :

onkeypress="
var k = (event.which | event.keyCode).toString();
var r = /(8|13|3[789]|9[789]|1[01][0-9]|12[012])/;;
event.returnValue = k = !k.search(r);
return k;"

Le PHP possible :
================ (non testé - j'y comprends rien en php)

function AddInt (
$label,$name,$size,$unit='',$value='',$readonly=0,$submitúlse) {
$strread = ( $readonly == 0 )? "" : "readonly";
print("<div id="row">
<span id='label'>$label</span>
<span id='value'>
<input type='text' name='$name'
value='$value' $strread size='$size'");
if ( $submit )
{
print("
ONKEYPRESS="var c = event.keyCode;
event.returnValue = (c= || (c>47 && c<58));">
</span>");
}
else
{
print("
ONKEYPRESS="var c = event.keyCode;
event.returnValue (c > 47 && c <58);">
</span>");
}
if ( $unit != '' )
print("
<span id='unit'>$unit'</span>") ;
print("
</div>");
}

En espérant qu'au bout du compte on se se retrouve paq avec x divs de
même ID ? !

Je me rends compte que je suis quand même obligé de contrôler par javascript
si les valeurs sont correctes en plus du test par caractère. Cela fait deux
appels pour chaque champ.

Ou bien on se contente de la seule vérif de validité du champ ?
Comme ça ça évite à l'autre de s'énerver sur son clavier qui ne marche
plus ! ? ;-)

J'avais lu que dans html5, les types seraient contrôlés à la frappe clavier.

No sè.

Encore merci de ton aide

Oui, bon ... je sais pas.

--
sm

SAM

02/07/2009 à 07:41

Le 7/1/09 12:28 PM, J-F Portala a écrit :

Bonjour,
Je reviens un peu à la charge
concernant les validations:
J'en vois à 3 niveaux:
- en capturant l'evenement on keypress (au niveau touche)
- au niveau du type de champ (email - password - entier - entier signé
etc...comment les distinguer )
- au niveau du champ lui même (valeurs min max...)

La routine proposée par Stéphane est intéressante mais est spécifique
name=='email' ou 'pass1'

Ha! oui! comme précisé : "vérif *minimale*"
un peu élargie dans la démo sur cJoint

Sommes toutes avec un formulaire un peu standard il n'y a pas grd' chose
à vérifier
- le champ est rempli ?
on peut s'arrêter là comme vérif
(tt le monde n'est pas débile
et on peut espérer le nom ailleurs qu'à la case téléphone)
sinon qques cas peuvent être semi-vérifiés en complément :
- il n'a que des lettres ?
- il n'a que des chiffres ? (c'est bien un nombre ?)
- le mail est bien de la forme ou ou
- la date de la forme xx/xx/xxxx ?
- le tél en 10 chiffres (avec ou sans '.' ou ' ') ?
- la checkbox indispensable cochée ?
- éventuellement le select a bougé ?
- les radios ... que peut-on contrôler ?
(en bon html, au moins l'une est déjà cochée par défaut)

Comment est ce que l'on peut associer les champs à un type défini.
(je crois que dans les lib js dont je parlais plus haut, ils utilisent des
classes)

Ben ils utilisent les class et je pense que c'est "mal"
pas joli, inélégant, toussa.
S'il faut glisser des class farfelues pour que l'imput sache à quoi s'en
tenir, on peut bien glisser des ids tt aussi farfelus (le blème avec les
ids est qu'ils doivent être uniques, ce qui n'est pas obligatoire pour
les classes)

Et puis, est-ce qu'on peut avoir un attribut 'rel' dans un input ?
Ha! non :-(
<http://www.w3.org/TR/html401/interact/forms.html#h-17.4>
plus :
<http://www.w3.org/TR/html401/sgml/dtd.html#coreattrs>

Mais peut-être qu'avec le 'alt' ?
(en annulant la bulle-info avec un title vide)

Dans le alt ce qui peut être pratique c'est qu'on peut y écrire
n'importe quoi comme un objet JS par exemple (enfin ... je suppose).

En tous cas mon html validator n'a pas gueulé pour le alt de l'input,
avec le code suivant :

<label>Un truc là genre nombre:
<input type="text" name="nombres[]" onchange="valid(this)"
alt="type:signed,max:100,min:50" title="nombre signé">
<span>Nombre positif ou négatif requis, compris entre 50 et 100</span>
<label>

(au passage: le label s'il contient l'élément n'a pas besoin de 'for')
(hop! alors l'élément n'a pas besoin d'id)
(autant d'économisé)

function valid(o) {
var requis, ok=true, v = o.value;
if(v == '') ok = false;
else {
if(o.alt && o.alt!='') requis = jsam(o.alt);
if(requis.type == 'signed' && !v.match(/^[+-]+/)) okúlse;
if(requis.max && requis.max < v) ok = false;
if(requis.min && requis.min > v) ok = false;
// à votre inspiration pour les autres if(blabla)
}
control(o, ok);
}

function jsam(o) {
var p, obj = {};
o = o.split(',');
for(var i=0; i<o.length; i++) {
p = o[i].split(':');
obj[p[0]] = p[1];
}
return obj;
}

function control(o, ok) {
o = o.parentNode;
while(o && o.tagName!='LABEL') o = o.parentNode;
o.className = ok? '' : 'alarm';
}

A partir de tables, il y a toujours un formulaire à faire , pou créer et
modifier les enregistrements, et je voulais
automatiser la création du code à partir de la description de la table.

Là ça me dépasse, je ne me souviens plus quels peuvent être les types
des champs d'une table (SQL ?).
... sauf l'ID incrémental, ce dont on n'a cure ici.

--
sm

Le 7/1/09 12:28 PM, J-F Portala a écrit :

Bonjour,
Je reviens un peu à la charge
concernant les validations:
J'en vois à 3 niveaux:
- en capturant l'evenement on keypress (au niveau touche)
- au niveau du type de champ (email - password - entier - entier signé
etc...comment les distinguer )
- au niveau du champ lui même (valeurs min max...)

La routine proposée par Stéphane est intéressante mais est spécifique
name=='email' ou 'pass1'

Ha! oui! comme précisé : "vérif *minimale*"
un peu élargie dans la démo sur cJoint

Sommes toutes avec un formulaire un peu standard il n'y a pas grd' chose
à vérifier
- le champ est rempli ?
on peut s'arrêter là comme vérif
(tt le monde n'est pas débile
et on peut espérer le nom ailleurs qu'à la case téléphone)
sinon qques cas peuvent être semi-vérifiés en complément :
- il n'a que des lettres ?
- il n'a que des chiffres ? (c'est bien un nombre ?)
- le mail est bien de la forme x@x.xx ou x@x.xxx ou x@x.xxxx
- la date de la forme xx/xx/xxxx ?
- le tél en 10 chiffres (avec ou sans '.' ou ' ') ?
- la checkbox indispensable cochée ?
- éventuellement le select a bougé ?
- les radios ... que peut-on contrôler ?
(en bon html, au moins l'une est déjà cochée par défaut)

Comment est ce que l'on peut associer les champs à un type défini.
(je crois que dans les lib js dont je parlais plus haut, ils utilisent des
classes)

Ben ils utilisent les class et je pense que c'est "mal"
pas joli, inélégant, toussa.
S'il faut glisser des class farfelues pour que l'imput sache à quoi s'en
tenir, on peut bien glisser des ids tt aussi farfelus (le blème avec les
ids est qu'ils doivent être uniques, ce qui n'est pas obligatoire pour
les classes)

Et puis, est-ce qu'on peut avoir un attribut 'rel' dans un input ?
Ha! non :-(
<http://www.w3.org/TR/html401/interact/forms.html#h-17.4>
plus :
<http://www.w3.org/TR/html401/sgml/dtd.html#coreattrs>

Mais peut-être qu'avec le 'alt' ?
(en annulant la bulle-info avec un title vide)

Dans le alt ce qui peut être pratique c'est qu'on peut y écrire
n'importe quoi comme un objet JS par exemple (enfin ... je suppose).

En tous cas mon html validator n'a pas gueulé pour le alt de l'input,
avec le code suivant :

<label>Un truc là genre nombre:
<input type="text" name="nombres[]" onchange="valid(this)"
alt="type:signed,max:100,min:50" title="nombre signé">
<span>Nombre positif ou négatif requis, compris entre 50 et 100</span>
<label>

(au passage: le label s'il contient l'élément n'a pas besoin de 'for')
(hop! alors l'élément n'a pas besoin d'id)
(autant d'économisé)

function valid(o) {
var requis, ok=true, v = o.value;
if(v == '') ok = false;
else {
if(o.alt && o.alt!='') requis = jsam(o.alt);
if(requis.type == 'signed' && !v.match(/^[+-]+/)) okúlse;
if(requis.max && requis.max < v) ok = false;
if(requis.min && requis.min > v) ok = false;
// à votre inspiration pour les autres if(blabla)
}
control(o, ok);
}

function jsam(o) {
var p, obj = {};
o = o.split(',');
for(var i=0; i<o.length; i++) {
p = o[i].split(':');
obj[p[0]] = p[1];
}
return obj;
}

function control(o, ok) {
o = o.parentNode;
while(o && o.tagName!='LABEL') o = o.parentNode;
o.className = ok? '' : 'alarm';
}

A partir de tables, il y a toujours un formulaire à faire , pou créer et
modifier les enregistrements, et je voulais
automatiser la création du code à partir de la description de la table.

Là ça me dépasse, je ne me souviens plus quels peuvent être les types
des champs d'une table (SQL ?).
... sauf l'ID incrémental, ce dont on n'a cure ici.

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Le 7/1/09 12:28 PM, J-F Portala a écrit :

Bonjour,
Je reviens un peu à la charge
concernant les validations:
J'en vois à 3 niveaux:
- en capturant l'evenement on keypress (au niveau touche)
- au niveau du type de champ (email - password - entier - entier signé
etc...comment les distinguer )
- au niveau du champ lui même (valeurs min max...)

La routine proposée par Stéphane est intéressante mais est spécifique
name=='email' ou 'pass1'

Ha! oui! comme précisé : "vérif *minimale*"
un peu élargie dans la démo sur cJoint

Sommes toutes avec un formulaire un peu standard il n'y a pas grd' chose
à vérifier
- le champ est rempli ?
on peut s'arrêter là comme vérif
(tt le monde n'est pas débile
et on peut espérer le nom ailleurs qu'à la case téléphone)
sinon qques cas peuvent être semi-vérifiés en complément :
- il n'a que des lettres ?
- il n'a que des chiffres ? (c'est bien un nombre ?)
- le mail est bien de la forme ou ou
- la date de la forme xx/xx/xxxx ?
- le tél en 10 chiffres (avec ou sans '.' ou ' ') ?
- la checkbox indispensable cochée ?
- éventuellement le select a bougé ?
- les radios ... que peut-on contrôler ?
(en bon html, au moins l'une est déjà cochée par défaut)

Comment est ce que l'on peut associer les champs à un type défini.
(je crois que dans les lib js dont je parlais plus haut, ils utilisent des
classes)

Ben ils utilisent les class et je pense que c'est "mal"
pas joli, inélégant, toussa.
S'il faut glisser des class farfelues pour que l'imput sache à quoi s'en
tenir, on peut bien glisser des ids tt aussi farfelus (le blème avec les
ids est qu'ils doivent être uniques, ce qui n'est pas obligatoire pour
les classes)

Et puis, est-ce qu'on peut avoir un attribut 'rel' dans un input ?
Ha! non :-(
<http://www.w3.org/TR/html401/interact/forms.html#h-17.4>
plus :
<http://www.w3.org/TR/html401/sgml/dtd.html#coreattrs>

Mais peut-être qu'avec le 'alt' ?
(en annulant la bulle-info avec un title vide)

Dans le alt ce qui peut être pratique c'est qu'on peut y écrire
n'importe quoi comme un objet JS par exemple (enfin ... je suppose).

En tous cas mon html validator n'a pas gueulé pour le alt de l'input,
avec le code suivant :

<label>Un truc là genre nombre:
<input type="text" name="nombres[]" onchange="valid(this)"
alt="type:signed,max:100,min:50" title="nombre signé">
<span>Nombre positif ou négatif requis, compris entre 50 et 100</span>
<label>

(au passage: le label s'il contient l'élément n'a pas besoin de 'for')
(hop! alors l'élément n'a pas besoin d'id)
(autant d'économisé)

function valid(o) {
var requis, ok=true, v = o.value;
if(v == '') ok = false;
else {
if(o.alt && o.alt!='') requis = jsam(o.alt);
if(requis.type == 'signed' && !v.match(/^[+-]+/)) okúlse;
if(requis.max && requis.max < v) ok = false;
if(requis.min && requis.min > v) ok = false;
// à votre inspiration pour les autres if(blabla)
}
control(o, ok);
}

function jsam(o) {
var p, obj = {};
o = o.split(',');
for(var i=0; i<o.length; i++) {
p = o[i].split(':');
obj[p[0]] = p[1];
}
return obj;
}

function control(o, ok) {
o = o.parentNode;
while(o && o.tagName!='LABEL') o = o.parentNode;
o.className = ok? '' : 'alarm';
}

A partir de tables, il y a toujours un formulaire à faire , pou créer et
modifier les enregistrements, et je voulais
automatiser la création du code à partir de la description de la table.

Là ça me dépasse, je ne me souviens plus quels peuvent être les types
des champs d'une table (SQL ?).
... sauf l'ID incrémental, ce dont on n'a cure ici.

--
sm

SAM

03/07/2009 à 00:12

Le 7/1/09 4:01 AM, Mickaël Wolff a écrit :

SAM a écrit :

J'utilises instanceof car ce devrait être plus rapide que de
comparer tagName à une chaîne

Vraiment ?

Vérifier que deux entiers (les références de chaque objets) sont égaux
est plus rapide que de comparer 2 × tagName.length octets.

Comme tu y vas, ne faut-il pas d'abord trouver les objets (ce qui me
semble le + lourd travail),
le gain HTMLType / tagName.string
ne doit pas représenter grd chose dans l'ensemble du processus.

(en fait, instanceof va comparer la référence au prototype de l'objet
de gauche à la référence à l'objet function de droite).

J'a rhen compris à ton instanceof

Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof vérifie que l'objet à sa gauche est prototypé à partir de
l'objet à droite de instanceof.

Oui, oui, et en images ça donne quoi ?

Et là : window.HTMLLabelElement
quels sont les autres HTMLElements de window ?
(HTMLCheckboxElement, HTMLRadioElement ?)

Dans ce document imbitable :
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

Gros effort ... vaguement survolé ...
c'est un peu comme si on redéfinissait le HTML.4
(en plus hermétique ! merci!)
et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Breffle c'est bêtement : HTML+Balise(HTML.4.01)+Element
avec les exceptions className et htmlFor
(pourquoi(*) ceux là et pas htmlAlt ou htmlTitle ?)
et qques complications comme HTMLOListElement
Mais pas de HTMLRadioElement
pourtant ils savent nous sortir un HTMLOptionElement
et même un HTMLTableColElement !

(*) oui, bon, ils disent pourquoi, mékanmême !

En fait, je parlais de do while car il évite parfois de se répéter.

Ha! OK! vu.
En effet je n'en avais pas saisi l'avantage.

Le seul pb que j'ai avec ma méthode est qu'au cas où il n'y a pas de
label conteneur, le while va remonter jusqu'à window avant de s'avouer
vaincu.

Est-ce que cet instanceof éviterait celà ?

Non. Je pense qu'il faudrait écrire quelque chose d'un peu plus
sophistiqué. D'ailleurs je viens d'écrire un petit objet qui fait ce
taf, et qui devrait gérer tout les cas. Si tu veux je te l'envoie.

Oui! Oui!
ça me permettra de venir te questionner pour chacune de ses lignes

Ceci étant : pourquoi qu'à moi ?

--
sm

Le 7/1/09 4:01 AM, Mickaël Wolff a écrit :

SAM a écrit :

J'utilises instanceof car ce devrait être plus rapide que de
comparer tagName à une chaîne

Vraiment ?

Vérifier que deux entiers (les références de chaque objets) sont égaux
est plus rapide que de comparer 2 × tagName.length octets.

Comme tu y vas, ne faut-il pas d'abord trouver les objets (ce qui me
semble le + lourd travail),
le gain HTMLType / tagName.string
ne doit pas représenter grd chose dans l'ensemble du processus.

(en fait, instanceof va comparer la référence au prototype de l'objet
de gauche à la référence à l'objet function de droite).

J'a rhen compris à ton instanceof

Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof vérifie que l'objet à sa gauche est prototypé à partir de
l'objet à droite de instanceof.

Oui, oui, et en images ça donne quoi ?

Et là : window.HTMLLabelElement
quels sont les autres HTMLElements de window ?
(HTMLCheckboxElement, HTMLRadioElement ?)

Dans ce document imbitable :
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

Gros effort ... vaguement survolé ...
c'est un peu comme si on redéfinissait le HTML.4
(en plus hermétique ! merci!)
et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Breffle c'est bêtement : HTML+Balise(HTML.4.01)+Element
avec les exceptions className et htmlFor
(pourquoi(*) ceux là et pas htmlAlt ou htmlTitle ?)
et qques complications comme HTMLOListElement
Mais pas de HTMLRadioElement
pourtant ils savent nous sortir un HTMLOptionElement
et même un HTMLTableColElement !

(*) oui, bon, ils disent pourquoi, mékanmême !

En fait, je parlais de do while car il évite parfois de se répéter.

Ha! OK! vu.
En effet je n'en avais pas saisi l'avantage.

Le seul pb que j'ai avec ma méthode est qu'au cas où il n'y a pas de
label conteneur, le while va remonter jusqu'à window avant de s'avouer
vaincu.

Est-ce que cet instanceof éviterait celà ?

Non. Je pense qu'il faudrait écrire quelque chose d'un peu plus
sophistiqué. D'ailleurs je viens d'écrire un petit objet qui fait ce
taf, et qui devrait gérer tout les cas. Si tu veux je te l'envoie.

Oui! Oui!
ça me permettra de venir te questionner pour chacune de ses lignes

Ceci étant : pourquoi qu'à moi ?

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Le 7/1/09 4:01 AM, Mickaël Wolff a écrit :

SAM a écrit :

J'utilises instanceof car ce devrait être plus rapide que de
comparer tagName à une chaîne

Vraiment ?

Vérifier que deux entiers (les références de chaque objets) sont égaux
est plus rapide que de comparer 2 × tagName.length octets.

Comme tu y vas, ne faut-il pas d'abord trouver les objets (ce qui me
semble le + lourd travail),
le gain HTMLType / tagName.string
ne doit pas représenter grd chose dans l'ensemble du processus.

(en fait, instanceof va comparer la référence au prototype de l'objet
de gauche à la référence à l'objet function de droite).

J'a rhen compris à ton instanceof

Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof vérifie que l'objet à sa gauche est prototypé à partir de
l'objet à droite de instanceof.

Oui, oui, et en images ça donne quoi ?

Et là : window.HTMLLabelElement
quels sont les autres HTMLElements de window ?
(HTMLCheckboxElement, HTMLRadioElement ?)

Dans ce document imbitable :
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

Gros effort ... vaguement survolé ...
c'est un peu comme si on redéfinissait le HTML.4
(en plus hermétique ! merci!)
et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Breffle c'est bêtement : HTML+Balise(HTML.4.01)+Element
avec les exceptions className et htmlFor
(pourquoi(*) ceux là et pas htmlAlt ou htmlTitle ?)
et qques complications comme HTMLOListElement
Mais pas de HTMLRadioElement
pourtant ils savent nous sortir un HTMLOptionElement
et même un HTMLTableColElement !

(*) oui, bon, ils disent pourquoi, mékanmême !

En fait, je parlais de do while car il évite parfois de se répéter.

Ha! OK! vu.
En effet je n'en avais pas saisi l'avantage.

Le seul pb que j'ai avec ma méthode est qu'au cas où il n'y a pas de
label conteneur, le while va remonter jusqu'à window avant de s'avouer
vaincu.

Est-ce que cet instanceof éviterait celà ?

Non. Je pense qu'il faudrait écrire quelque chose d'un peu plus
sophistiqué. D'ailleurs je viens d'écrire un petit objet qui fait ce
taf, et qui devrait gérer tout les cas. Si tu veux je te l'envoie.

Oui! Oui!
ça me permettra de venir te questionner pour chacune de ses lignes

Ceci étant : pourquoi qu'à moi ?

--
sm

Olivier Miakinen

03/07/2009 à 01:29

Le 03/07/2009 00:12, SAM a écrit :

Dans ce document imbitable :
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

C'est pas moi, m'sieur, je l'jure !

Et pourtant j'aime bien les docs de référence en général (ECMAScript,
HTML 4.01, CSS 2.1, ...) mais alors là je n'y ai effectivement rien
compris du tout. À côté de ce machin, les assertions négatives en
arrière dans les regexp Perl c'est vraiment de la gnognote.

--
Olivier Miakinen

Mickaël Wolff

04/07/2009 à 03:26

Pascal PONCET a écrit :

Bonjour Mickaël,

Je vais peut-être faire hurler,

J'ai dû me cacher après avoir lu ton courriel. Les voisins ont appelé
des professionnel de santé ;)

Par exemple, en conservant une sémantique correcte, un attribut
"subtype" pourrait faire l'affaire.
Exemple :
<input type="text" subtype="date_jjmmaaaa" name="birthdate">

Le problème de cette méthode c'est que tu te prive des validateurs de
code, et que tu casses l'interopérabilité. Si le laxisme des navigateurs
Web est nécessaire pour être tolérant à la faillibilité des différents
intervenant, exploiter de manière consciente ce laxisme ne me parait pas
être une bonne idée.

Attention, seul IE reconnaîtra la propriété "formElement.subtype", donc
il faudra plutôt utiliser "formElement.getAttribute('subtype')" pour
récupérer la valeur.

En plus :D

Evidemment, le nec plus ultra serait de générer un document XHTML, avec
un espace de nommage spécifique et un attribut préfixé (cf XForms).

Utiliser XForms serait une manière plus élégante en effet, mais il
faudra alors prévoir un fonctionnement de secours pour ceux qui ne
comprennent pas XForms (à moins que tu ne les ignores).

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position <http://lupusmic.org/pro/>

Mickaël Wolff

04/07/2009 à 06:59

SAM a écrit :

Comme tu y vas, ne faut-il pas d'abord trouver les objets (ce qui me
semble le + lourd travail),

Trouver les objets me semble être une opération bien moins lourde que
la comparaison de deux chaînes. D'autant plus que pour comparer la
chaîne au nom du Tag, il faut déjà avoir cherché l'objet correspondant
au nœud.

le gain HTMLType / tagName.string
ne doit pas représenter grd chose dans l'ensemble du processus.

Je suis d'accord, j'avais hésité à utiliser cet argument, car sur une
machine moderne le gain est ridicule.

Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof est un opérateur qui attends deux opérandes.
op1 instanceof op2
instanceof vérifie que l'objet op2 est présent dans la liste des
prototypes qui ont permis la fabrication de op1.

Oui, oui, et en images ça donne quoi ?

Ben...
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>
chapitre 4.2.1.

<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

Je persiste :D

Gros effort ... vaguement survolé ...
c'est un peu comme si on redéfinissait le HTML.4

Pas vraiment, c'est plutôt complémentaire. le DOM HTML défini une
interface de programmation pour manipuler les morceaux d'un document HTML.

(en plus hermétique ! merci!)

Pourquoi hermétique ?

et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Ce n'est pas DOM 2003, c'est DOM HTML 2. Il faut noter que, comme tu
dois le savoir, la période 1995 - 2005 fut quelque peu chaotique. Les
normes sont souvent venues après l'apparition de la technologie, qu'ils
tentent de formaliser, dans les navigateurs en pleine compétition.

Breffle c'est bêtement : HTML+Balise(HTML.4.01)+Element
avec les exceptions className et htmlFor
(pourquoi(*) ceux là et pas htmlAlt ou htmlTitle ?)

Parce que for et class sont souvent des noms réservés dans les
langages de programmation.

et qques complications comme HTMLOListElement

Pourquoi complication ?

Mais pas de HTMLRadioElement

Normal, ça n'existe pas (ce sont des HTMLInputElement).

pourtant ils savent nous sortir un HTMLOptionElement
et même un HTMLTableColElement !

Ben les éléments correspondant existent. Le DOM HTML se borne à cela.

(*) oui, bon, ils disent pourquoi, mékanmême !

:D

Ha! OK! vu.
En effet je n'en avais pas saisi l'avantage.

Mea culpa, je m'étais mal exprimé.

Oui! Oui!
ça me permettra de venir te questionner pour chacune de ses lignes

Mais pas trop hein ;)

Ceci étant : pourquoi qu'à moi ?

Parce que je n'en suis pas totalement satisfait. 'fin, c'est en ligne
<http://lupusmic.org/label.tar.bz>

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position <http://lupusmic.org/pro/>

SAM a écrit :

Comme tu y vas, ne faut-il pas d'abord trouver les objets (ce qui me
semble le + lourd travail),

Trouver les objets me semble être une opération bien moins lourde que
la comparaison de deux chaînes. D'autant plus que pour comparer la
chaîne au nom du Tag, il faut déjà avoir cherché l'objet correspondant
au nœud.

le gain HTMLType / tagName.string
ne doit pas représenter grd chose dans l'ensemble du processus.

Je suis d'accord, j'avais hésité à utiliser cet argument, car sur une
machine moderne le gain est ridicule.

Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof est un opérateur qui attends deux opérandes.
op1 instanceof op2
instanceof vérifie que l'objet op2 est présent dans la liste des
prototypes qui ont permis la fabrication de op1.

Oui, oui, et en images ça donne quoi ?

Ben...
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>
chapitre 4.2.1.

<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

Je persiste :D

Gros effort ... vaguement survolé ...
c'est un peu comme si on redéfinissait le HTML.4

Pas vraiment, c'est plutôt complémentaire. le DOM HTML défini une
interface de programmation pour manipuler les morceaux d'un document HTML.

(en plus hermétique ! merci!)

Pourquoi hermétique ?

et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Ce n'est pas DOM 2003, c'est DOM HTML 2. Il faut noter que, comme tu
dois le savoir, la période 1995 - 2005 fut quelque peu chaotique. Les
normes sont souvent venues après l'apparition de la technologie, qu'ils
tentent de formaliser, dans les navigateurs en pleine compétition.

Breffle c'est bêtement : HTML+Balise(HTML.4.01)+Element
avec les exceptions className et htmlFor
(pourquoi(*) ceux là et pas htmlAlt ou htmlTitle ?)

Parce que for et class sont souvent des noms réservés dans les
langages de programmation.

et qques complications comme HTMLOListElement

Pourquoi complication ?

Mais pas de HTMLRadioElement

Normal, ça n'existe pas (ce sont des HTMLInputElement).

pourtant ils savent nous sortir un HTMLOptionElement
et même un HTMLTableColElement !

Ben les éléments correspondant existent. Le DOM HTML se borne à cela.

(*) oui, bon, ils disent pourquoi, mékanmême !

:D

Ha! OK! vu.
En effet je n'en avais pas saisi l'avantage.

Mea culpa, je m'étais mal exprimé.

Oui! Oui!
ça me permettra de venir te questionner pour chacune de ses lignes

Mais pas trop hein ;)

Ceci étant : pourquoi qu'à moi ?

Parce que je n'en suis pas totalement satisfait. 'fin, c'est en ligne
<http://lupusmic.org/label.tar.bz>

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position <http://lupusmic.org/pro/>

Vous avez filtré cet utilisateur ! Consultez son message

SAM a écrit :

Comme tu y vas, ne faut-il pas d'abord trouver les objets (ce qui me
semble le + lourd travail),

Trouver les objets me semble être une opération bien moins lourde que
la comparaison de deux chaînes. D'autant plus que pour comparer la
chaîne au nom du Tag, il faut déjà avoir cherché l'objet correspondant
au nœud.

le gain HTMLType / tagName.string
ne doit pas représenter grd chose dans l'ensemble du processus.

Je suis d'accord, j'avais hésité à utiliser cet argument, car sur une
machine moderne le gain est ridicule.

Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof est un opérateur qui attends deux opérandes.
op1 instanceof op2
instanceof vérifie que l'objet op2 est présent dans la liste des
prototypes qui ont permis la fabrication de op1.

Oui, oui, et en images ça donne quoi ?

Ben...
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>
chapitre 4.2.1.

<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

Je me demande si on n'a pas déjà essayé de me mettre ça sous les yeux ?
Je m'demande ?

Je persiste :D

Gros effort ... vaguement survolé ...
c'est un peu comme si on redéfinissait le HTML.4

Pas vraiment, c'est plutôt complémentaire. le DOM HTML défini une
interface de programmation pour manipuler les morceaux d'un document HTML.

(en plus hermétique ! merci!)

Pourquoi hermétique ?

et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Ce n'est pas DOM 2003, c'est DOM HTML 2. Il faut noter que, comme tu
dois le savoir, la période 1995 - 2005 fut quelque peu chaotique. Les
normes sont souvent venues après l'apparition de la technologie, qu'ils
tentent de formaliser, dans les navigateurs en pleine compétition.

Breffle c'est bêtement : HTML+Balise(HTML.4.01)+Element
avec les exceptions className et htmlFor
(pourquoi(*) ceux là et pas htmlAlt ou htmlTitle ?)

Parce que for et class sont souvent des noms réservés dans les
langages de programmation.

et qques complications comme HTMLOListElement

Pourquoi complication ?

Mais pas de HTMLRadioElement

Normal, ça n'existe pas (ce sont des HTMLInputElement).

pourtant ils savent nous sortir un HTMLOptionElement
et même un HTMLTableColElement !

Ben les éléments correspondant existent. Le DOM HTML se borne à cela.

(*) oui, bon, ils disent pourquoi, mékanmême !

:D

Ha! OK! vu.
En effet je n'en avais pas saisi l'avantage.

Mea culpa, je m'étais mal exprimé.

Oui! Oui!
ça me permettra de venir te questionner pour chacune de ses lignes

Mais pas trop hein ;)

Ceci étant : pourquoi qu'à moi ?

Parce que je n'en suis pas totalement satisfait. 'fin, c'est en ligne
<http://lupusmic.org/label.tar.bz>

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position <http://lupusmic.org/pro/>

SAM

05/07/2009 à 03:55

Le 7/4/09 6:59 AM, Mickaël Wolff a écrit :

SAM a écrit :
Enfin ... on peut un peu comprendre (instance de)
Mais la gauche de la droite du prototype-truc ...
(faut déjà aimer jongler avec c't'affaire bien mystérieuse)

instanceof est un opérateur qui attends deux opérandes.
op1 instanceof op2

je parle de "prototype" ;-)

instanceof vérifie que l'objet op2 est présent dans la liste des
prototypes qui ont permis la fabrication de op1.

<http://fr.wikibooks.org/wiki/Programmation_JavaScript/Op%C3%A9rateurs#Type_d.27objet_.28instanceof.29>

Oui, oui, et en images ça donne quoi ?

Ben...
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>
chapitre 4.2.1.

Mais il a réponse à tout !

<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html> :D

(en plus hermétique ! merci!)

Pourquoi hermétique ?

Heu ... non? C'est vraiment limpide ?

et en pire puisque s'intéresse à des deprecated comme 'DIR'
Le DOM de 2003 a donc un métro de retard sur l'HTML de 1999 ?

Ce n'est pas DOM 2003, c'est DOM HTML 2.

Ha! moi je vois des dates en haut des documents.

et qques complications comme HTMLOListElement

Pourquoi complication ?

dans la mesure où ils tentent de s'approcher du nom de la balise HTML
pourquoi pas n'avoir fait : HTMLOLElement
?

Mais pas de HTMLRadioElement

Normal, ça n'existe pas (ce sont des HTMLInputElement).

Néanmoins, ça aurait facilité.

Ceci étant : pourquoi qu'à moi ?

Parce que je n'en suis pas totalement satisfait. 'fin, c'est en ligne
<http://lupusmic.org/label.tar.bz>

Téléchargé.

--
sm

Mickaël Wolff

06/07/2009 à 10:14

SAM a écrit :

je parle de "prototype" ;-)

Tu veux dire que tu ne comprends pas ce qu'est le prototype ?

<http://fr.wikibooks.org/wiki/Programmation_JavaScript/Op%C3%A9rateurs#Type_d.27objet_.28instanceof.29>

Je trouve que l'expression « type d'objet » est maladroite, car les
objets ne sont pas typés en Javascript. À la rigueur on pourrait parler
de « prototype d'objet ».

Mais il a réponse à tout !

Non, heureusement ;)

Heu ... non? C'est vraiment limpide ?

Peut-être dans ma tête. Mais à exprimer ce n'est pas forcément évident.

Ha! moi je vois des dates en haut des documents.

Oui mais non. La date n'est pas la version :p

dans la mesure où ils tentent de s'approcher du nom de la balise HTML
pourquoi pas n'avoir fait : HTMLOLElement
?

À oui, c'est stupide, si on regarde comme ça. Alors HTMLAnchorElement
est aussi une exception. Mais bon, ce genres de choses sont souvent
issues de discutions interminables, et je te propose de ne pas y
contribuer !

Néanmoins, ça aurait facilité.

Tout à fait. Mais ce qui aurait été encore plus simple, s'eût été de
ne pas avoir cet attribut HTML type à la con.

Téléchargé.

J'attends tes commentaires (et de ceux qui furent intéressés), ce
n'était qu'un jet rapide.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position <http://lupusmic.org/pro/>

validation de formulaire

9 réponses

Veuillez sélectionner un problème