j'ai une form :
<form action='http://127.0.0.1/ruby/man.rbx' method='post'>
<p>
<label for='search'>Search : </labeL>
<input type='text' id='search' name='search' value='man'>
<input type='submit' value='Send'> <input type='reset'>
</p>
</form>

qui me sert (vira...) à visualiser les pages de man aussi, j'ai donné à
'search' la valeur par défaut "man".

si j'entre, par exemple "eruby", j'ai bien dans mon cgi['search'] la
valeur "eruby" et je peux afficher le corps du fichier html
"/Users/yt/man/#{cgi['search']}.html" dans ma page
'http://127.0.0.1/ruby/man.rbx'.

MAIS la valeur affichée dans l'input text est "man", soit la valeur par
défaut, je préférerais afficher la valeur entrée ?

comment éviter ça ?
--
Une Bévue

Une Bévue a écrit :
> j'ai une form :
> <form action='http://127.0.0.1/ruby/man.rbx' method='post'>
> <p>
> <label for='search'>Search : </labeL>
> <input type='text' id='search' name='search' value='man'>
> <input type='submit' value='Send'> <input type='reset'>
> </p>
> </form>
>
> qui me sert (vira...) à visualiser les pages de man aussi, j'ai donné à
> 'search' la valeur par défaut "man".
>
> si j'entre, par exemple "eruby", j'ai bien dans mon cgi['search'] la
> valeur "eruby" et je peux afficher le corps du fichier html
> "/Users/yt/man/#{cgi['search']}.html" dans ma page
> 'http://127.0.0.1/ruby/man.rbx'.
>
> MAIS la valeur affichée dans l'input text est "man", soit la valeur par
> défaut, je préférerais afficher la valeur entrée ?
>
> comment éviter ça ?

<?
if (cgi['search']="") {
cgi['search'] = "man";
}
?>
<form action='http://127.0.0.1/ruby/man.rbx' method='post'>
<p>
<label for='search'>Search : </labeL>
<input type='text' id='search' name='search' value='cgi['search']'>
<input type='submit' value='Send'> <input type='reset'>
</p>
</form>
??

giganet <giganet@free.fr> wrote:

>
> <?
> if (cgi['search']="") {
> cgi['search'] = "man";
> }
> ?>
> <form action='http://127.0.0.1/ruby/man.rbx' method='post'>
> <p>
> <label for='search'>Search : </labeL>
> <input type='text' id='search' name='search' value='cgi['search']'>
> <input type='submit' value='Send'> <input type='reset'>
> </p>
> </form>
> ??

ok, c'est béton ;-)

si j'ai bien compris, en php, aussi, on est obligé de faire ça ?
j'ai trouvé "curieux" que le brouteur file une valeur et en affiche une
autre...

en tk, merci bien !
--
Une Bévue

Le 03/05/2008 22:19, Une Bévue a écrit :
>
> si j'ai bien compris, en php, aussi, on est obligé de faire ça ?

Si j'ai bien compris, tu avais envie que la valeur demandée dans la
nouvelle page soit écrasée par celle saisie par l'utilisateur sur la
page précédente ?

> j'ai trouvé "curieux" que le brouteur file une valeur et en affiche une
> autre...

Le brouteur fait une requête en passant certains paramètres, puis le
serveur envoie une page en retour. Ce que je trouve curieux, c'est que
tu souhaites que le navigateur décide de lui-même que la page retournée
par le serveur est incorrecte, et qu'il prenne l'initiative de changer
le code.

Olivier Miakinen <om+news@miakinen.net> wrote:

> > si j'ai bien compris, en php, aussi, on est obligé de faire ça ?
>
> Si j'ai bien compris, tu avais envie que la valeur demandée dans la
> nouvelle page soit écrasée par celle saisie par l'utilisateur sur la
> page précédente ?

