Règle d'action sur balise

Yes, c’est ce à quoi je pensais au départ mais faut que je me penche sur la pertinence ici, par rapport au reste de l’architecture que je suis en train de construire.

Par contre, pour moi ./mapage.php est une URL relative… Et www.onestation.fr… une URL absolue.
Et avec cette logique là, il n’y a avec cette méthode que le relatif qui fonctionne : CF bêta test.

Et f**k les iFrames :o ^^

Sinon, tu ne fais que des URLs absolues (par rapport au serveur).
Ou tu recalcules les liens par rapport à la source du document. En gros, si le lien est foobar/toto.php
Alors tous les sous liens relatifs (ne commençant pas par un protocole ou un /), peuvent être préfixés par foobar : le truc, c’est qu’il te faudra aussi retravailler les liens des images, des scripts (je crois qu’ils ne sont pas lus par Prototype, j’avais vu ça dans la doc), … d’où l’intérêt d’iframe :stuck_out_tongue:

Ah j’y vois un peu plus clair d’un coup… En gros, si dans la sous-page que je charge il y a des liens relatifs (images, feuilles de style et j’en passe), et que cette sous-page appellée n’est pas dans le même répertoire que la page-mètre appelante, la relativité des liens se fera par rapport à la page mère et non pas à la page fille. Et c’est là le hic !?

Par contre, là où justement l’idée de ne mettre que des URL absolues ne fonctionne pas -> le script que nous avons déployé ne charge pas de page en URL absolue, seules les URL relatives fonctionnent (donc idem à l’intérieur pour les sous-liens, y’a que les images etc… que je pourrais être ammené à charger qui peuvent fonctionner en absolu)

Le hic est bien là. Vu que tu fais ça en php, tu as à priori la connaissance de l’url de base - à préfixer sur chaque lien. Je pense que c’est plus simple que de réécrire toutes les URL via Javascript+Prototype/jQuery. Tu peux par exemple faire une constante IMAGE_DIRECTORY_WEBPATH pointant vers /images, et générer tes liens ainsi :

<img src="<?php echo IMAGE_DIRECTORY_WEBPATH, '/foobar.png'; ?>" />

Tu peux aussi créer une fonction, genre get_image($a) qui fait ça.

Sinon, vu que c’est un div interne, tu n’es peut-être pas forcé de générer la partie feuille de style & compagnie, mais tu auras le problème pour les images.
Et là, pas de soucis non plus, le code que je t’ai filé s’adapte : $(‘dMain’).select(‘img’) te donne toutes les images contenu dans ton bloc, à toi de recalculer le nouveau src à partir de l’ancien, de l’url du script parent, et de l’url de la page chargée.

C’est toi qui voies ce qui est plus simple :stuck_out_tongue: Moi perso, j’aurai fait soit un iframe, soit côté serveur.

J’opterais également pour générer toutes les URL côté serveur. Cela dit, si tu n’appelles que des pages qui sont au même niveau que la page appelante, au final tu n’as pas ce soucis :neutre:

L’iFrame me pose juste un soucis, c’est que c’est un cadre que tu peux ouvrir sans le reste de la structure. A moins que je puisse faire comme avec Ajax, faire passer une variable entre l’une et l’autre des parties de ma page, et que si l’une s’ouvre sans l’autre, on charge l’ensemble. Faut que je creuse :slight_smile:
Edité le 07/08/2012 à 10:49

Tes pages peuvent aussi être appelée en dehors de la structure :slight_smile:

oui, justement :wink:
Par contre avec Ajax, je colle une variable et si à l’ouverture de la page, la variable est absente, il charge la structure complète. Si elle est là, c’est qu’on est bien dans la page contenante, et on ne charge que le corps central. Et ça, je n’arrive pas à le reproduire sous iframe (transmettre une variable au sous-document pour l’exploiter à cette fin)

J’ai fait un essai en iFrame : onestation.fr… - en soi c’est bien pour la navigation, mais moins sympa pour le dialogue contenant/contenu

Je ne sais pas non plus comment dire à la page contenante qu’on scrolle la page contenue (la propriété onscroll sur l’iFrame ne semble pas fonctionner :confused: )

Sur le body de la frame, peut-être. Tu peux ajouter l’événement, et faire référence à la frame parente (genre : window.parent pour accéder à la frame parente). ça n’a pas fonctionné sur mon test, mais je suis quasiment sûr que c’est possible, même si ça implique de modifier l’événement passé au onscroll.

depuis 10h que je m’y arrache les cheveux !

Ce message n’était pas conforme aux règles d’utilisation du nouveau forum :

?

Sur cette histoire de window.parent, et sur cette histoire de passage de variable.

Concernant le scroll, effectivement en le positionnant dans la balise body de la page contenue dans la frame, ça fonctionne. Par contre, j’ai beau mettre ma fonction dans la page contenante et l’appeler avec window.parent.updateLogo(); rien ne se passe. Firebug ne renvoie aucune erreur… Je creuse !

Sinon, question subsidiaire, comment puis-je m’assurer que ma page soit bien ouverte dans la frame, et que si elle est ouverte en standalone, je puisse charger un contenant avant ?
En ajax, je passais par une variable GET, que je ne peux pas faire fonctionner ici
Edité le 07/08/2012 à 15:32

Tu peux vérifier que window.parent = l’url de la page parente :slight_smile:

J’ai même fait un truc plus générique, chargé dans body onload :

isAlone=function() {
	if(window.parent.location == window.location) { alert("erreur, il faut charger les headers"); }
	else { alert("tout va bien mon capitaine !"); }
}

Et bien on y arrive ! :slight_smile:

Au final, j’ai opté pour l’iFrame et les ancres pour naviguer (le comble :o )
Résultat : onestation.fr…

Dommage qu’ils le retirent d’HTML5 :stuck_out_tongue: (dit-il d’un air innocent)

… :riva:

Non, mais ce n’est pas pour aujourd’hui hein, et si retrait il y a, il y a encore pas mal de sites qui s’en servent;
ton site sera depuis longtemps refait quand ça disparaîtra.

J’imagine bien :slight_smile:
Mais ça me fait rire ce petit air innocent, tu suggère l’iFrame alors que je préférais Ajax, et maintenant tu indiques que ça va devenir has-been :o

J’ai aucune préférence pour l’un ou l’autre hein :slight_smile:

iframe apporte son lot de problèmes, pour la navigation, pour une catégorie limitée de gens,
ajax apporte son lot de problèmes d’un point de vue du développeur (pour la réécriture des liens), mais aussi d’un point de vue utilisateur (gestion de l’historique, la navigation, etc).

Ensuite, tu me dis que c’est trop compliqué (etc) de mettre un lien absolu pour ton application, soit. Dans ce cas, soit tu fais un pari de n’avoir que des liens de même niveau, soit tu réécris tout, soit tu passes par iframe qui fait ça “nativement”.

C’est plus un choix en fonction des inconvénients & avantages qu’idéologique à ce niveau :slight_smile:

Je conçoit bien tout ça, mais au départ, j’expliquais juste que les liens absolus ne fonctionnaient pas avec la méthode Ajax, seuls les liens relatifs étaient lus et affichés dans la page, peu importe à quel niveau ils se trouvaient. Il me fallait donc tout mettre en relatif. 'fin là n’est plus le soucis :wink: