Forum d'entraide PHPFrance

Bonsoir ^^

J'ai enfin finis admin.php. Maintenant, je prépare les pages pour accueillir les news...

Cependant, je sèche sur quelque chose.

Dans ma partie admin, pour chaque news correspond une date et une page. Par exemple pour la news : "Grand brunch !", la page attribué sera index.php et la date 25/05/2010 (cette date correspond à un évènement)

Maintenant retour sur mes pages oueb. Ce que j'aimerais avoir, c'est recevoir les news affilié à ma page en affichant la date de la plus grande à la plus petite.

J'ai fais un petit cheminement mais je bloque un peu.

1/ Afficher la date en Francais => Fait.
2/ Faire une requête SQL pour afficher les news en ordre décroissant par rapport à la date. => Fait.
3/ Vérifier si il y a d'autres news avant et après. Si oui, afficher bouton correspondant à la news suivante ou précédente, si non, ne rien afficher.

C'est la 3eme étape qui me pose problème ! Je n'ai vraiment aucune idée de comment vérifier si il y a des news avant ou après. :s

Je ne demande pas forcément un code fonctionnel, mais juste une piste à suivre.

Merci et bonne soirée.

je sais pas trop mais j'ai un code en fait dans ta requête tu utilise l'option limit en utilisant des variables.
select * from matable limit $limite1,$limite2

ensuite (ou avant en fait)

$limite2=5// 5 affichages par pages
if(!$limite1) $limite1=0 // si $limite1 n'a pas encore été initialisé cela signifie que c'est l'affichage des premières news

Là tu fait ta requête, ensuite tu fais tes liens suivant et précèdent pour cela tu dois créer deux variables

$limitesuivante = $limite1+ $limite2;
$limiteprecedente = $limite1 - $limite2;
 