oui histoire de donner un feedback à l'utilisateur du genre "j'ai bien
compris votre commande, vous voulez que j'affiche la page de man XXX"...
>
> > j'ai trouvé "curieux" que le brouteur file une valeur et en affiche une
> > autre...
>
> Le brouteur fait une requête en passant certains paramètres, puis le
> serveur envoie une page en retour. Ce que je trouve curieux, c'est que
> tu souhaites que le navigateur décide de lui-même que la page retournée
> par le serveur est incorrecte, et qu'il prenne l'initiative de changer
> le code.

ben non, ce qui me trouble :

je suis toujours dans la page '/man/index.rbx' là, dans l'input text,
j'entre le nom d'une commande de man, par exemple "mkdir", puis je fais
enter ou je clique sur le bouton de sousmission.

comme j'ai :
<form id='search_form' action='http://127.0.0.1/man/index.rbx'
method='post'>

le brouteur recharge la page avec cgi['search'] = "mkdir"
et mon script cgi-ruby affiche bien la page de man relative à "mkdir"
(sous la form).

mais l'input lui, affiche la valeur par défaut (après rechargement de la
page), voilà, c'est ce qui m'a "troublé" le brouteur affiche le bon
résultat (ie la bonne page de man dans le corps du document), mais
affiche "man", la valeur par défaut de l'input et pas celle entrée
précédemment par l'utilisateur.

mais bon, la solution donnée par "giganet" me convient très bien.
en fait, je pense que l'astuce donnée par "giganet" est systématiquement
utilisée par les gens qui conçoivent des sites avec form (quand on reste
sur la même page), sinon, on perdrait l'info entrée précédemment...

et, comme le rechargement de la page ne me plait pas, je vai regarder
une solution où le cgi-ruby file à javascript le nouveau contenu (la
page de man) et javascript s'occuperait de l'affichage via le DOM, mais
c'est une autre histoire...
--
Une Bévue

Le 04/05/2008 12:48, Une Bévue a écrit :
>>
>> Si j'ai bien compris, tu avais envie que la valeur demandée dans la
>> nouvelle page soit écrasée par celle saisie par l'utilisateur sur la
>> page précédente ?
>
> oui histoire de donner un feedback à l'utilisateur du genre "j'ai bien
> compris votre commande, vous voulez que j'affiche la page de man XXX"...

C'est *ton* interprétation. L'interprétation du navigateur au moment de
faire la requête POST, c'est « j'envoie une requête POST avec comme
paramètre 'search=eruby' » ; l'interprétation du serveur est « j'ai
reçu une requête, je renvoie la réponse » ; enfin l'interprétation du
navigateur est « je reçois une page HTML contenant un input de type
'text', de nom 'search', et de valeur 'man' ». Je précise, car ça ne
semble pas être clair pour toi, que la requête est oubliée depuis
longtemps. Qui plus est, il n'est pas censé savoir non plus qu'il s'agit
de « la même page » (c.-à-d. la même URL), ni que parmi tous les input
possibles de type 'text' et de nom 'search' il doit ignorer la valeur
'man' qu'on lui a passée.

>> Le brouteur fait une requête en passant certains paramètres, puis le
>> serveur envoie une page en retour. Ce que je trouve curieux, c'est que
>> tu souhaites que le navigateur décide de lui-même que la page retournée
>> par le serveur est incorrecte, et qu'il prenne l'initiative de changer
>> le code.
>
> ben non, ce qui me trouble :
>
> je suis toujours dans la page '/man/index.rbx'

NON !

Tu as quitté la page, qui s'appelait peut-être '/man/index.rbx', pour en
charger *une autre*, qui s'appelle peut-être aussi '/man/index.rbx'. Il
n'y a strictement aucune raison pour que le navigateur fasse un truc
particulier quand la nouvelle page porte le même nom que l'ancienne. À
moins bien sûr que tu n'aies lu dans la norme qu'il faille faire quelque
chose de spécial dans ce cas *très* particulier.

