Affichage d'une page Web dans un DIV

Bonsoir,

Je suis développeur VB.NET mais assez novice en développement web ... il faut bien se lancer un jour Je fais tout par bloc-notes.
Je veux qu'en cliquant sur un élément de la barre de menus, que la page s'affiche dans un DIV situé en dessous, sans actualiser complètement la page.
Comment-dois je m'y prendre ? AJAX, Javascript, iFrame, include en PHP .. ?
Je cherche une solution "simple et moderne" ... si cela existe

Je sais que la question a déjà été posée mais c'est parfois un peu confus

Merci

Le mieux reste l'include car cela marche pour tout le monde (côté serveur), sinon tu peux utiliser l'Ajax (et donc javascript 90% du temps) mais ce n'est pas référençable et cela ne fonctionnera pas chez ceux qui ont désactivé javascript.

L'iframe n'est vraiment pas conseillée pour des questions d'accessibilité et d'ergonomie.

Skoua a écrit :
Le mieux reste l'include car cela marche pour tout le monde (côté serveur), sinon tu peux utiliser l'Ajax (et donc javascript 90% du temps) mais ce n'est pas référençable et cela ne fonctionnera pas chez ceux qui ont désactivé javascript.

L'iframe n'est vraiment pas conseillée pour des questions d'accessibilité et d'ergonomie.

Merci pour cette réponse rapide
Comment utilises-tu le include dans mon exemple : cliquer sur un lien et envoyer la page dans un DIV précis ?

je ne pense pas que l'include soit la solution si tu es certain de vouloir:

WIF a écrit :
[...]sans actualiser complètement la page.

L'include nécessite un traitement du serveur et donc page reload.

Le mieux je pense reste donc Ajax.

webdesign-fr a écrit :
je ne pense pas que l'include soit la solution si tu es certain de vouloir:

L'include nécessite un traitement du serveur et donc page reload.

Le mieux je pense reste donc Ajax.

Oui tout à fait c'est que je veux
Par contre je ne pense pas m'avancer en disant que ce sera plus compliqué
Peux-tu m'expliquer comment faire ou me renvoyer sur un tuto l'expliquant

Bonjour,

L'utilisation d'AJAX n'implique pas la non utilisation de système d'inclusion de fichiers.
D'abord passer par l'include puis enrichir l'expérience avec AJAX (et pas avant).

Concernant la mise en oeuvre technique de la chose (AJAX), il faut un minimum de connaissance en développement front-end (Javascript / DOM HTML) et oui ça ça requière du boulot. Pas de tuto spécialement à conseiller mais faire des recherches sur AJAX, XmlHttpRequest et compagnie peuvent t'apporter des débuts de réponse.

N'hésite pas à poster en cas d'incompréhension .

Bonne continuation.
Romain

Bonjour,

a écrit :
Je veux qu'en cliquant sur un élément de la barre de menus, que la page s'affiche dans un DIV situé en dessous, sans actualiser complètement la page.
Comment-dois je m'y prendre ? AJAX, Javascript, iFrame, include en PHP .. ?
Je cherche une solution "simple et moderne" ... si cela existe rolleyes

Sauf cas d'application en ligne il est peu probable que l'actualisation complète de la page pose un problème quelconque.

La solution simple et moderne est d'utiliser HTML avec éventuellement des includes pour les élément récurrents de la page qui se chargera comme elle doit l'être à chaque demande.

Une page est une page

Salut,

au sujet d'include (et pour les autres sujets) ne pas hésiter à faire une recherche dans la section Apprendre.

yodaswii a écrit :
Bonjour,

L'utilisation d'AJAX n'implique pas la non utilisation de système d'inclusion de fichiers.
D'abord passer par l'include puis enrichir l'expérience avec AJAX (et pas avant).

Concernant la mise en oeuvre technique de la chose (AJAX), il faut un minimum de connaissance en développement front-end (Javascript / DOM HTML) et oui ça ça requière du boulot. Pas de tuto spécialement à conseiller mais faire des recherches sur AJAX, XmlHttpRequest et compagnie peuvent t'apporter des débuts de réponse.

N'hésite pas à poster en cas d'incompréhension .

Bonne continuation.
Romain

Je pense avoir trouvé mais il faut encore que je continue à tester ce soir
Oui c'est sûr que tout s'apprend. Justement avec un exemple concret, j'aurai pu analysé pour apprendre. Pour le moment je n'ai trop le temps de prendre la lecture d'un gros chapitre tel que Javascript/AJAX ... j'en ai déjà de tous les côtés

Igor a écrit :
Sauf cas d'application en ligne il est peu probable que l'actualisation complète de la page pose un problème quelconque.

