ugrás a tartalomhoz

Listázó oldal url felépítés

szabo.b.gabor · 2015. Nov. 5. (Cs), 07.09
Sziasztok!

Egy viszonylag egyszerű kérdésem volna. Listázok cikkeket egy oldalon, van sok, kell a lapozás.

a cikkeket időrendben szeretném megjeleníteni, mi az optimálisabb?

A
ha azt mondom az url-ben, hogy page=1, page=2.. stb. és ilyenkor a page 1, 2, stb oldalak tartalma változik ahogy jelennek meg az újabb cikkek (ez az egy bajom ezzel a megközelítéssel).

B
azt mondom, hogy adott listázó url-en mindig ugyanazok a cikkek jelenjenek meg. és azt mondom, hogy maxid=1323, maxid=1318, stb.. ha nincs ez a paraméter, akkor nyilván a legfrissebbek jönnek.

szerintem A-nak is, B-nek is vannak előnyei, talán az A jobb (könnyebben érthető, hogy miről van szó), de van-e olyan változat ami olyasmi, mint a B, de mégis jobb annál? :D
 
1

Dátum

Poetro · 2015. Nov. 5. (Cs), 09.39
A cikkeknek ugye van dátuma? Mert ha igen, akkor a kezdő dátum lehetne a lapozó változója. Ekkor ugye minden oldal dinamikus, de minden oldal elérési útja is az.
2

én is gondolkodtam a dátumon,

szabo.b.gabor · 2015. Nov. 5. (Cs), 10.31
én is gondolkodtam a dátumon, de mi van, ha egy napon mondjuk van 5 cikk és az egyik oldalon van ebből 3, a másikon meg kettő. nyilván lehet a dátum felbontását finomítani, de akkor már az id, az egy konkrétabb dolog.
8

id

Poetro · 2015. Nov. 5. (Cs), 13.10
Az id miért is konkrétabb? Mivel az ID egy véletlenszerű szám, nem szabad rá építeni listázáskor. Azaz lehet, hogy egy elem ID-je 123, de attól még később jelent meg mint az 134.
11

azért az id az nem

szabo.b.gabor · 2015. Nov. 5. (Cs), 14.05
azért az id az nem véletlenszerű.. nodemindegy, értem mire gondolsz
3

inverz page

szabo.b.gabor · 2015. Nov. 5. (Cs), 10.37
ha fordítva számoznám, akkor az majdnem jó (0 - legutolsó, 125 - első) csak ugye ha nem egész többszöröse az oldalon felsoroltak darabszáma, akkor máris elcsúszik a dolog, meg azért furcsa is olvasni :D
4

Limit, offset

smokey · 2015. Nov. 5. (Cs), 10.45
Nekem elég sokszor bevált már, hogy egy limit és egy offset paraméter segítségével listázok. Ezzel akár könnyedén tudod felhasználó által definiálhatóvá tenni az egy oldalon megjelenő találatokat, könnyen tudod felépíteni az SQL lekérdezésed is.

Példa itt

Ha ezt használod, akkor szükséged lehet az összes találat számosságára is, hogy az oldalak számát meg tudd határozni. Ezt a metodikát egyébként "endless scrolling"-ra is szoktam használni.
7

ez eddig tiszta, csak az a

szabo.b.gabor · 2015. Nov. 5. (Cs), 11.15
ez eddig tiszta, csak az a kérdés, hogy elérhető-e valami felhasználók számára is érthető módon, hogy az url-ek értelmezhetőek is legyenek, és adott url alatt a tartalom ne változzon (új elemek létrejötte ne csúsztassa lejjebb a listában az elemeket)
10

Megoldható

smokey · 2015. Nov. 5. (Cs), 14.02
Ha az elemek száma egy adott oldalon (egy adott URL alatt) változik, mert bővül a cikkek száma, és a legfrissebbek vannak előrébb, akkor ez a módszer úgy tudja megállni a helyét, hogy egy extra paraméterrel, pl. egy dátummal kiegészíted az URL-t. Ez a dátum szintén bekerülhet az SQL lekérdezésbe, így tudathatod az alkalmazással, hogy az adott URL alatti lista milyen időpontra vonatkozik.

Pl.:
SELECT * FROM cikkek WHERE created_at <= :date ORDER BY created_at DESC LIMIT 40, 10
A lekérdezés tehát a :date paraméterben szereplő dátumnál nem későbbi cikkeket listázza. Ezzel a módszerrel a :date-nél később íródott cikkeket nem listázódnak.

Ha a későbbi cikkeket is szeretnénk listázni, és szeretnénk azt is, hogy adott limit és offset paraméterek mellet a dátummal ellátott kérés ugyanazt a listát szolgáltassa, akkor itt még mindig lehetőség van egy összetettebb lekérdezés létrehozására, pl. UNION segítségével.
12

