Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

gerer une page un peu longue

0 views
Skip to first unread message

J-F Portala

unread,
Mar 21, 2011, 5:44:48 PM3/21/11
to
Bonjour,
j'ai un petit souci quant � la convivialit� d'une page.
C'est une liste d'articles, et au bout de chaque ligne, j'ai un lien
"modifier" permettant d'ouvrir une boite de dialogue pour
modifier les caract�ristiques de l'article.

Au fur et � mesure de l'utilisation, le nombre d'articles a consid�rablement
augment� et la page devient peu sympathique � utiliser.
1. plusieurs secondes pour rafraichir la page.
2. quand on modifie un article � la ligne 600, la boite de dialogue
"modification" s'ouvre, puis recharge la liste apr�s validation, et
l'utilisateur se retrouve
en d�but de liste. Ce pourrait �tre utile de replacer la page sur la ligne
modifi�e.

Pour la partie 1, il me semble que je n'ai pas d'autres solutions que de
d�couper la liste en plusieurs pages.(c'est la construction des liens
"modifier" qui semble prendre du temps)
Pour le 2, j'ai essay� avec des ancres en mettant pour chaque ligne <A
name="id_article"></A> mais je ne vois pas comment rappeler la page
dynamiquement pour r�utiliser l'ancre.<A HREF="mapage.php#1431"></A>
apr�s l'avoir rafraichie.
Quand je valide mon formulaire, je mets � jour la base de donn�es puis je
relance la page qui rafraichit la liste des articles avec #id_article, mais
je reste toujours au d�but de la page.
Je dois faire une grossi�re erreur dans mon appel.

Sinon, de fa�on plus g�n�rale, y a-t-il d'autres m�thodes pour am�liorer
l'ergonomie de ce type de pages?

Merci de vote aide


Jeff

SAM

unread,
Mar 21, 2011, 6:20:37 PM3/21/11
to
Le 21/03/11 22:44, J-F Portala a écrit :

> Je dois faire une grossière erreur dans mon appel.

à mon idée, une ancre n'a pas le droit d'être un nombre
(le name doit commencer par une lettre)

> Sinon, de façon plus générale, y a-t-il d'autres méthodes pour améliorer


> l'ergonomie de ce type de pages?

c'est ce type de pages qui me fait fuir les blogs :-(

> Merci de vote aide

<span id="a_1245">Article 1245</span>


l'appel : mapage.php#a_1245

devrait scroller jusqu'à cet ID


--
Stéphane Moriaux avec/with iMac-intel

Pascal Poncet

unread,
Mar 21, 2011, 6:42:45 PM3/21/11
to
Le 21/03/2011 22:44, J-F Portala a écrit :
> Bonjour,

Bonsoir,

> j'ai un petit souci quant à la convivialité d'une page.


> C'est une liste d'articles, et au bout de chaque ligne, j'ai un lien
> "modifier" permettant d'ouvrir une boite de dialogue pour

> modifier les caractéristiques de l'article.

Gestion classique d'une administration de catalogue, que ce soit
d'articles, de produits ou autre.

> Au fur et à mesure de l'utilisation, le nombre d'articles a considérablement
> augmenté et la page devient peu sympathique à utiliser.

Normal, il faut donc gérer une pagination.

> Pour la partie 1, il me semble que je n'ai pas d'autres solutions que de

> découper la liste en plusieurs pages.(c'est la construction des liens


> "modifier" qui semble prendre du temps)

