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
> 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
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
Je vais travailler dans ce sens.
Jeff
Il faut donc que tout soit créé (toute la page html) pour que l'ancre puisse
aller au bon endroit.
J'ai bon?
Jeff
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.
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.
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 ?
>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
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
Mais ça, le navigateur n'a aucun moyen de s'en rendre compte, et
d'ailleurs il s'en fout. ;-)
Non !
et ça ne fonctionne que pour les champs (et textarea ?)
function monFocus(ouSsaDonc) { location = '#"+ouSsaDonc; }
window.onload = monFocus('a_1234');
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 ...