ez így egész életképes. főleg

szabo.b.gabor · 2015. Nov. 5. (Cs), 14.18
ez így egész életképes. főleg annak tükrében, hogy ha több oldalra is akarok linkelni (2-10) - és persze akarok, akkor limit, offset-en kívül nem nagyon van egyszerű értelmes módszer a linkek egyszerű elkészítésére.
13

seo

szabo.b.gabor · 2015. Nov. 5. (Cs), 14.32
a 'nulladik' oldalon (ami bejön paraméterek nélkül) pedig rakhatok egy canonical url meta taget, amiben benne van a created_at timestamp. ez így jó lehet?

sőt akár minden oldalra oda lehetne tenni ezt a canonical izét, mintha az adott oldal 0. oldal lenne, így az adott időponttól a lapozó linkek kirakása triviális és a dupla tartalom miatt sincs probléma.. talán :)
14

Nem teljesen értem mire

smokey · 2015. Nov. 5. (Cs), 17.27
Nem teljesen értem mire gondolsz. Ha arra gondolsz, hogy legyen egy kvázi default dátum, amit paraméterként át tudsz adni, akkor én ezt nem így csinálnám, hanem egész egyszerűen ezt a dátumot opcionális paraméterként kezelném.

Ha létezik a dátum az URL-ben, akkor befűzöd a lekérdezésbe a használatát, ha nincs definiálva, akkor nem. Másik alternatíva, az lehet, hogy a dátumot minden esetben belefűzöd a querybe, viszont függővé teszed az értékét az URL alapján. Hogy értsd mire gondolok:

$date = isset($_GET['date']) ? $_GET['date'] : date('Y.m.d. H:i:s');
15

Ha megfordítod a számozást,

Joó Ádám · 2015. Nov. 6. (P), 00.10
Ha megfordítod a számozást, az erre megoldás – egészen addig, amíg nem törölsz elemeket. Akkor vagy hagyod elcsúszni, vagy kihagyod a helyét.
5

Válaszd szét a két feladatot.

feketeKalapos · 2015. Nov. 5. (Cs), 10.47
Válaszd szét a két feladatot.

Sorba-rendezés és szűrés dátum alapján:

http://valami.hu?tipus=cikk&ev=2007

vagy SEO barátoknak:

http://valami.hu/cikkek/2007.

Azután jöhet a lapozó

http://valami.hu?tipus=cikk&ev=2007&oldal=2

vagy

http://valami.hu/cikkek/2007/2.

Ha nem tévedek a WordPress és a Drupal se nem mindig ugyanazokat a listaelemeket jeleníti meg, a lapozó egy adott oldalán. A legtöbb esetbe a programozók adnak egy fix LIMIT értéket az SQL lekérdezéshez és egy dinamikus OFFSET értéket pedig kinyernek a lapozó URL változójából.

Igaz, ha az adott URL-t beteszik könyvjelzőbe, akkor bukta a parti. Mondjuk egy webshop esetén egy kevésbé rutinos felhasználó könnyen azt hiheti, hogy már nincs a boltban a kiszemelt termék. Pedig csak az első oldalról a másodikba csúszott.
6

Igaz, ha az adott URL-t

szabo.b.gabor · 2015. Nov. 5. (Cs), 11.12
Igaz, ha az adott URL-t beteszik könyvjelzőbe, akkor bukta a parti. Mondjuk egy webshop esetén egy kevésbé rutinos felhasználó könnyen azt hiheti, hogy már nincs a boltban a kiszemelt termék. Pedig csak az első oldalról a másodikba csúszott.


ilyesmi okból vetődött fel bennem a probléma, de nem tudom, hogy ez életszerű-e vagy sem.. :)

vagy melyik a fontosabb? adott url-en ugyanaz a tartalom jöjjön, vagy az url alapján lássa a felhasználó, hogy hányadik oldalon van..

ha már url felépítés
cikkeknél maradva úgy gondolom, hogy a havi bontás url alapján természetesen életszerű, és persze ott is lehet lapozás, viszont a lapozást mindenképpen get paraméterbe raknám.
9

vagy melyik a fontosabb?

sanyoo · 2015. Nov. 5. (Cs), 13.31
vagy melyik a fontosabb? adott url-en ugyanaz a tartalom jöjjön, vagy az url alapján lássa a felhasználó, hogy hányadik oldalon van..


adott url-en ugyanaz a tartalom jöjjön.. Már ha számít a seo. Vagyis inkább úgy mondom hogy számít hogy googleből jövö felhasználók. Marha idegesítő felhasználóként hogy ha google beindexel valamit, - és a találatott lekattintva nincs ott az elvárt tartalom.

egyébként:
"url alapján lássa a felhasználó, hogy hányadik oldalon van.."
felhasználók nem nézik az url-t:)