Le serveur a toute latitude pour choisir la valeur par défaut en
fonction des paramètres qui lui sont passés, je ne vois pas pourquoi on
irait rajouter une bidouille dans le navigateur pour l'en empêcher !

D'ailleurs, quel serait l'intérêt de mettre comme valeur par défaut de
l'input celle qui est déjà affichée ? Au contraire, dans la plupart des
cas c'est celle qui présente le moins d'intérêt, puisqu'on l'a déjà !

> mais bon, la solution donnée par "giganet" me convient très bien.

Ben oui.

> en fait, je pense que l'astuce donnée par "giganet"

Euh... appelle-ça une astuce si tu veux, moi ça me semble une méthode
normale.

> est systématiquement
> utilisée par les gens qui conçoivent des sites avec form (quand on reste
> sur la même page), sinon, on perdrait l'info entrée précédemment...

Tu veux dire de prendre comme valeur par défaut celle de la page déjà
affichée ? Moi je verrais plutôt :
- mettre la valeur "suivante" dans le cas où une recherche séquentielle
peut avoir un sens ;
- mettre la valeur "la plus proche sémantiquement" quand c'est approprié
(par exemple, mettre le synonyme le plus proche du mot courant pour un
dictionnaire des synonymes) ;
- etc.

> et, comme le rechargement de la page ne me plait pas, je vai regarder
> une solution où le cgi-ruby file à javascript le nouveau contenu (la
> page de man) et javascript s'occuperait de l'affichage via le DOM, mais
> c'est une autre histoire...

Ah, là en effet, c'est autre chose. Dans ce cas tu pourras vraiment
considérer que la page ne change pas, ce qui n'est certainement pas le
cas avec une requête POST.

Olivier Miakinen <om+news@miakinen.net> wrote:

> Le 04/05/2008 12:48, Une Bévue a écrit :
> >>
> >> Si j'ai bien compris, tu avais envie que la valeur demandée dans la
> >> nouvelle page soit écrasée par celle saisie par l'utilisateur sur la
> >> page précédente ?
> >
> > oui histoire de donner un feedback à l'utilisateur du genre "j'ai bien
> > compris votre commande, vous voulez que j'affiche la page de man XXX"...
>
> C'est *ton* interprétation. L'interprétation du navigateur au moment de
> faire la requête POST, c'est « j'envoie une requête POST avec comme
> paramètre 'search=eruby' » ; l'interprétation du serveur est « j'ai
> reçu une requête, je renvoie la réponse » ; enfin l'interprétation du
> navigateur est « je reçois une page HTML contenant un input de type
> 'text', de nom 'search', et de valeur 'man' ». Je précise, car ça ne
> semble pas être clair pour toi, que la requête est oubliée depuis
> longtemps. Qui plus est, il n'est pas censé savoir non plus qu'il s'agit
> de « la même page » (c.-à-d. la même URL), ni que parmi tous les input
> possibles de type 'text' et de nom 'search' il doit ignorer la valeur
> 'man' qu'on lui a passée.


Euh, je parlais en "fonctionnalité" du point de vue "utilisateur" non
pas de la machinerie derrière...

> >> Le brouteur fait une requête en passant certains paramètres, puis le
> >> serveur envoie une page en retour. Ce que je trouve curieux, c'est que
> >> tu souhaites que le navigateur décide de lui-même que la page retournée
> >> par le serveur est incorrecte, et qu'il prenne l'initiative de changer
> >> le code.
> >
> > ben non, ce qui me trouble :
> >
> > je suis toujours dans la page '/man/index.rbx'
>
> NON !
>
> Tu as quitté la page, qui s'appelait peut-être '/man/index.rbx', pour en
> charger *une autre*, qui s'appelle peut-être aussi '/man/index.rbx'. Il
> n'y a strictement aucune raison pour que le navigateur fasse un truc
> particulier quand la nouvelle page porte le même nom que l'ancienne. À
> moins bien sûr que tu n'aies lu dans la norme qu'il faille faire quelque
> chose de spécial dans ce cas *très* particulier.
>
> Le serveur a toute latitude pour choisir la valeur par défaut en
> fonction des paramètres qui lui sont passés, je ne vois pas pourquoi on
> irait rajouter une bidouille dans le navigateur pour l'en empêcher !
>
> D'ailleurs, quel serait l'intérêt de mettre comme valeur par défaut de
> l'input celle qui est déjà affichée ? Au contraire, dans la plupart des
> cas c'est celle qui présente le moins d'intérêt, puisqu'on l'a déjà !

