bonjour à tou
j'ai crée un formulaire ou j'aimerai y intégrer un code rendant obligatoire la saisie de certain champ texte, meme problème pour un bouton radio qui doit etre coché obligatoirement, en clair qu'il y ai un controle du formulaire avant que l'action mailto fonctionne
merci pour votre aid
<form action="mailto:****@yahoo.fr" method="post" enctype="text/plain" name="demande de devis
onSubmit="return validation();"
au fait, avec action="mailto:blabla" le serveur peut contrôler çà et renvoyer le form à compléter ? en php par exemple ?
Euh, je suis pas sûr de bien comprendre, mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit, ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées et éventuellement les corrige,
Sur le client ?
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
O.L. wrote:
au fait, avec
action="mailto:blabla"
le serveur peut contrôler çà et renvoyer le form à compléter ?
en php par exemple ?
Euh, je suis pas sûr de bien comprendre, mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit,
ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées
et éventuellement les corrige,
Sur le client ?
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
au fait, avec action="mailto:blabla" le serveur peut contrôler çà et renvoyer le form à compléter ? en php par exemple ?
Euh, je suis pas sûr de bien comprendre, mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit, ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées et éventuellement les corrige,
Sur le client ?
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
bruno at modulix
ASM wrote:
au fait, avec action="mailto:blabla" le serveur peut contrôler çà et renvoyer le form à compléter ? en php par exemple ?
Euh, je suis pas sûr de bien comprendre,
je voulais juste faire remarquer que l'action passe par une gestion directe par le navigateur (et ou son mailleur associé) et que donc, à priori, il n'est pas prévu de contôle via serveur du contenu du form
Effectivement.
En conséquence la petite béquille JS, même si elle n'est pas parfaite, apporte néanmoins un plus.
Elle apporte un plus de toutes façons, mais si elle est seule, autant considérer qu'il n'y a pas eu de validation du tout.
et mon interrogation complémentaire : avec un action="mailto:blabla" peut-on cour-circuiter l'envoi du mail et ouvrir un *.php à la place?
PAQJS, non, il faut que l'action renvoie les données au serveur pour ça.
mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit, ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées et éventuellement les corrige, puis il "affiche" un formulaire invisible (display:none) ayant comme attribut action le fameux mailto:, et il met aussi un petit JavaScript qui va submitter automatiquement le formulaire. Pour l'utilisateur, bah il remplit son truc, il clique, et il re-clique dans la fenêtre de confirmation. Bref, pour lui ça change rien, mais pourtant les entrées ont été contrôlées ...
Là, bien que je capte l'idée d'un truc détourné (utilisant tt de même du JS), je dois avouer je n'ai pas bien saisi les méandres du bazar :-)
Soit OL a oublié quelque chose en route, soit je deviens sénile, soit ça ne tient pas debout.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
ASM wrote:
au fait, avec
action="mailto:blabla"
le serveur peut contrôler çà et renvoyer le form à compléter ?
en php par exemple ?
Euh, je suis pas sûr de bien comprendre,
je voulais juste faire remarquer que l'action
passe par une gestion directe par le navigateur (et ou son mailleur
associé)
et que donc, à priori, il n'est pas prévu de contôle via serveur
du contenu du form
Effectivement.
En conséquence la petite béquille JS, même si elle n'est pas parfaite,
apporte néanmoins un plus.
Elle apporte un plus de toutes façons, mais si elle est seule, autant
considérer qu'il n'y a pas eu de validation du tout.
et mon interrogation complémentaire :
avec un action="mailto:blabla"
peut-on cour-circuiter l'envoi du mail et ouvrir un *.php à la place?
PAQJS, non, il faut que l'action renvoie les données au serveur pour ça.
mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit,
ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées
et éventuellement les corrige, puis il "affiche" un formulaire
invisible (display:none) ayant comme attribut action le fameux
mailto:, et il met aussi un petit JavaScript qui va submitter
automatiquement le formulaire.
Pour l'utilisateur, bah il remplit son truc, il clique, et il
re-clique dans la fenêtre de confirmation. Bref, pour lui ça change
rien, mais pourtant les entrées ont été contrôlées ...
Là, bien que je capte l'idée d'un truc détourné (utilisant tt de même du
JS),
je dois avouer je n'ai pas bien saisi les méandres du bazar :-)
Soit OL a oublié quelque chose en route, soit je deviens sénile, soit ça
ne tient pas debout.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
au fait, avec action="mailto:blabla" le serveur peut contrôler çà et renvoyer le form à compléter ? en php par exemple ?
Euh, je suis pas sûr de bien comprendre,
je voulais juste faire remarquer que l'action passe par une gestion directe par le navigateur (et ou son mailleur associé) et que donc, à priori, il n'est pas prévu de contôle via serveur du contenu du form
Effectivement.
En conséquence la petite béquille JS, même si elle n'est pas parfaite, apporte néanmoins un plus.
Elle apporte un plus de toutes façons, mais si elle est seule, autant considérer qu'il n'y a pas eu de validation du tout.
et mon interrogation complémentaire : avec un action="mailto:blabla" peut-on cour-circuiter l'envoi du mail et ouvrir un *.php à la place?
PAQJS, non, il faut que l'action renvoie les données au serveur pour ça.
mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit, ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées et éventuellement les corrige, puis il "affiche" un formulaire invisible (display:none) ayant comme attribut action le fameux mailto:, et il met aussi un petit JavaScript qui va submitter automatiquement le formulaire. Pour l'utilisateur, bah il remplit son truc, il clique, et il re-clique dans la fenêtre de confirmation. Bref, pour lui ça change rien, mais pourtant les entrées ont été contrôlées ...
Là, bien que je capte l'idée d'un truc détourné (utilisant tt de même du JS), je dois avouer je n'ai pas bien saisi les méandres du bazar :-)
Soit OL a oublié quelque chose en route, soit je deviens sénile, soit ça ne tient pas debout.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
ASM
J'ai comme l'impression qu'on a pas le même truc en tête tout les 2 ;-)
D'une manière ou d'une autre (mailto direct ou par ton zig-zag) on a, au final, un action = "mailto: ..."
donc çà maile via le navigateur (ou son courrieleur associé)
Lors d'un envoi par mail, on n'a pas de confirmation que c'est bien parti, surtout avec un formulaire (exepté le truc d'avertissement qu'on ferme rageusement sans le lire).
Usuellement, le formulaire part enfin ... il appelle une page en lui refilant les données du formulaire la page appelée est, usuellement toujours, 'intelligente' (php, cgi, asp) et engrange les données envoyées, et, surtout, averti que le formulaire a bien été digéré en renvoyant la page adhoc (te proposant de revenir au site ou à son menu)
Avec un mailto tu n'as pas de retour. Tu restes bête devant ta page remplie qui reste là à te regarder bêtement elle aussi.
Voilà donc ce que j'avais en tête.
Ouf ! çà fait du bien d'en être débarrassé.
-- Stephane Moriaux et son [moins] vieux Mac
J'ai comme l'impression qu'on a pas le même truc en tête tout les 2 ;-)
D'une manière ou d'une autre (mailto direct ou par ton zig-zag)
on a, au final, un action = "mailto: ..."
donc çà maile via le navigateur (ou son courrieleur associé)
Lors d'un envoi par mail, on n'a pas de confirmation
que c'est bien parti, surtout avec un formulaire
(exepté le truc d'avertissement qu'on ferme rageusement sans le lire).
Usuellement, le formulaire part
enfin ... il appelle une page en lui refilant les données du formulaire
la page appelée est, usuellement toujours, 'intelligente' (php, cgi, asp)
et engrange les données envoyées,
et, surtout, averti que le formulaire a bien été digéré en renvoyant
la page adhoc (te proposant de revenir au site ou à son menu)
Avec un mailto tu n'as pas de retour.
Tu restes bête devant ta page remplie
qui reste là à te regarder bêtement elle aussi.
J'ai comme l'impression qu'on a pas le même truc en tête tout les 2 ;-)
D'une manière ou d'une autre (mailto direct ou par ton zig-zag) on a, au final, un action = "mailto: ..."
donc çà maile via le navigateur (ou son courrieleur associé)
Lors d'un envoi par mail, on n'a pas de confirmation que c'est bien parti, surtout avec un formulaire (exepté le truc d'avertissement qu'on ferme rageusement sans le lire).
Usuellement, le formulaire part enfin ... il appelle une page en lui refilant les données du formulaire la page appelée est, usuellement toujours, 'intelligente' (php, cgi, asp) et engrange les données envoyées, et, surtout, averti que le formulaire a bien été digéré en renvoyant la page adhoc (te proposant de revenir au site ou à son menu)
Avec un mailto tu n'as pas de retour. Tu restes bête devant ta page remplie qui reste là à te regarder bêtement elle aussi.
Voilà donc ce que j'avais en tête.
Ouf ! çà fait du bien d'en être débarrassé.
-- Stephane Moriaux et son [moins] vieux Mac
O.L.
J'ai comme l'impression qu'on a pas le même truc en tête tout les 2 ;-)
D'une manière ou d'une autre (mailto direct ou par ton zig-zag) on a, au final, un action = "mailto: ..."
donc çà maile via le navigateur (ou son courrieleur associé)
Lors d'un envoi par mail, on n'a pas de confirmation que c'est bien parti, surtout avec un formulaire (exepté le truc d'avertissement qu'on ferme rageusement sans le lire).
Usuellement, le formulaire part enfin ... il appelle une page en lui refilant les données du formulaire la page appelée est, usuellement toujours, 'intelligente' (php, cgi, asp) et engrange les données envoyées, et, surtout, averti que le formulaire a bien été digéré en renvoyant la page adhoc (te proposant de revenir au site ou à son menu)
Avec un mailto tu n'as pas de retour. Tu restes bête devant ta page remplie qui reste là à te regarder bêtement elle aussi.
Oui. Comme une fois que le submit s'est fait JS n'a plus accès à rien et reste dans l'ignorance la plus totale de ce qui se passe, on peut partir du principe que le form est parti, et afficher un petit message : "il y a 99% de chances que le formulaire aie été correctement envoyé" ... ;-)
Voilà donc ce que j'avais en tête.
Ouf ! çà fait du bien d'en être débarrassé.
Wép, ça fait de la place :)
-- Olivier Ligny Créateur web free-lance / www.cyber-tamtam.net
J'ai comme l'impression qu'on a pas le même truc en tête tout les 2 ;-)
D'une manière ou d'une autre (mailto direct ou par ton zig-zag)
on a, au final, un action = "mailto: ..."
donc çà maile via le navigateur (ou son courrieleur associé)
Lors d'un envoi par mail, on n'a pas de confirmation
que c'est bien parti, surtout avec un formulaire
(exepté le truc d'avertissement qu'on ferme rageusement sans le lire).
Usuellement, le formulaire part
enfin ... il appelle une page en lui refilant les données du formulaire
la page appelée est, usuellement toujours, 'intelligente' (php, cgi, asp)
et engrange les données envoyées,
et, surtout, averti que le formulaire a bien été digéré en renvoyant
la page adhoc (te proposant de revenir au site ou à son menu)
Avec un mailto tu n'as pas de retour.
Tu restes bête devant ta page remplie
qui reste là à te regarder bêtement elle aussi.
Oui. Comme une fois que le submit s'est fait JS n'a plus accès à rien
et reste dans l'ignorance la plus totale de ce qui se passe, on peut
partir du principe que le form est parti, et afficher un petit message :
"il y a 99% de chances que le formulaire aie été correctement envoyé"
... ;-)
Voilà donc ce que j'avais en tête.
Ouf ! çà fait du bien d'en être débarrassé.
Wép, ça fait de la place :)
--
Olivier Ligny
Créateur web free-lance / www.cyber-tamtam.net
J'ai comme l'impression qu'on a pas le même truc en tête tout les 2 ;-)
D'une manière ou d'une autre (mailto direct ou par ton zig-zag) on a, au final, un action = "mailto: ..."
donc çà maile via le navigateur (ou son courrieleur associé)
Lors d'un envoi par mail, on n'a pas de confirmation que c'est bien parti, surtout avec un formulaire (exepté le truc d'avertissement qu'on ferme rageusement sans le lire).
Usuellement, le formulaire part enfin ... il appelle une page en lui refilant les données du formulaire la page appelée est, usuellement toujours, 'intelligente' (php, cgi, asp) et engrange les données envoyées, et, surtout, averti que le formulaire a bien été digéré en renvoyant la page adhoc (te proposant de revenir au site ou à son menu)
Avec un mailto tu n'as pas de retour. Tu restes bête devant ta page remplie qui reste là à te regarder bêtement elle aussi.
Oui. Comme une fois que le submit s'est fait JS n'a plus accès à rien et reste dans l'ignorance la plus totale de ce qui se passe, on peut partir du principe que le form est parti, et afficher un petit message : "il y a 99% de chances que le formulaire aie été correctement envoyé" ... ;-)
Voilà donc ce que j'avais en tête.
Ouf ! çà fait du bien d'en être débarrassé.
Wép, ça fait de la place :)
-- Olivier Ligny Créateur web free-lance / www.cyber-tamtam.net
O.L.
bruno at modulix a couché sur son écran :
O.L. wrote:
au fait, avec action="mailto:blabla" le serveur peut contrôler çà et renvoyer le form à compléter ? en php par exemple ?
Euh, je suis pas sûr de bien comprendre, mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit, ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées et éventuellement les corrige,
Sur le client ?
Oui et non. Le but de mon bazar est de faire en sorte que les entrées d'un formulaire que l'on veut envoyer par email (action=mailto) puissent être auparavant vérifiées et, éventuellement, corrigées par un script PHP.
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Mais bon, au niveau de l'utilité du truc, je ne suis sûr de rien, puisque apparrament je n'avais pas saisi ce que demandais ASM ... :)
-- Olivier Ligny Créateur web free-lance / www.cyber-tamtam.net
bruno at modulix a couché sur son écran :
O.L. wrote:
au fait, avec
action="mailto:blabla"
le serveur peut contrôler çà et renvoyer le form à compléter ?
en php par exemple ?
Euh, je suis pas sûr de bien comprendre, mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit,
ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées
et éventuellement les corrige,
Sur le client ?
Oui et non.
Le but de mon bazar est de faire en sorte que les entrées d'un
formulaire que l'on veut envoyer par email (action=mailto) puissent
être auparavant vérifiées et, éventuellement, corrigées par un script
PHP.
Donc d'abord on envoie le contenu du form au script PHP (comme on fait
d'habitude), puis ce script PHP donne en retour un formulaire avec
action=mailto qui s'envoie de chez le client, avec les données
vérifiées entre-temps.
Mais bon, au niveau de l'utilité du truc, je ne suis sûr de rien,
puisque apparrament je n'avais pas saisi ce que demandais ASM ... :)
--
Olivier Ligny
Créateur web free-lance / www.cyber-tamtam.net
au fait, avec action="mailto:blabla" le serveur peut contrôler çà et renvoyer le form à compléter ? en php par exemple ?
Euh, je suis pas sûr de bien comprendre, mais je pense que oui :
L'utilisateur remplit son formulaire, il clique sur son bouton Submit, ça arrive au script PHP caché dans une IFRAME, qui vérifie les entrées et éventuellement les corrige,
Sur le client ?
Oui et non. Le but de mon bazar est de faire en sorte que les entrées d'un formulaire que l'on veut envoyer par email (action=mailto) puissent être auparavant vérifiées et, éventuellement, corrigées par un script PHP.
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Mais bon, au niveau de l'utilité du truc, je ne suis sûr de rien, puisque apparrament je n'avais pas saisi ce que demandais ASM ... :)
-- Olivier Ligny Créateur web free-lance / www.cyber-tamtam.net
Patrick Mevzek
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Donc d'abord on envoie le contenu du form au script PHP (comme on fait
d'habitude), puis ce script PHP donne en retour un formulaire avec
action=mailto qui s'envoie de chez le client, avec les données
vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
ASM
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
parceque on n'a pas pris l'option php mail facturée très cher par l'hébergeur ? je suppose
ou pour rester dans la Q de départ : action="mailto: ..."
ou parceque s'il n'y avait pas eu au moins un petit bout de code JS, on aurait été hors charte ?
-- Stephane Moriaux et son [moins] vieux Mac
Donc d'abord on envoie le contenu du form au script PHP (comme on fait
d'habitude), puis ce script PHP donne en retour un formulaire avec
action=mailto qui s'envoie de chez le client, avec les données
vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
parceque on n'a pas pris l'option php mail
facturée très cher par l'hébergeur ?
je suppose
ou pour rester dans la Q de départ : action="mailto: ..."
ou parceque s'il n'y avait pas eu au moins
un petit bout de code JS, on aurait été hors charte ?
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
parceque on n'a pas pris l'option php mail facturée très cher par l'hébergeur ? je suppose
ou pour rester dans la Q de départ : action="mailto: ..."
ou parceque s'il n'y avait pas eu au moins un petit bout de code JS, on aurait été hors charte ?
-- Stephane Moriaux et son [moins] vieux Mac
Patrick Mevzek
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
parceque on n'a pas pris l'option php mail facturée très cher par l'hébergeur ? je suppose
Quelle drôle d'idée. Parce que si on compte sur le _client_ pour faire l'envoi, il ne faut pas espérer de bonne fiabilité, sans compter que niveau sécurité, un client pourrait bidouiller complétement le contenu du mail.
Bref, je ne vois pas un seul cas de figure où c'est intéressant. S'il n'y a pas mail chez l'hébergeur, on proteste ou on change ou on trouve un autre moyen de transférer l'information (SGBDR, FTP, SCP, etc...)
ou parceque s'il n'y avait pas eu au moins un petit bout de code JS, on aurait été hors charte ?
Là, fatalement, ca tue :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Donc d'abord on envoie le contenu du form au script PHP (comme on fait
d'habitude), puis ce script PHP donne en retour un formulaire avec
action=mailto qui s'envoie de chez le client, avec les données
vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
parceque on n'a pas pris l'option php mail
facturée très cher par l'hébergeur ?
je suppose
Quelle drôle d'idée. Parce que si on compte sur le _client_ pour faire
l'envoi, il ne faut pas espérer de bonne fiabilité, sans compter que
niveau sécurité, un client pourrait bidouiller complétement le contenu
du mail.
Bref, je ne vois pas un seul cas de figure où c'est intéressant.
S'il n'y a pas mail chez l'hébergeur, on proteste ou on change ou on
trouve un autre moyen de transférer l'information (SGBDR, FTP, SCP, etc...)
ou parceque s'il n'y avait pas eu au moins
un petit bout de code JS, on aurait été hors charte ?
Là, fatalement, ca tue :-)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Donc d'abord on envoie le contenu du form au script PHP (comme on fait d'habitude), puis ce script PHP donne en retour un formulaire avec action=mailto qui s'envoie de chez le client, avec les données vérifiées entre-temps.
Quel intérêt a le script PHP a ne pas faire l'envoi par email lui-même ?
parceque on n'a pas pris l'option php mail facturée très cher par l'hébergeur ? je suppose
Quelle drôle d'idée. Parce que si on compte sur le _client_ pour faire l'envoi, il ne faut pas espérer de bonne fiabilité, sans compter que niveau sécurité, un client pourrait bidouiller complétement le contenu du mail.
Bref, je ne vois pas un seul cas de figure où c'est intéressant. S'il n'y a pas mail chez l'hébergeur, on proteste ou on change ou on trouve un autre moyen de transférer l'information (SGBDR, FTP, SCP, etc...)
ou parceque s'il n'y avait pas eu au moins un petit bout de code JS, on aurait été hors charte ?
Là, fatalement, ca tue :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
