Discussion :

[zanteskuken]

Bonjour,

J'effectue un d�veloppement sous symfony 2 utilisant le routage de celui-ci et twig.

J'ai int�gr� des appels Ajax pour �viter des chargements de page compl�tes. Comme tout le monde je souhaite n�anmoins qu'un url corresponde � une donn�e. J'utilise donc PushState de la biblioth�que History.js

Sc�nario.
1 - Je suis sur ma page accueil. J'effectue une recherche.
2 - Je tombe sur une nouvelle page affichant un ensemble r�sultat.
3 - Je clic sur suivant, pour afficher les r�sultats suivants, sans recharger la page, juste mettre � jour le bout d'interface n�cessaire. J'utilise donc un appel Ajax.
etc.

Arborescence

Sans Hisotry :
1 - Accueil.
2 - resultat/
3 - resultat/
etc...

Avec :

1 - Accueil/
2 - resultat/page-1
3 - resultat/page-2
etc..

Si je m�arr�te l�, la navigation via le navigateur est correct.

On pense tout est g�nial. Hors je me confronte � un probl�me allant plus loin.

4 - Je demande le d�tail d'une recherche, qui est un appel "normal" url.

1 - Accueil/
2 - resultat/page-1
3 - resultat/page-2
4 - details/2

Je clic maintenant sur "pr�c�dent", retrouvant cet �tat :
1 - Accueil/
2 - resultat/page-1
3 - resultat/page-2

je re-clic sur pr�c�dent...

1 - Accueil/
2 - resultat/page-1
3 - resultat/page-2

"bug"

De nouveau sur pr�c�dent

1 - Accueil/
2 - resultat/page-1

"ok"

J'ai un probl�me de conception selon moi et je ne vois pas comment le r�soudre.

Voici le code JS de la page "resultat".

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
 