Le découpage se fait à partir de la requête envoyée à la BDD.
On peut maintenant utiliser la clause LIMIT à peu près partout (je crois
même qu'elle a été intégrée à un standard SQL, peut-être 2003).
Pour la totalisation des résultats, soit envoyer une deuxième requête
allégée et sans clause LIMIT, soit utiliser une fonction spéciale comme
FOUND_ROWS() dans MySQL.

> Pour le 2, j'ai essayé avec des ancres en mettant pour chaque ligne<A


> name="id_article"></A> mais je ne vois pas comment rappeler la page

> dynamiquement pour réutiliser l'ancre.<A HREF="mapage.php#1431"></A>
> après l'avoir rafraichie.

Tu n'es pas obligé de passer par une ancre nommée.
Le plus simple est de passer l'identifiant de l'article dans l'attribut
ID du conteneur de chaque article.
Par exemple, si chaque article est contenu dans une balise DIV, tu le
génère sous la forme <DIV ID="article_12345">.

> Quand je valide mon formulaire, je mets à jour la base de données puis je


> relance la page qui rafraichit la liste des articles avec #id_article, mais

> je reste toujours au début de la page.


> Je dois faire une grossière erreur dans mon appel.

De base, la difficulté vient de la gestion de popup.
Ce n'est pas insurmontable, mais ça complique un peu, ça oblige à
ajouter du scripting client et en plus c'est pas très ergonomique.
Mieux vaudrait afficher le formulaire dans la fenêtre courante, avec un
lien de retour vers la liste plus l'ancre et les données de pagination.
Par exemple, si on se trouvait sur la troisième page et qu'on a modifié
l'article #12345, le lien serait de la forme :
<A HREF="liste_articles.php#article_12345?page=3">Retour liste<A>


--
Cordialement,
Pascal

J-F Portala

unread,
Mar 22, 2011, 12:14:43 PM3/22/11
to
Merci ą vous

Je vais travailler dans ce sens.

Jeff


J-F Portala

unread,
Mar 22, 2011, 12:23:30 PM3/22/11
to
J'ai quand même une petit incompréhension sur l'utilisation de l'ancre (avec
numéro de page ou pas)
Lorsque je valide mon formulatire de modification de l'article 1234, je
recharge une page mapage.php#a_1234?idArticle=1234&page=3 qui va modifier la
table article,
puis rechercher les articles dans la table, et les afficher dynamiquement.

Il faut donc que tout soit créé (toute la page html) pour que l'ancre puisse
aller au bon endroit.
J'ai bon?
Jeff


Olivier Miakinen

unread,
Mar 22, 2011, 12:39:45 PM3/22/11
to
Bonjour,

Le 22/03/2011 17:23, J-F Portala a écrit :
> J'ai quand même une petit incompréhension sur l'utilisation de l'ancre (avec
> numéro de page ou pas)
> Lorsque je valide mon formulatire de modification de l'article 1234, je

> recharge une page mapage.php#a_1234?idArticle=1234&page=3 [...]

Euh... si c'est vraiment l'URL que tu saisis, la page chargée est
"mapage.php", dans laquelle le navigateur va tenter d'atteindre
l'ancre "a_1234?idArticle=1234&page=3" !

Je suppose que tu voulais dire :
"mapage.php?idArticle=1234&page=3#a_1234"

> Il faut donc que tout soit créé (toute la page html) pour que l'ancre puisse
> aller au bon endroit.

Ça, c'est une question pour fciw.navigateurs. En effet, la page
demandée au serveur sera "mapage.php?idArticle=1234&page=3", et c'est
le navigateur qui décide s'il doit attendre ou non que la page soit
chargée en entier avant d'atteindre l'ancre "a_1234". Il me semble
quand même que, pour les navigateurs que j'ai pratiqués, ils allaient
à l'ancre aussitôt que celle-ci était chargée, sans attendre la fin de
la page.

SAM

unread,
Mar 22, 2011, 12:45:25 PM3/22/11
to
Le 22/03/11 17:23, J-F Portala a écrit :

il faut bien que "toute" la page soit créée avant d'être envoyée, non ?
à moins que ça ne se fasse sans recharger la page ? (en JavaScript)
bien que je dubitative avec une url : mapage.php?idArticle=1234&page=3

de toutes façons, ça revient au même, le div d'id a_1234 est là affiché.

> J'ai bon?

il semblerait ;-)


On doit pouvoir avoir :
<a href="#a_1234">aller à art. 1234</a>
qui va sauter directement là sans réellement recharger le fichier — si
toutefois cet article (son div de cet ID) existe.

SAM

unread,
Mar 22, 2011, 12:49:12 PM3/22/11
to
Le 22/03/11 17:39, Olivier Miakinen a écrit :

attendre la fin du chargement de la page ne veut pas dire que tout le
code de la page n'a pas d'abord été créé.
Qu'en est-il exactement à ce sujet ?

Denis Beauregard

unread,
Mar 22, 2011, 1:02:44 PM3/22/11
to
Le Tue, 22 Mar 2011 17:45:25 +0100, SAM
<stephanemor...@wanadoo.fr.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:

>Le 22/03/11 17:23, J-F Portala a écrit :

[...]

>> Il faut donc que tout soit créé (toute la page html) pour que l'ancre puisse
>> aller au bon endroit.
>
>il faut bien que "toute" la page soit créée avant d'être envoyée, non ?
>à moins que ça ne se fasse sans recharger la page ? (en JavaScript)

