> et l'existence de bistrots et restaurants plus nombreux
C'est pas ça qui va sauver la dentition de M de la noyade.
Pendant ce temps, la baskie croule sous les intempéries.
#5313910/11/13 - 12h45 : M
Oui : la (relative) proximité de chez moidu local de la rue des Mariniers et une bonne desserte par autobus, et l'existence de bistrots et restaurants plus nombreux et moins chers dans le quartier.
#5313810/11/13 - 12h27 : Zorglub
la rando MEV
J'ai découvert que le départ se faisait dorénavant de Montpar'. Y a-t-il une raison particulière à ce changement ?
#5313710/11/13 - 12h12 : M
Platines réglées, roulements huilés, roues permutées. Je vais voir si mes chevilles sont compatibles avec la rando MEV de staprème.
Je n'ai pas encore mis les roues neuves d'XS.
#5313610/11/13 - 00h51 : M
J'imagine que mais j'ai les dents du fond qui baignent
futur client.
Trop fort ce mec. Je note qu'il a piqué l'espace vital de son Jvuvuzela et pas l'inverse. Bon faut m'excuser j'ai match.
#5313409/11/13 - 19h32 : Zorglub
Ajax
Je renonce avant même d'avoir réellement commencé, d'une part je n'y comprends absolument RIEN, d'autre part, j'ai toujours eu des réticences à utiliser du js pour les commandes fondamentales d'un site, au risque qu'il devienne totalement inaccessible à ceux qui n'ont pas le bon navigateur ou la bonne version, ou qui ont désactivé les scripts...
#5313309/11/13 - 18h37 : M
Y'a juste à démonter la maison pour extraire le bouzin
Je comprends l'idée générale (introduire les modif. sans rechargement, ce qui résoudrait mon problème), je comprends vaguement le principe général (une fonction Ajax dirige la manière dont est traité le formulaire en php), reste à savoir si j'aurais les capacités ou la patience d'essayer de comprendre suffisamment la fonction pour l'adapter à mon contexte.
Z #5313009/11/13 - 13h13 : steph
Je le récapdupète : le salut est dans l'AJAX. Mettre à jour les DIV qui contiennent le texte et le formulaire sans rechargement de la page.
Une requête asynchrone (c'est beau!) devrait faire l'affaire.
Je ne vois actuellement aucun moyen de réaliser le point 2. : la fonction ScrollIntoView agit sur l'affichage et ne permet pas de le tester.
Deux options en l'état :
- renoncer ;
- opter pour une solution partiellement satisfaisante : si certaines cases sont cochées dans le menu alors partir du principe que l'utilisateur doit s'intéresser à une partie de tel ensemble et le replacer, sinon sur cette partie, au moins sur le début de l'ensemble auquel elle appartient.
Que vous en semble ?
Rien, j'entends bien, mais encore ?
Z #5312809/11/13 - 03h32 : M
Bonne chance
steph #5312708/11/13 - 22h21 : Zorglub
Merci pour ton assistance. La solution sera (peut-être) un mixte entre ce que tu as trouvé et ceci.
Je me suis déjà assurée d'un premier point indispensable, à savoir que l'on pouvait doubler un bouton de formulaire d'une fonction js de type onclick : c'est intellectuellement horrible, mais ça marche.
Reste :
1. à voir quel type d'élément peut être visé par le ScrollIntoView (seulement des élément visibles ou d'autres choses, telles que des ancres),
2. à construire les conditions : pour la faire brève, chercher un élément du type indiqué pour lequel ScrollIntoView soit vrai,
3. construire la fonction appelée par le onclick qui permette de préserver cette vérité ou de positionner cet élément par exemple en haut d'écran.
Autant dire que ce n'est pas gagné.
Z #5312608/11/13 - 20h56 : steph
L'API JQuery sera ton amie. C'est une composante d'AJAX.
Elle te permet de détecter la position du visiteur sur la page (et de récupérer les variables de positionnement).
Exemple ici.
Il ne te reste plus qu'à injecter ces variables dans ton formulaire pour replacer ton visiteur à l'endroit où il se trouvait.
En théorie hein, je n'ai pas testé.
#5312508/11/13 - 19h59 : Zorglub
Le fait que le formulaire se trouvait affiché au moment de sa validation (forcément) n'est pas une info suffisamment précise ?
Si c'était le cas, ce serait trop fastoche. Le formulaire est fixé sur son div à lui, tandis que le texte scrollable est sur un autre. Je rappelle que la page pour laquelle le problème se pose est celle-ci.
#5312408/11/13 - 19h45 : M
Le fait que le formulaire se trouvait affiché au moment de sa validation (forcément) n'est pas une info suffisamment précise ?
#5312308/11/13 - 18h58 : Zorglub
Ajax
Elle ne passera rien du tout car, pour ce que j'ai compris, le fonctionnement du code (cf. l'usage de history) ou des fonctions js location.hash utilise des ancres qui a un moment quelconque ont figuré dans l'url (#toto)*.
Dans mon cas en revanche, il n'y pas d'ancre dans l'url et il n'y en a jamais eu. La seule donnée qu'il faudrait exploiter, et je ne sais comment, c'est le fait que telle partie de la page s'affiche à l'écran au moment où l'utilisateur envoie le formulaire. Ma question est donc par quel biais peut-on enregistrer l'information "cette partie de la page s'affiche" et peu importe ensuite s'il faut la préciser en nombre de lignes depuis le début du fichier, par des ancres ou autre chose.
J'ai déjà observé que certaines vidéos cessaient de se jouer lorsqu'elle sortaient de l'écran, c'est le même type d'information que je voudrais pouvoir exploiter et que met en oeuvre aussi le simple refresh d'une page.
Merci.
Pour le peut que j'ai eu le temps de chercher, le js devrait suffire ; le problème est que je suis une quiche en js à un point exceptionnel et que je vais donc derechef devoir y passer des heures.
à mettre des balises
J'entends bien et suis prête à mettre toutes les ancres (ou toute autre forme de balises) que l'on souhaite. Ma question est : quelle variable/fonction... permet d'établir que si tel texte est à l'écran, alors on est au niveau de telle ancre ou balise ?
#5311407/11/13 - 13h40 : M
Le tout est de ne pas se la prendre en pleine face