ben là, nous ne sommes pas d'accord, ça a un intérêt, pour moi,
d'afficher dans l'input la page qui a été demandée en particulier ne
serait-ce que par ce que les pages de man n'ont **pas toujours** un
titre qui indique de quelle commande il s'agit.

> > mais bon, la solution donnée par "giganet" me convient très bien.
>
> Ben oui.
>
> > en fait, je pense que l'astuce donnée par "giganet"
>
> Euh... appelle-ça une astuce si tu veux, moi ça me semble une méthode
> normale.
>
> > est systématiquement
> > utilisée par les gens qui conçoivent des sites avec form (quand on reste
> > sur la même page), sinon, on perdrait l'info entrée précédemment...
>
> Tu veux dire de prendre comme valeur par défaut celle de la page déjà
> affichée ? Moi je verrais plutôt :
> - mettre la valeur "suivante" dans le cas où une recherche séquentielle
> peut avoir un sens ;
> - mettre la valeur "la plus proche sémantiquement" quand c'est approprié
> (par exemple, mettre le synonyme le plus proche du mot courant pour un
> dictionnaire des synonymes) ;
> - etc.

dans mon cas, particulier des pages de man, attrapper "sémantiquement"
les pages approchantes, c'est loin d'être évident. Il faut qqc d'assez
"sioux" genre "lire la page effectivement affichée et ses 'SEE ALSO'".
dans ce cadre-là, j'ai ajouté deux choses :
- un menu qui liste les pages déjà converties ;
- un js de suggestion de page de man construit à partir des pages déjà
converties (auto-completion dans l'input 'search')*.

mais bon, je regarderais comment ajouter d'autres suggestions ne
serait-ce que celles des 'SEE ALSO' de la page visualisée.

et comme la difficulté, en tant qu'utilisateur est de connaître une
commande, je veux dire son existence, avoir un système permettant de
visualiser toutes les pages de man existant sur ma bécanne, en
hiérarchisant mais bon il ne me semble pas évident de les regrouper
"sémantiquement", de les catégoriser.


> > et, comme le rechargement de la page ne me plait pas, je vai regarder
> > une solution où le cgi-ruby file à javascript le nouveau contenu (la
> > page de man) et javascript s'occuperait de l'affichage via le DOM, mais
> > c'est une autre histoire...
>
> Ah, là en effet, c'est autre chose. Dans ce cas tu pourras vraiment
> considérer que la page ne change pas, ce qui n'est certainement pas le
> cas avec une requête POST.

oui, enfin, j'ai commencé à le faire, mon cgi-ruby écrit déjà un objet
JavaScript (les pages déjà converties en html)

* là (avec l'auto-complétion) j'ai un problème de js, ça marche bien
excepté un "détail" qui me gène et dont je ne comprends pas la cause.

d'après ce que j'ai lu du script d'auto-complétion (du à un certain
Elegie) la recherche (regexp) est sensible à la casse, je veux dire par
là que dans le code je ne vois pas de /.../i, MAIS le résultat de cette
recherche ne l'est pas (?) par exemple j'ai actuellement comme pages de
man converties :
'SetFile' et 'setfcomment'

et si j'entre dans mon input 'search' Set, donc avec un grand "S", ça me
suggère "Setfcomment" qui n'existe pas...

comme je l'ai dit + haut je ne pige pas pourquoi, mais le code du à
Elegie m'est assez hermétique, on peut le trouver là:
acticle sur usenet - clj :
<http://thoraval.yvon.free.fr/Fixed_layout/doc/suggestion_google.html>
le js proprement dit :
<http://thoraval.yvon.free.fr/Fixed_layout/js/suggest_colors_elegie.js>
adaptée, dans ce cas, aux couleurs nommées.

--
Une Bévue

--{ Une Bévue a plopé ceci: }--


> dans mon cas, particulier des pages de man, attrapper "sémantiquement"
> les pages approchantes, c'est loin d'être évident. Il faut qqc d'assez
> "sioux" genre "lire la page effectivement affichée et ses 'SEE ALSO'".

Pourtant, les manpages sur http://openbsd.org/ gèrent très bien
les SEE ALSO. Je n'ai jamais regardé comment ils font, mais tu
pourrais essayer de t'en inspirer...

> commande, je veux dire son existence, avoir un système permettant de
> visualiser toutes les pages de man existant sur ma bécanne, en

$ man xman


--
>> Euh, juste par pure curiosité technique. Comment est défini le barycentre
>> sur une variété qui n'est pas globalement difféomorphe à une boule ?
> À tes souhaits.
-+- JS in GFA -+- Bien configurer sa curiosite technique.

Une Bévue <unbewusst.sein@weltanschauung.com.invalid> wrote:

>
> * là (avec l'auto-complétion) j'ai un problème de js, ça marche bien
> excepté un "détail" qui me gène et dont je ne comprends pas la cause.
>
> d'après ce que j'ai lu du script d'auto-complétion (du à un certain
> Elegie) la recherche (regexp) est sensible à la casse, je veux dire par
> là que dans le code je ne vois pas de /.../i, MAIS le résultat de cette
> recherche ne l'est pas (?) par exemple j'ai actuellement comme pages de
> man converties :
> 'SetFile' et 'setfcomment'
>
> et si j'entre dans mon input 'search' Set, donc avec un grand "S", ça me
> suggère "Setfcomment" qui n'existe pas...
>
> comme je l'ai dit + haut je ne pige pas pourquoi, mais le code du à
> Elegie m'est assez hermétique, on peut le trouver là:
> acticle sur usenet - clj :
> <http://thoraval.yvon.free.fr/Fixed_layout/doc/suggestion_google.html>
> le js proprement dit :
> <http://thoraval.yvon.free.fr/Fixed_layout/js/suggest_colors_elegie.js>
> adaptée, dans ce cas, aux couleurs nommées.

bon, ça, j'ai trouvé le pb, dans le code js il y avait la ligne :
//complete=man_pages[txt[1].toLowerCase()];
//changée en :
complete=man_pages[txt[1]];

et, apparemment, ça roule...
--
Une Bévue

Une Bévue a écrit :
>
> * là (avec l'auto-complétion) j'ai un problème de js, ça marche bien
> excepté un "détail" qui me gène et dont je ne comprends pas la cause.
>
> d'après ce que j'ai lu du script d'auto-complétion (du à un certain
> Elegie) la recherche (regexp) est sensible à la casse,

oui, peut-être ?
ça semble être là :

// validate that the started word matches
txt=/\b(.(\B.)+)$/.exec(el.value.substr(0, ii));

et je ne sais pas trop ce que fait : /\b(.(\B.)+)$/

mais tout l'bazar prévu pour les couleurs, finalement ne traite qu'en
minuscules :
if(txt) {
complete=color_values[txt[1].toLowerCase()];
^^^^^^^^^^^^^

> par exemple j'ai actuellement comme pages de
> man converties :
> 'SetFile' et 'setfcomment'
>
> et si j'entre dans mon input 'search' Set, donc avec un grand "S", ça me
> suggère "Setfcomment" qui n'existe pas...
>
> comme je l'ai dit + haut je ne pige pas pourquoi, mais le code du à
> Elegie m'est assez hermétique, on peut le trouver là:
> acticle sur usenet - clj :
> <http://thoraval.yvon.free.fr/Fixed_layout/doc/suggestion_google.html>
> le js proprement dit :
> <http://thoraval.yvon.free.fr/Fixed_layout/js/suggest_colors_elegie.js>
> adaptée, dans ce cas, aux couleurs nommées.

--
sm

Le 05/05/2008 11:25, Une Bévue a écrit :
>
> Euh, je parlais en "fonctionnalité" du point de vue "utilisateur" non
> pas de la machinerie derrière...

C'est bien ce que je disais : tu parles de *ton* interprétation de ce
qui serait bien pour *ton* cas.

Mais pour obtenir cette fonctionnalité du point de vue utilisateur, il
te suffit de programmer le serveur pour qu'il donne comme valeur par
défaut celle qu'il a trouvée dans la requête. D'autres que toi, voulant
une autre valeur par défaut, la programmeront dans le serveur selon
leurs propres besoins. C'est simple et de bon goût.

Au contraire, ce que tu dis depuis le début de cette discussion,
c'est que les navigateurs devraient ignorer cette valeur fournie par
le serveur (adaptable par chacun) et la remplacer par une valeur
particulière, qui se trouve convenir à *ton* besoin, mais pas forcément
aux besoins des autres. Alors qu'il existe une solution simple qui peut
convenir à tous, tu voudrais imposer une solution compliquée qui ne
fonctionnera pas dans tous les cas.

C'est ÇA que je trouve curieux.

>> D'ailleurs, quel serait l'intérêt de mettre comme valeur par défaut de
>> l'input celle qui est déjà affichée ? Au contraire, dans la plupart des
>> cas c'est celle qui présente le moins d'intérêt, puisqu'on l'a déjà !
>
> ben là, nous ne sommes pas d'accord, ça a un intérêt, pour moi,
> d'afficher dans l'input la page qui a été demandée en particulier ne
> serait-ce que par ce que les pages de man n'ont **pas toujours** un
> titre qui indique de quelle commande il s'agit.

Ça a un intérêt *pour toi*. Mais ça empêcherait le fonctionnement pour
les autres dans la plupart des cas. Vu qu'il existe une solution simple
qui fonctionnera pour tous les cas, autant l'utiliser.

> dans mon cas, particulier des pages de man, attrapper "sémantiquement"
> les pages approchantes, c'est loin d'être évident.

Encore une fois, ton cas particulier est loin d'être le seul.

Thierry B. <tth@prout.stex.invalid> wrote:

>
> Pourtant, les manpages sur http://openbsd.org/ gèrent très bien
> les SEE ALSO. Je n'ai jamais regardé comment ils font, mais tu
> pourrais essayer de t'en inspirer...

j'y suis ;-)
je m'aperçois d'une différence entre la sortie :
$ man xman
et :
$ man xman | man2html


il n'y a justement plus ce que j'indique + bas...

>
> > commande, je veux dire son existence, avoir un système permettant de
> > visualiser toutes les pages de man existant sur ma bécanne, en
>
> $ man xman

je suis rarement sous X11...
en tk, merci beaucoup, j'ai "un peu plus" de "sémantique" là :

Directory Section Name
--------- ------------
man1 (1) User Commands
man2 (2) System Calls
man3 (3) Subroutines
man4 (4) Devices
man5 (5) File Formats
man6 (6) Games
man7 (7) Miscellaneous
man8 (8) Sys. Administration
manl (l) Local
mann (n) New
mano (o) Old

--
Une Bévue

SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

> complete=color_values[txt[1].toLowerCase()];
> ^^^^^^^^^^^^^

oui, merci, c'est ce que j'ai vu entre-temps, supprimer le
"toLowerCase()" est suffisant...
--
Une Bévue

Olivier Miakinen <om+news@miakinen.net> wrote:

>
> Au contraire, ce que tu dis depuis le début de cette discussion,
> c'est que les navigateurs devraient ignorer cette valeur fournie par
> le serveur (adaptable par chacun) et la remplacer par une valeur
> particulière, qui se trouve convenir à *ton* besoin, mais pas forcément
> aux besoins des autres. Alors qu'il existe une solution simple qui peut
> convenir à tous, tu voudrais imposer une solution compliquée qui ne
> fonctionnera pas dans tous les cas.
>
> C'est ÇA que je trouve curieux.


mon erreur est d'acoir pris le comportement d'un certain nombre de pages
pour le comportement du navigateur...

> >> D'ailleurs, quel serait l'intérêt de mettre comme valeur par défaut de
> >> l'input celle qui est déjà affichée ? Au contraire, dans la plupart des
> >> cas c'est celle qui présente le moins d'intérêt, puisqu'on l'a déjà !
> >
> > ben là, nous ne sommes pas d'accord, ça a un intérêt, pour moi,
> > d'afficher dans l'input la page qui a été demandée en particulier ne
> > serait-ce que par ce que les pages de man n'ont **pas toujours** un
> > titre qui indique de quelle commande il s'agit.
>
> Ça a un intérêt *pour toi*. Mais ça empêcherait le fonctionnement pour
> les autres dans la plupart des cas. Vu qu'il existe une solution simple
> qui fonctionnera pour tous les cas, autant l'utiliser.

???

>
> > dans mon cas, particulier des pages de man, attrapper "sémantiquement"
> > les pages approchantes, c'est loin d'être évident.
>
> Encore une fois, ton cas particulier est loin d'être le seul.

???

--
Une Bévue

Le 05/05/2008 18:27, Une Bévue a écrit :
>
> mon erreur est d'acoir pris le comportement d'un certain nombre de pages
> pour le comportement du navigateur...

En effet, alors qu'en réalité c'est le comportement du serveur, voire la
norme HTML. En passant, la commande « View / Source » est ton amie.

>> Ça a un intérêt *pour toi*. Mais ça empêcherait le fonctionnement pour
>> les autres dans la plupart des cas. Vu qu'il existe une solution simple
>> qui fonctionnera pour tous les cas, autant l'utiliser.
>
> ???

Ben oui : c'est de demander au serveur (plus précisément au script sur
le serveur) de remplir la valeur par défaut dont tu as envie qu'elle
soit la vraie valeur par défaut, au lieu de mettre une autre valeur qui
ne te plaît pas.

>> Encore une fois, ton cas particulier est loin d'être le seul.
>
> ???

Je croyais avoir été clair, mais on est mauvais juge de ses propres
explications. Si quelqu'un veut prendre le relais pour t'expliquer
mieux que moi les formulaires et les éléments INPUT, je lui en serai
reconnaissant.

--{ Une Bévue a plopé ceci: }--

>> $ man xman
>
> je suis rarement sous X11...
> en tk, merci beaucoup, j'ai "un peu plus" de "sémantique" là :

Avec quel logiciel ?


--
Cleanup Parse Warning: This rendering uses the following experimental
feature(s): spline. The design and implementation of these features is likely
to change in future versions of POV-Ray. Full backward compatibility with the
current implementation is NOT guaranteed.

Thierry B. <tth@prout.stex.invalid> wrote:

>
> Avec quel logiciel ?

ben là, c'est bêtement le man au terminal, la commande :
$ man xman

c'est tout

mais xman me donne la même sortie par contre, ce que j'utilise pour
convertir les pages de man en html, c'est un script perl (man2html) qui,
d'après cette expérience perd une partie de l'info :O

la commande :

$ man xman | man2html

pour l'enregistrer dans un fichier html:

$ man xman | man2html > xman.html
--
Une Bévue