Je ne vois pas pourquoi il faut que TOUTE la page soit créée. Il me
semble que l'on a parfois une page comme ceci

code PHP
longue requête SQL
autre code PHP

et que l'on peut voir apparaître le début de la page, puis un délai,
puis la suite de la page.

Par ailleurs, en ce qui concerne le problème du fil, il y a aussi un
focus en javascript.


<body onload="monFocus();">

<script type="text/javascript">
function monFocus() {
document.forms["frm"].elements["fff"].focus();
}
</script>

<form name="frm">
<input name="fff" type="text">


Je suppose que c'est adaptable aux autres balises que form.


Denis

Olivier Miakinen

unread,
Mar 22, 2011, 1:08:41 PM3/22/11
to
Le 22/03/2011 17:45, SAM a écrit :
>>
>> Il faut donc que tout soit créé (toute la page html) pour que l'ancre puisse
>> aller au bon endroit.
>
> il faut bien que "toute" la page soit créée avant d'être envoyée, non ?

Sur le serveur, tu veux dire ? Non, il n'y a aucune obligation.
On peut très bien envoyer le début d'une réponse HTTP avant d'avoir
décidé de ce que sera la suite. Tant qu'on ne ferme pas la connexion
TCP, le tuyau reste ouvert pour recevoir de nouvelles données.

De toute manière, quoique je n'aie sans doute pas tout compris de la
question de J-F, il me semble qu'il se place du côté du navigateur
et pas du côté du serveur quand il essaye de comprendre comment ledit
navigateur gère les ancres. De son point de vue il n'y a aucun moyen
de savoir, quand il reçoit le début d'une page, si le serveur « sait »
déjà comment sera la fin.

--
Olivier Miakinen

Olivier Miakinen

unread,
Mar 22, 2011, 1:10:01 PM3/22/11
to
Le 22/03/2011 17:49, SAM a écrit :
>>
>>> Il faut donc que tout soit créé (toute la page html) pour que l'ancre puisse
>>> aller au bon endroit.
>>
>> Ça, c'est une question pour fciw.navigateurs. En effet, la page
>> demandée au serveur sera "mapage.php?idArticle=1234&page=3", et c'est
>> le navigateur qui décide s'il doit attendre ou non que la page soit
>> chargée en entier avant d'atteindre l'ancre "a_1234". Il me semble
>> quand même que, pour les navigateurs que j'ai pratiqués, ils allaient
>> à l'ancre aussitôt que celle-ci était chargée, sans attendre la fin de
>> la page.
>
> attendre la fin du chargement de la page ne veut pas dire que tout le
> code de la page n'a pas d'abord été créé.

Mais ça, le navigateur n'a aucun moyen de s'en rendre compte, et
d'ailleurs il s'en fout. ;-)

SAM

unread,
Mar 22, 2011, 2:02:57 PM3/22/11
to
Le 22/03/11 18:02, Denis Beauregard a écrit :

> Le Tue, 22 Mar 2011 17:45:25 +0100, SAM
> <stephanemor...@wanadoo.fr.invalid> écrivait dans
> fr.comp.infosystemes.www.auteurs:
>
> Par ailleurs, en ce qui concerne le problème du fil, il y a aussi un
> focus en javascript.
>
>
> <body onload="monFocus();">
>
> <script type="text/javascript">
> function monFocus() {
> document.forms["frm"].elements["fff"].focus();
> }
> </script>
>
> <form name="frm">
> <input name="fff" type="text">
>
>
> Je suppose que c'est adaptable aux autres balises que form.

Non !
et ça ne fonctionne que pour les champs (et textarea ?)


function monFocus(ouSsaDonc) { location = '#"+ouSsaDonc; }
window.onload = monFocus('a_1234');

SAM

unread,
Mar 22, 2011, 2:10:32 PM3/22/11
to
Le 22/03/11 18:10, Olivier Miakinen a écrit :

C'est pourtant la question !
(si j'ai bien compris ?)

C'est vrai que s'il sait patienter que le serveur se décide à lui
envoyer qque chose, il peut bien patienter que le serveur ait déchevelé
les requêtes et amalgamé les brins de ficèles réclamés avant de
continuer à lui envoyer des successions de codes durement re-bâties.

Après on s'étonne que ça rame ...

0 new messages