if($limite1!=0) echo '<a href="tapage.php?limite1=$limiteprecedente">'//lien précédent
if($limitesuivante < $total) //$total est le nombre de news qui existent
{
echo '<a href="tapage.php?limite1=$limitesuivante"}

Bonjour.

J'ai quasiment le même problème, mais avec un fichier XML (voir le forum XML).

Les solutions que j'ai trouvées :
1. La plus simple : en trois passes.
- Tu commences par faire un SELECT pour récupérer ta nouvelle. Tu stockes la date (disons dans $datecourrante)
- Tu fais un SELECT id_new FROM TABLE_NEWS where date_new < $datecourrante ORDER by date_new DESC LIMIT 1,1, qui va te retourner la dernière nouvelle avant la nouvelle affichée. Avec ça, tu peux constituer le lien "précédent".
- Pour la nouvelle suivante, c'est à peu près la même chose...
Inconvénient : trois requêtes, ça peut vite faire lourd (surtout si tu n'utilises pas de cache)

2. En modifiant la table :
- Tu rajoutes les champs prec_new et next_new qui contiendront l'id des nouvelles précédente et suivante.
- A la création d'une nouvelle, tu vas chercher la nouvelle précédente pour mettre son id dans prec_new, et tu fais un UPDATE dessus pour renseigner le champ next_new de la nouvelle précédente (faisable en PHP ou avec des triggers suivant la BDD).
Ce n'est pas très élégant, pas du tout normalisé, ça peut être lourd à gérer (surtout si tu permets de faire des news qui ne paraîtront pas tout de suite, tu peux te retrouver à retravailler toute la table à chaque fois).
Mais c'est un traitement lourd qui ne se fait qu'à la création (éventuellement aussi à la modification) d'une nouvelle. Pour la consultation tu te limites à une seule requête...

3. En pariant sur la régularité des nouvelles :
Si le rythme de parution des nouvelles est à peu près régulier, tu peux faire un SELECT en limitant les dates, histoire d'être à peu près sûr de récupérer les nouvelles précédente et suivante.
Exemple : Une nouvelle par semaine =>
- Tu calcules $datemin = ($datecourante - 1 mois) et $datemax = ($datecourante + 1 mois)
Tu fais un SELECT * FROM TABLE_NEWS where date_new between $datemin AND $datemax.
Ca devrait te retourner un nombre raisonnable de nouvelles, et inclure les nouvelles précédente et suivante.
Problèmes : il faut avoir un rythme de parution à peu près régulier, et ce n'est pas garanti...

Personnellement, je choisirais la dénormalisation, en rajoutant les champs nouvelle_prec et nouvelle_suiv dans ma table...

personnelement je choisirai mon code qui fonctionne parfaitement.

yahoo propose des templates pour ce genre de chose

http://developer.yahoo.com/yui/paginator/

C'est du javascript

Et je n'ai pas compris le problème de la même manière que vous (toi et jojo1000).

- Vous partez sur un problème de pagination : comment gérer l'affichage de X éléments, avec x éléments par page ?
- Je pars sur un problème précédent/suivant : comment sélectionner dans une table les enregistrements qui "entourent" un enregistrement donné ?

C'est du javascript

pas rave c'est la gestion juste de données en javascript,
http://framework.zend.com/manual/en/zend.paginator.html

- Vous partez sur un problème de pagination : comment gérer l'affichage de X éléments, avec x éléments par page ?
- Je pars sur un problème précédent/suivant : comment sélectionner dans une table les enregistrements qui "entourent" un enregistrement donné ?

c'est pareil dans le fond, jojo il est sur 5 elements et toi 1

Si ce que tu cherches est un tuto sur un affichage page par page avec barre de navigation il y a un exemple ici

- Je pars sur un problème précédent/suivant : comment sélectionner dans une table les enregistrements qui "entourent" un enregistrement donné ?

Avec l'id non? il se peut, certes que l'id précédent un enregistrement ne soit pas l'id-1 c'est possible; alors à toi de faire en sorte que les id se suivent.
Ou alors j'ai pas compris.

- Je pars sur un problème précédent/suivant : comment sélectionner dans une table les enregistrements qui "entourent" un enregistrement donné ?

Avec l'id non? il se peut, certes que l'id précédent un enregistrement ne soit pas l'id-1 c'est possible; alors à toi de faire en sorte que les id se suivent.
Ou alors j'ai pas compris.

Je comprend pas trop cette réponse puisqu'il dit qu'il peut faire un tri par date. Ou alors c'est moi qui n'ai pas tout suivi.

A part ça que les id se suivent ou pas tu peux toujours trier par ordre ascendant ou descendant donc les id n'ont pas besoin de se suivre.
Enfin tant que c'est possible autant trier par date, car dans les tables non myISAM les id effacés peuvent être réutilisés si bien qu'on ne peux pas s'y fier pour indiquer un ordre chronologique de rentrée des données.

- Je pars sur un problème précédent/suivant : comment sélectionner dans une table les enregistrements qui "entourent" un enregistrement donné ?

Avec l'id non? il se peut, certes que l'id précédent un enregistrement ne soit pas l'id-1 c'est possible; alors à toi de faire en sorte que les id se suivent.
Ou alors j'ai pas compris.

Je comprend pas trop cette réponse puisqu'il dit qu'il peut faire un tri par date. Ou alors c'est moi qui n'ai pas tout suivi.

Il veut l'enregistrement avant un enregistrement donné (si j'ai bien compris) et celui après un enregistrement donné.
Désolé si je suis pas clair.
EDIT: et si c'est pas ça alors je comprends rien parce que ma première reponse correspondait parfaitement à ce qu'il recherchait d'ailleurs le code fourni est quasiment le même (même nom de variables et tout) que celui que tu donnes. Mon prof l'a piqué éhontemment sur ce site sans donner la source!

Dans l'exemple que je donne, le tri ORDER BY se fait sur les prénoms, pas sur l'ID.

Comme je le dis un ID auto incrémenté correspond à un ordre chronologique d'entrée des données, UNIQUEMENT dans les tables myISAM puisque dans ces tables un ID autoincrémenté effacé ne sera pas réemployé par la suite.
Par contre dans d'autres tables, un ID auto incrémenté effacé peut être réemployé et donc on ne peut pas s'en servir pour déterminer l'ordre d'entrée des données dans la table.
C'est pour cela que je dis que pour faire un tri chronologique, il vaut mieux utiliser les dates quand c'est possible, pour une meilleure portabilité du script et aussi parce que c'est plus logique. Un id n'est qu'un identifiant; il se trouve de par les spécificités de myISAM qu'il indique également l'ordre d'entrée des données, mais c'est une spécificité des tables myISAM.

EDIT : quand je dis "UNIQUEMENT" dans les tables myISAM, c'est une façon de parler pour dire que ce n'est pas une règle absolue que suivent toutes les tables.

Oui mais moi je parlais de l'id uniquement en rapport avec le dernier message JeanJean au départ j'aurai fait un orderby sur la date aussi.

Tu veux dire le dernier message de macgawel... mais lui aussi avait des champs date

Ce que je disais c'était juste pour info, parce que ta réponse était exacte avec par exemple les tables myISAM de mysql mais cela ne fonctionnerait pas pour les tables InnoDB de mysql

Accessoirement, même en ISAM, comment tu fais pour éviter les trous en cas de suppression d'un enregistrement ?

Sans compter qu'il y a toujours des possibilités pour que l'ordre d'écriture ne soit pas l'ordre de lecture, ou pour qu'il y ait des trous.
Par exemple, il peut être possible de créer des nouvelles, et de les publier plus tard. La nouvelle 2 "Bonne année" est créée avant la 3 "Joyeux Noël", mais au niveau classement elle apparaît après.

Par principe, un identifiant est sensé être non signifiant. Du coup, on ne devrait pas se baser dessus pour établire un classement...