<script type="text/javascript">
$(document).ready(function()
 
//Première visite, on effectue un historique
//"div_p_result" est le conteneur changeant à chaque appel Ajax
// vpageStart et le numéro de la page courante (en effet, l'utilisateur peut très bien faire un copier coller d'une url et accéder directement pour la //première fois de cette interface à la page N
 
var stateStartObj = { data: $('.div_p_result').html() };
History.pushState(stateStartObj, window.document.title, "page-"+vpageStart);
 
History.Adapter.bind(window, 'statechange', function()
	{
		var State = History.getState();
 
	        History.log(State.data, State.title, State.url);
 
                // On met à jour le conteneur
		$('.div_p_result').empty();
		$('.div_p_result').append(State.data.data);
	});
 
$('#test').click(function()
			{
                                // J'avoue, il y a surement mieux comme méthode de calcul de paramètre d'url...
				loc='{{  app.session.locale}}';
				//récupére l'url
				var lien = document.location.href;
				// décompte l'url
				var stlien = lien.split("/");
				//Nb items
				lg = stlien.length;
				//récupére la donnée continent (tableau commence à 0 )
				var name = stlien[lg-2];
				//récupére la donnée page
				var vpage = stlien[lg-1];
				//récupére la valeur page
				vpage = Number(vpage.split("-")[1]);
 
 
				$.get(Routing.generate('lookForByContinentPage', {'name':name,'page':vpage, '_locale':loc}), 
						function(data){
      							var stateObj = { data: data };
							var title = window.document.title;
							var title = title.split("|")[0];
							History.pushState(stateObj, title+"| page-"+vpage, "page-"+vpage);
						});
			}
		);
 
</script>
 
 
<div class="button_look">
	<input type="button" id="test" class="input_lookfor" value="go">
</div>
 
	<div class="div_p_result">
			{% for result in listResult %}
                              etc ...

Comme vous le voyez, lors du premier appel de la page "resultat", on effectue un pushState pour "m�moriser" le contenu de conteneur (Sans cela, lors d'un forward jusque la "page-1" (dans l'exemple), on aurai le "conteneur" vide.
Ensuite on effectue un PushState � la suite de chaque appel Ajax.
Ensuite on passe � une autre page, exemple "d�tails d'une recherche" (appel url), le navigateur reprend la main de l'historique.

Hors, lorsque de l'on revient, "bouton pr�c�dent", on recharge la page "resultat" et donc on re-effectue un pushState, ce qui donne ce sc�nario montr� plus haut. Ce qui n'est pas souhait� du tout comme vous l'avez compris.

Je n'arrive pas � voir comment je peut faire pour pallier ceci, qui est au bout du compte, une alternance Manipulation Historique ajax/js et Historique classique.

Si vous auriez une vision ?

Et pour compl�ter ceci, est-ce que History.js suffit, ou dois-je impl�menter autre chose (angular/backbonne , que je n'utilise, ayant d�j� le syst�me de routage symfony et twig, pensant ne m'�tre utile..).


Merci de m'avoir d�j� lu.

[Sylvercis]

Salut,

je n'ai pas encore eu l'occasion de me pencher sur la gestion de l'historique du navigateur mais pour ton probl�me ce que je ferai c'est simplement a chaque page, m�moriser le nombre d'�lement dans l'historique.
Comme �a par exemple:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
sessionStorage.historyLength = window.history.length;

et avant d'ajouter un nouvel element dans l'historique

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
if (!(sessionStorage.historyLength < window.history.length)) {
   History.pushState(stateStartObj, window.document.title, "page-"+vpageStart);
   // etc..
}
sessionStorage.historyLength = window.history.length;

[zanteskuken]

Salut,

Merci pour cette r�ponse.

J'ai regard� alors � quoi correspondait sessionStorage, ne connaissant pas. C'est int�ressant et c'est vrai que dans ce cas il faut utilis� "sessionStorage" et non "localStorage".

Je pense bien comprendre que cela permet de stocker des donn�es utiles, par exemple � la navigation dans ce cas.
Principe de cl�-valeur. sessionStorage.setItem('cl�', 'valeur');

Valable pendant la dur�e d�activit� de la fen�tre ouverte du navigateur. Chaque �l�ment enregistr� par sessionStorage �tant ind�pendante de chaque fen�tre ouverte et effac� � la fermeture de la fen�tre.

Avant de tout impl�menter ou faire plein de test j'ai test� dans mon esprit et me pose ces questions � termes.

- le d�veloppeur va cr�er ses propres <cl�-valeur> pour sont site

A quel moment aura-t-on une atomicit� de <cl�-valeur>, dans le sens, un autre d�veloppeur aura cr�er le m�me attribut <cl�-valeur>, qui peut g�n�rer un conflit.

C'est � dire, l'utilisateur va ouvre un onglet et va sur le site domain1.com qui utilise la cl� "historyLength" pour sessionStorage.
L'utilisateur va ensuite sur mon site domain2.com, avec le m�me onglet, et j'utilise aussi la cl� "historyLength"

Il y a t-il conflit ?

Juste confirmation, car si ma traduction en anglais est bonne, j'ai lu que chaque site (domain) � son propre storageSession (donc pas de conflit) "Each site has its own separate storage area."

Tu as rencontr� des contraintes � cette utilisation sinon ?

Comme tu dis "� chaque page" mettre � jour le nombre d'historique (j'ai mis du temps � saisir, c'est d�j� une belle contrainte. La cata s'il y a un oublie).
Tu as utilis� cette notion de mise � jour au niveau du chargement du "menu", de ton site peut-�tre ? (c'est un bon moyen je trouve, �tant charg� pour chaque page, pas de redondance de code)

Merci c'est int�ressant en tout cas. J'essaye de comprendre les limites/contraintes avant tout.

[Sylvercis]

Non, avec sessionStorage, pas de conflit possible avec d'autres domaines. On peut consid�rer �a comme une variable globale qui reste m�me si on change de page sur le site.
Par contre je ne sais pas si sa reste en m�moire d'un onglet a l'autre (en ouvrant une page du site vers un nouvel onglet par exemple). Je ne pense pas, � v�rifier.
Pour les stockage longue dur�e il y a localStorage.

Sinon comme je te l'ai dit je n'ai pas encore commenc� a g�rer ces probl�mes d'historique donc je ne peut pas te dire comment je ferai pour mon site.

Pour ton site, je pense qu'il faut que tu remette � jour la cl� "historyLength" (exemple de nom) juste apr�s chaque "pushState" de la fa�on indiqu� dans mon exemple pr�c�dent.
Mettre a jour a chaque page �a ne fonctionnera surement pas.
Si "historyLength" est inexact sur les pages standards �a ne posera aucun probl�me.
Ton bug se produit au retour sur une page contenant un "pushState" (et donc une mise a jour de "historyLength") donc automatiquement, comme tu revient, c'est que "historyLength" aura forcement �t� mis a jour pour te permettre d��viter ce bug.

J'ai juste un petit doute qui remet tout en cause. Qu'est ce qui se passera si tu fait un "pushState", tu avance d'une page puis tu ferme le navigateur.
2 jours plus tard, tu r'ouvre et tu d�cide de faire un page pr�c�dent.
Est que le sessionStorage aura gard� la variable ? non.
Du coup le bug r�appara�tra a cette occasion.

Donc a priori il vaut mieux utiliser localStorage pour stocker "historyLength".

[zanteskuken]

J'ai test� voir, je suis parti directement avec LocalStorage. Je n'avais pas pens� � cette notion de fermer le navigateur et reprendre la navigation plus tard. Je n'utilise jamais cela et je ne crois m�me pas que je connaissais (j'ai cliqu� sur Safari "rouvrir sur la derni�re fen�tre ayant �t� ferm�"), si c'est bien ce que tu disais ? en effet on peut refaire des "boutons pr�c�dents" et je ne vois pas trop l�int�r�t d'avoir de ce type de navigation, mais d'accord, �a existe.

