AJAX et indexation - Page 3

(Pour Apache, ça s'appelle de l'url rewriting)

Hmm et donc je fais une redirection vers la page principale lorsqu'on arrive dessus?
(Sinon je me retrouve de nouveau avec plusieurs URLs pour une même page... i.e. http://mondomaine/index.php/monautrepage et http://mondomaine/index.php#monautrepage si fait avec AJAX)

Quel est le problème d’avoir plusieurs URL pour une même page ?
Tu as un jeu d’URLs qui servent à la navigation statique. Et les autres URLs qui correspondent à la navigation AJAX.

C'est dans la doc http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html

C'est apache qui se charge de transformer l'adresse demandée http://www.example.com/search/query en http://www.example.com/search.php?q=query , par exemple
Ton application ne verra que la seconde.

Flan> Oui, en fait c'est ce dont a parlé Sasume qui me troublait, le fait d'avoir deux jeux d'URL ne me semblait pas propre
Merci
Autre chose, pour la navigation en AJAX il faudrait un moyen d'encoder la page du même genre, tout en n'utilisant que l'anchor, par exemple:
http://monserveur/index.php?page=photos&offset=30&type=big
Devrait venir un truc du genre:
http://monserveur/index.php#page_photos__offset_30__type_big
Il y a un moyen standard de faire ça? J'ai l'impression d'être un peu sur la mauvaise voie...

Malheureusement, PHP n'a pas accès à l'ancre...
squale saura peut-être comment faire.

En fait pas besoin de PHP, il faudrait juste une fonction bijective en Javascript, qui permet d'encoder un truc que je demande au serveur (page.php?arg1=val1&argn=valn...) en anchor et l'inverse au cas où la personne aurait noté l'URL.
Comme j'ai vu au fil de mes recherches des moyens d'aller dans un sens mais aucun dans l'autre, je me dis que je fais probablement fausse route

Flanker (./66) :
Malheureusement, PHP n'a pas accès à l'ancre...
squale saura peut-être comment faire.

!call Squale92
--- Call : Squale92 appelé(e) sur ce topic ...
--- Call : Squale92 appelé(e) sur ce topic ...

Avec une imprimante (ou un poulpe) tu auras accès à l'encre...

Flanker (./66) :
Malheureusement, PHP n'a pas accès à l'ancre... squale saura peut-être comment faire.

Effectivement, PHP n'a pas accès à l'ancre : c'est une information que le navigateur n'envoi pas a serveur.

pour ce qui est de "est-ce qu'on peut simuler l'envoi de l'ancre" : oui (genre gmail le fait, me semble : copie-colle l'adresse d'un écran de consultation de mail, ferme le navigateur, relance le avec ton url qui a une ancre, et le mail est chargé)

pour ce qui est du "comment" : jamais fait ; en la récupérant en JS et la poussant vers le serveur via une requête Ajax, je suppose

squale92 (./70) :
pour ce qui est du "comment" : jamais fait ; en la récupérant en JS et la poussant vers le serveur via une requête Ajax, je suppose

Je ne l'ai jamais fait et c'est possible en Ajax ; j'ai un collègue qui l'a fait en Flash.

Mais c'est une utilisation totalement abusive d'un ancre.
# sert pour les paramètres côté client (normalement une position, l'utiliser pour autre chose même en JS côté client est déjà limite abusif), ? pour les paramètres à passer au serveur. Tout le reste, ce sont des bidouilles.

Bon j'ai essayé de faire un super menu dynamique avec JQuery. J'ai une page avec un CSS de façon à afficher un menu basé sur des <ul> (sur autant de niveaux que nécessaire). Exemple:

<ul>
   <li>Accueil</li>
   <li>Mes softs<ul>
      <li>Inutile</li>
      <li>Pas mieux</li>
   </ul></li>
</ul>

On appellera les éléments "Accueil" et "Mes softs" comme menus racine. Ensuite je fais ça:

// Ajoute un nom de classe pour tous les éléments du menu, histoire qu'on puisse les retrouver
var i = 0;
$("#menu").find("li").each(function() {
   $(this).addClass("element" + i++);
});
// Au clic sur un élément
$("#menu li").click(function() {
   event.stopPropagation();
   // Cache les éléments racine qui ne contiennent pas d'élément répondant à la classe de l'élément sélectionné
   var classe = $(this).attr("class");
   $("#menu").find("li").each(function() {
      if ($(this).find("." + classe).length == 0)
         $(this).find("ul").hide();
   });
   $(this).find('ul:first').show();
});

Concrètement: quand on clique sur un élément, je ferme tous les sous-menus racine dont cet élément ne fait pas partie. C'est assez con, mais ça n'est VRAIMENT pas évident à exprimer en JQuery Y a moyen de faire moins dégueu?

J'ai continué dans ma lancée, et en fait j'ai de plus en plus envie de me congratuler d'avoir écrit le code le plus incompréhensible de ma vie. Le même type de plaisir diabolique qu'on a en ayant terminé une regex vraiment gore et impossible à documenter
[Edit] \o/ la première fois de ma vie que j'écris un truc qui fonctionne MIEUX sous IE (et je l'ai ouvert juste pour voir, je l'utilise pas ^^).

Brunni (./74) :
J'ai continué dans ma lancée, et en fait j'ai de plus en plus envie de me congratuler d'avoir écrit le code le plus incompréhensible de ma vie.

J'ai comme ça de magnifiques portions de code avec du PHP qui génère du js, qui génère de l'xhtml... c'est ingérable, quand je dois faire une modification, une fois sur deux ça revient à tout réécrire

Wo putain... je viens de perdre 2 heures sur un truc profondément débile. Comme je génère les pages en PHP j'ai oublié le
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
au début. Et il se trouve que le rendu était tout bugué de partout avec IE (mais des bugs subtils, genre clignotement pendant les animations JQuery, comportement intéressant mais mauvais du padding, etc.). Bref une chance que j'aie finalement tenté ça
En tous cas même si c'est maintenant bon sous IE8 ce n'est pas prêt de fonctionner sous IE6 :/
(Comme je vais devoir faire une version sans script, j'ai assez envie de faire 'if (browser.isExotic) return; // ne fait rien' comme ça ce sera moche mais les gens pourront le voir)

oublie IE6, ca ne sert à rien, limite toi à IE7/IE8

Ouais, et vu que tout le monde finira par passer à Win7, tout le monde finira par passer à IE8 du même coup, donc tu prends pas trop de risques… À moins qu'un sombre connard réussisse à porter IE6 vers Win7 :]

Merci du conseil, ça me rassure
En fait je bloque, JQuery n'arrive juste pas à traiter les attributs ID correctement sous IE6 -_-
Donc j'ai fait comme ça:
* Il y a une div '#menu' qui est cachée au début. Au démarrage un script l'affiche.
* Si c'est IE6, l'attribut ID de la div est remplacé par 'menusimple', qui a d'autres propriétés CSS (affiche une simple liste ordonnée) et rien n'est configuré en JS, désactivant tout dynamisme.
* Si le browser ne supporte pas le script, la div ne sera pas affichée, mais une deuxième version du menu exactement identique est présentée dans une balise <noscript>. Cette fois il utilise l'ID 'menusimple'.
Bref ça a l'air de marcher (le site est fonctionnel mais pas dynamique du tout sous FF avec noscript), mais je suis moyennement sûr d'être sur la bonne voie, en particulier sur le fait de devoir mettre deux fois le même menu...

Gauche: browser normal, droite: browser de merde:
[URL=http://img709.imageshack.us/i/img066g.png/][IMG]http://img709.imageshack.us/img709/895/img066g.png[/IMG][/URL] [URL=http://img153.imageshack.us/i/img065.png/][IMG]http://img153.imageshack.us/img153/5250/img065.png[/IMG][/URL]

As-tu testé ton site sous Konqueror?

Non (je n'ai pas d'environnement avec ce navigateur de toute façon).

et puis si de toute facon ton site web marche sur IE/FF/Safari/Opera/Chrome, ca ne sert à rien de s'embeter avec d'autres

Si. Un site qui ne marche pas avec Konqueror est un site que je ne visiterai pas.

Brunni (./81) :
Non (je n'ai pas d'environnement avec ce navigateur de toute façon).

http://windows.kde.org/
Pas d'excuses.

De toutes façons, Konqueror est passé à Webkit, non ? Donc si ça passe sous Safari & Chrome, ça a toutes les chances de passer sous K...

Konqueror n’est pas encore sous Webkit mais ça vient.

Kevin Kofler (./83) :
Si. Un site qui ne marche pas avec Konqueror est un site que je ne visiterai pas.

Il n'a qu'à mieux respecter les standards

Konqueror n'est pas passé à WebKit et n'a aucune intention de passer à WebKit.

Et pour Flanker, les sites qui ne marchent pas utilisent justement des extensions non-standard de IE, Mozilla et WebKit, en général avec une détection par navigateur et du code non-standard différent dans chaque cas.

Kevin, je te prédis que dans 2 ans Konqueror proposera le backend Webkit par défaut ^^
À moins que des idiots de conservateurs ne luttent pour conserver KHTML qui est pourtant complètement en retard…

Kevin Kofler (./83) :
Si. Un site qui ne marche pas avec Konqueror est un site que je ne visiterai pas.

Et c'est censé être un argument pour convaincre Brunni de supporter Konqueror, ça ?