La solution simple et moderne est d'utiliser HTML avec éventuellement des includes pour les élément récurrents de la page qui se chargera comme elle doit l'être à chaque demande.

Une page est une page

C'est un choix tout simplement comme certains préfèreraient mettre du noir plutôt que de bleu De plus, depuis longtemps, il a toujours été dit que c'était un gros point noir que de devoir recharger complètement la page en développement web (pas très esthérique et utilisation de la bande passante) alors qu'en développement "standard", il était possible aisément de mettre à jour un composant d'une form précise. Les technologies permettant désormais des "actualisations partielles" même si elles doivent encore être améliorées donc autant les utiliser pour se rapprocher le développement webform du développement winform

WIF a écrit :
C'est un choix tout simplement comme certains préfèreraient mettre du noir plutôt que de bleu

Ha ha, bien tenté, mais non.

WIF a écrit :
De plus, depuis longtemps, il a toujours été dit que c'était un gros point noir que de devoir recharger complètement la page en développement web (pas très esthérique et utilisation de la bande passante)

Alors bon:
1. Ça a été dit par qui? Avec quels arguments précis (genre une analyse ergonomique avec tests utilisateurs)?
2. Utilisation de la bande passante: négligeable.
3. Esthétique: aucune différence esthétique une fois la page ou le contenu chargé. Le fait qu'il y ait un chargement n'est pas un problème esthétique, le mot est mal choisi.

WIF a écrit :
Les technologies permettant désormais des "actualisations partielles"