J'ai impl�ment� alors et �a fait de la tambouille :s

Le code, lors du chargement de la page (effectu� lors du chargement complet de la page donc)

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
 
$(document).ready(function()
{
 
//localstorage est-il supporté par le navigateur 
	if(typeof localStorage!='undefined') 
		{
		//la varialbe historyLength existe t-elle
		if (localStorage.getItem("historyLength") === null) 
			{
				localStorage.setItem('historyLength', window.history.length);
                                .....
				History.pushState(stateStartObj, window.document.title, "page-"+vpageStart);
		}else
			{
				if(!(localStorage.historyLength < window.history.length)) 
				{
                                        .........
					History.pushState(stateStartObj, window.document.title, "page-"+vpageStart);
				}
				localStorage.historyLength = window.history.length;
                        }
           }else{
                 // Faire autre chose
                alert("localstorage pas supporté");
	   }
.......
 }

1 - la condition if(!(localStorage.historyLength < window.history.length)) ne fonctionne pas comme attendu.
peut s'�crire aussi if(localStorage.historyLength >= window.history.length)

Vu comme cela, je me dis que cette condition ne sera pas v�rifi�

Ex de navigation :
- Page_accueil
- Resultat_recherche/page1 (on cr�� "historyLength" , n'existant pas) = pushState : historyLength=history.length=2
- Resultat_recherche/page2 (pushSate, via Ajax) : historyLength=2 ,history.length=3
- Page_Autre (historisque navigateur) historyLength=2 ,history.length=4
- Page_Accueil (historique navigateur) historyLength=2 ,history.length=5
- Resultat_recherche/page1 (nouvelle recherche) (pas de pushState, la condition historyLength>=history.length invalide) historyLength= 2 history.length=5 (avant condition)(bug)

Un exemple parmi d'autre malheureusement

2 - LocalStorage va partager sa valeur "historyLength" entre les diff�rents onglets ouvert (comme tu le disais), ce qui fausse d'avantage toute la navigation avec ce principe. D'autant plus lors d'une nouvelle session/navigation par exemple.


Bien entendu, sessionStorage r�soudra le 2eme probl�me, quand � la notion de "reouverture" de navigateur...

�a ce trouve il ne manque pas grand chose, pour l'instant les pinceaux sont emm�l�s.