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