DataGrid: Data Paging and Scrolling

Mreže, ki segajo čez višino okna: nativno drsenje, straničenje na strani strežnika in sprotno nalaganje med drsenjem – ter odločitev proti navideznemu drsenju.

Velike sezname DataGrid straniči na strežniku in jih med drsenjem sproti nalaga: če mreža sega čez vidno območje, doda naslednjo stran, ko bralec pride do konca. Brez JavaScripta ostane za upravljanje vrstica straničenja.

Nazaj: predstavitveni pregled

Stanje: [Live] – nativno drsenje, straničenje na strani strežnika (možnost paging) in na njem zgrajeno sprotno nalaganje (Infinite Loading) za mreže, ki segajo čez višino vidnega območja; namenoma brez navideznega drsenja (arhitekturna odločitev, odsek 3). Referenca: DevExpress ASPxGridView »Paging and Scrolling« / način navideznega drsenja.

Brez dodatnih – zadošča osnovna pogodba dataGrid(); nativno drsenje deluje brez dodatnih nastavitev.

Namerna omejitev: na tej stopnji brez navideznega drsenja. Utemeljitev: navidezno drsenje (v DOM ohranjati le vidne vrstice, preostale sproti izrisovati glede na zamik drsenja) zahteva izrisovalnik v JS z lastnim stanjem – to je v nasprotju z načelom »brez ponovne izvedbe izrisovalnika mreže v JS« (layout → mehanika postavitve). Za zelo velike nabore rezultatov je predvidena pot zmanjšanje na strani strežnika (filtri, straničenje), ne virtualizacija na strani odjemalca.

// Brez funkcije straničenja odgovornost za smiselno število vrstic
// nosi klicatelj -- npr. prek stavka SQL LIMIT pred dataGrid().
$rows = $db->queryAll('SELECT id, name, status FROM opravila ORDER BY id LIMIT 500');
echo $widgets->dataGrid($columns, $rows, [
    'empty' => 'Ni najdenih opravil.',
]);

Napačno: rezultat z več deset tisoč vrsticami nefiltriran posredovati dataGrid(). Brez navideznega drsenja gradnik izriše vsako vrstico kot pravo <tr> – DOM postane velik in stran opazno počasna; to ni napaka gradnika, temveč dokumentirana omejitev te stopnje.

Telo mreže (.wk-datagrid__body) ima overflow: auto – vse $rows se v celoti izrišejo v DOM, drsenje pa prevzame brskalnik (sestavina 3 recepta v adaptivity → recept CSS). To je edini podprt način prikaza – ključa $opts za virtualizacijo ni; straničenje je od polne izvedbe na voljo prek $opts['paging'] (naslednji razdelek).

Za nabore rezultatov, ki jih straniči strežnik (virtualizacija ostaja izključena, glejte odsek 3 – le klasično straničenje):

• 'paging' => ['page' => int, 'pageSize' => int, 'total' => int, 'pageUrl' => callable] izriše vrstico straničenja pod telesom mreže (.wk-datagrid__paging): Prva/Prejšnja/»Stran X od Y (N vnosov)«/Naslednja/Zadnja kot navadne povezave z aria-label; neaktivna konca se izrišeta kot posivljena elementa span.
• Podobno kot sortUrl/filterAction: pageUrl(int $page): string vrne URL za vsako stran – pot brez JS je sama funkcija; klicatelj $rows straniči sam (SQL LIMIT/OFFSET).
• pageSize je izbiren; brez njega velja privzeta velikost strani za ves projekt helper_plugin_wkfluentui_widgets::PAGE_SIZE = 12 vrstic. Vsak seznam v izdelku se začne z enako velikostjo strani – če tu nastavite drugo število, odstopate namerno in razlog navedite pri klicatelju.
• pageUrl vrne NEOBDELAN URL (ločilo &, ne &). Gradnik sam maskira na vsakem mestu, kjer URL vstavi. Če mu podate že maskirano obliko, v HTML-ju nastane &; brskalnik to dekodira v dobesedni &, in vsak parameter za prvim se tedaj imenuje amp;do, amp;page, … – stran 2 neopazno pristane v pregledu skrbništva. 2026-07-30 so bili prizadeti štirje klicatelji hkrati (wkidentity uporabniki, wkblog prispevki/komentarji, wksqliteds Browse), ker pomožne metode url() teh modulov privzeto maskirajo. Gradnik od tedaj dodatno normalizira (str_replace('&', '&', …)), ker wl() vrednosti parametrov kodira z odstotki in je dobesedni & v ustvarjenem URL-ju zato vedno ločilo, nikoli podatek.