Certes. La question est: à quel prix? Quelques pistes:
- accessibilité;
- indexabilité (cf. référencement);
- ergonomie (quelles perceptions dans un cas et dans l'autre, quelles conséquences?);
- impact sur la méthodologie de développement et la maintenabilité.

Je ne dis pas que la solution Ajax (puisqu'il s'agit de cela) est à écarter. Il me semble juste qu'on y plonge allègrement sans avoir ce qu'elle implique.

Florent V. a écrit :

Ha ha, bien tenté, mais non.

Ben si

Florent V. a écrit :
Alors bon:
1. Ça a été dit par qui? Avec quels arguments précis (genre une analyse ergonomique avec tests utilisateurs)?
2. Utilisation de la bande passante: négligeable.
3. Esthétique: aucune différence esthétique une fois la page ou le contenu chargé. Le fait qu'il y ait un chargement n'est pas un problème esthétique, le mot est mal choisi.

Depuis le temps que je fais de l'informatique, j'ai entendu de nombreuses personnes le dire par exemple des personnes de chez Microsoft aux TechDays et DevDays ou encore de l'équipe Wygwam...
Il s'agit bien d'esthétique car cela évite le "scintillement" de la page et donc amène un confort visuel. D'autant que certaines personnes sont encore en 512K, donc si on peut limiter les échanges et l'actualisation totale de la page, ça ne me parait pas plus mal ...

Florent V. a écrit :
Certes. La question est: à quel prix? Quelques pistes:
- accessibilité;
- indexabilité (cf. référencement);
- ergonomie (quelles perceptions dans un cas et dans l'autre, quelles conséquences?);
- impact sur la méthodologie de développement et la maintenabilité.

Oui c'est sûr que tout choix fait suite à une réflexion. En ce qui me concerne, les éléments qui m'ont amenés à cette décision sont : actualisation partielle, utilisation/apprentissage de Javascript/AJAX, je sais que AJAX pose problème pour le référencement mais dans mon cas ce n'est pas gênant ...

Le site n'étant pas très lourd et son organisation propre, la maintenance ne posera pas de problème

WIF a écrit :
Ben si

Ce que je voulais dire, c'est que l'analogie n'est pas satisfaisante. Tu dis toi-même que «tout choix fait suite à une réflexion», et tu précises ensuite les critères de cette réflexion. Tu admettras que, rhétoriquement et logiquement, c'est très loin de «C'est un choix tout simplement comme certains préfèreraient mettre du noir plutôt que de bleu».

WIF a écrit :
Depuis le temps que je fais de l'informatique, j'ai entendu de nombreuses personnes le dire par exemple des personnes de chez Microsoft aux TechDays et DevDays ou encore de l'équipe Wygwam...

Il y a pas mal de choses dites dans ces contextes sur la réactivité des applications desktop. Pour le Web, la situation est sensiblement différente. Pour une application desktop, l'utilisateur attend soit une réaction immédiate, soit l'affichage immédiat d'un signal comme quoi son instruction est prise en compte (un message et une barre de progression, par exemple).

Sur le Web, il y a peu encore le modèle était: je lance une instruction, ça charge une nouvelle page/la page se recharge. Ce comportement est encore largement attendu par l'utilisateur. Le domaine dans lequel on peut facilement s'en abstraire, c'est dans le cas des applications web qui imitent fortement des équivalents desktop. Gmail, une des premières applications web qui a marqué la transition vers l'applicatif web, a impressionné par le fait qu'on pouvait faire certaines actions instantanément (ce n'était pas le cas, mais l'action était affichée comme faite directement, dès le moment où la requête Ajax partait). Dans le cas de Gmail, ça a séduit. Dans le cas d'un site «classique» orienté contenus, il reste à voir si ça va séduire, ou bien perturber, ou un peu des deux.

Les publications intéressantes sur ce sujet sont celles sur l'ergonomie web et celles sur les performances client (cf. performance.survol.fr par exemple).

WIF a écrit :
Il s'agit bien d'esthétique car cela évite le "scintillement" de la page et donc amène un confort visuel.

Trois choses ici:
1. Le confort «visuel» et l'esthétique, ce sont deux choses différentes. Désolé d'être tatillon, c'est mon éducation littéraire qui ressort.
2. Le scintillement en question est loin d'être un phénomène universel. Dans de nombreux navigateurs modernes, il n'a pas lieu entre deux pages d'un même site: le navigateur attend d'avoir un rendu visuel de la nouvelle page avant de remplacer le visuel de l'autre page (visuel qui peut être inactif -- je pense aux liens et actions JavaScript) sur la fin du temps de chargement. On voit là un mécanisme assez intelligent d'optimisation des performances perçues par l'utilisateur. Je crois bien que tous les navigateurs récents font ça, IE8 compris. À voir pour IE7.
3. Dans le cas où un navigateur fait apparaitre brièvement une page blanche, ce comportement n'est pas inhabituel pour le navigateur (il ne gène réellement que le développeur sous Firefox/Opera/Safari/IE8 qui teste ponctuellement sous IE6 et se dit «mon dieu, c'est affreux ce scintillement»). Il est je pense important de dédramatiser ce «souci», du moins pour un cas d'usage qui représente le passage d'un écran A à un écran B (et pas une altération subtile de l'écran A).

Un récapitulatif rapide sur les défauts techniques d'une navigation Ajax (comparée à une navigation HTML classique):
- Le fait de ne pas changer l'adresse dans l'URL signifie que l'on ne peut pas placer de marque-page pour une page donnée. Ce problème se règle partiellement avec un système d'ancres dans l'URL.
- Si pas conçu -- et testé -- sur un modèle d'optimisation Ajax en surcouche, le site sera inutilisable sans JavaScript et donc pour une partie des utilisateurs, et par ailleurs pas visible des moteurs de recherche.
- À moins d'utiliser ARIA, les modifications de zones de la page par JavaScript ne sont pas notifiées à un utilisateur de lecteur d'écran. Si le site ou application doit être accessible, il faut utiliser ARIA.

Les raisons que tu exposes sont intéressantes et l'objectif de formation est louable. Quitte à se former, je conseillerais donc de se former aux bonnes pratiques et d'implémenter la navigation Ajax comme une surcouche d'une navigation traditionnelle. Et pourquoi pas d'implémenter un système d'URL virtuelles (http://example.org/#rubrique1, http://example.org/#rubrique5-page2), pour une solution plus complète. Mais ça peut faire beaucoup d'un seul coup.

Merci pour ces infos
Pour le moment je ne suis pas penché sur l'URL Rewriting.
En revanche, je suis justement en train de regarder la surcouche AJAX.
Le code que j'utilise est le suivant (il n'est pas de moi bien que je le comprenne) :

function envoiRequete(url,id)
{
	var xhr_object = null;
	var position = id;
	if(window.XMLHttpRequest) xhr_object = new XMLHttpRequest();
	else
	if (window.ActiveXObject) xhr_object = new ActiveXObject("Microsoft.XMLHTTP");
	// On ouvre la requete vers la page désirée
	xhr_object.open("GET", url, true);
	xhr_object.onreadystatechange = function(){
		if ( xhr_object.readyState == 4 )
		{
			// j'affiche dans la DIV spécifiée le contenu retourné par le fichier
			document.getElementById(position).innerHTML = xhr_object.responseText;
		}
	}
	// dans le cas du get
	xhr_object.send(null);
}

On y fait appel de la manière suivante :

<a onclick="envoiRequete('./page.php','nom_div');" href="#">Accueil</a>

J'ai lu que pour palier au problème de référencement, il fallait laisser le HREF.
J'ai donc remplacé # par page.php ; la page s'affiche bien mais forcément sans mise en forme.
Je continue à lire et à apprendre ...