Pravilo (zahteva uporabnikov 2026-07-29): ko mreža preseže višino vidnega območja, samodejno preklopi v način sprotnega nalaganja. Izvedba: paging poleg vrstice straničenja objavi še URL naslednje strani in lastne seštevke kot podatkovne atribute na .wk-datagrid__more; scripts/gridinfinite.js med izvajanjem odloči, ali se način vklopi – odločilno dejstvo (ali ta mreža sega čez vidno območje?) obstaja šele po izračunu postavitve.

Brez navideznega drsenja (odsek 3 velja nespremenjeno): vsaka naložena vrstica ostane prava vrstica v DOM. Izbira, Ctrl+A, razvrščanje, število v vrstici množičnih dejanj in izvoz CSV zato ohranijo preprost pomen »vse naloženo«; vrstice se nikoli ne reciklirajo ali odstranijo. Brez JavaScripta se nič ne spremeni – vrstica straničenja je navigacija.

Kombinacija z razvrščanjem in filtri (zavezujoče pravilo za klicatelja): pri straničenju na strani strežnika morajo funkcije sortUrl in filterHidden trenutno stran prenašati v ustvarjenem URL-ju oziroma v skritih poljih – sicer sprememba razvrščanja ali filtra neopazno skoči na 1. stran.

$page = max(1, (int)($_GET['p'] ?? 1));
$rows = $db->queryAll('SELECT id, name FROM opravila ORDER BY id LIMIT 50 OFFSET ' . (($page - 1) * 50));
echo $widgets->dataGrid($columns, $rows, [
    'paging' => [
        'page'    => $page,
        'pageSize' => 50,
        'total'   => $skupaj,
        'pageUrl' => static fn (int $p) => wl($ID, ['p' => $p]),
    ],
]);

• Brez navideznega drsenja (namerna, trajna omejitev, glejte odsek 3) – sprotno nalaganje ni virtualizacija, temveč dodajanje pravih vrstic.
• Sprotno nalaganje je vezano na paging. Mreža brez paging izriše vse podane vrstice in se pomika nativno; tam ni ničesar naložiti (tako deluje na primer mreža z rezultati na delovni površini SQL, ki vrstice dobi naenkrat).
• Pogoj sta IntersectionObserver in fetch; če eden manjka, ostane vrstica straničenja vidna in vse deluje kot prej.
• Praktična zgornja meja za »še vedno tekoče« je odvisna od brskalnika in naprave in tu namenoma ni navedena kot stalno število (nepodprta trditev o zmogljivosti).

• Nativno drsenje je v celoti upravljivo s tipkovnico (Page Up/Page Down, puščice, ko je fokus v telesu mreže) brez dodatne kode.
• Brez zahtev za združljivost brskalnikov, ki bi presegale osnovno podporo CSS overflow.

Simptom: mreža postane pri velikih naborih rezultatov opazno počasna.

Vzrok: vse vrstice se v celoti izrišejo v DOM – to je dokumentirana omejitev te stopnje, ne napaka.

Rešitev: nabor rezultatov zmanjšajte pred klicem (SQL LIMIT/ WHERE) ali vklopite straničenje na strani strežnika prek $opts['paging'] (odsek 6).

• predstavitveni pregled – vse kategorije
• DataGrid: adaptivity – recept CSS, na katerem temelji drsenje
• DataGrid: filtering – zmanjšanje podatkov na strani strežnika (filtri)
• area:layout → mehanika postavitve – načelo »brez ponovne izvedbe izrisovalnika mreže v JS«