Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 77 78 [79] 80 81 ... 375
1171
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 21. 05. 2021, 21:51:22 »
Na JS-only aplikacích není pomalé samotné JS generování DOMU. To se koneckonců přeloží na stejné volání interní funkcí browseru na vybudování DOMU, jako bude volat parsing HTML
Ne, ta cesta je jiná. Při parsování HTML se může prohlížeč spolehnout na to, že je parser jediný, kdo má k vznikajícímu DOMu přístup. Když DOM staví skript, jsou už to živé objekty, ke kterým se podle toho musí chovat, např. je zamykat. Proto vznikají věci jako Shadow DOM, které umožňují vyhnout se pomalé práci s živým DOMem. To, že je DOM řádově rychlejší, než před lety, neznamená, že už je stejně rychlý, jako HTML parser. Rozdíly tam pořád jsou a dají se změřit a změřit.

Debata začala od toho, že jsi to navrhoval konkrétní problémřešit pomocí dohrávání HTML snippetů.
Ne, já jsem navrhoval ten problém řešit tím, že se někdo začne zabývat UX aplikace. HTML snippety jsem uvedl jako příklad maximální rychlosti, které lze docílit – aby si tazatel mohl vyzkoušet, co je maximum možného, a např. mohl usoudit, že je to stále pomalé a je potřeba opravdu řešit UX. Nebo, v horším případě,  aby měl aspoň s čím srovnávat a věděl, zda už se dostal na 90 % maxima, nebo se stále plácá někde kolem 5 %.

Tazatel popisoval případ, kdy na klientu ta data zobrazovat chce
Tazatel popisoval příklad, kdy data na klientovi chce programátor. Uživatel je tam nechce.

1172
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 21. 05. 2021, 12:34:45 »
tento přístup jde zrovna pro záznamy typu logy, kde člověka zpravidla zajímá blízká budoucnost, dobře a funkčně implementovat s filtrováním jen na klientovi. A to máš s dobrým widgetem v podstatě zadarmo, popř. musíš napsat jeden malej JS helper apod. Takže Ti to naopak často práci ušetří
Vidím, že načíst si celou tabulku do paměti a pak záznamy filtrovat a řadit na serveru v PHP, už není v módě. Teď se celá ta tabulka rovnou přestěhuje až na klienta.

i když je dat tolik a usecase je takové, že je potřeba součinnost filtrování na klientu a serveru, tak ta námitka je úplně mimo, protože doplnit do serverového api filtrování je práce tak asi na čtvrt hodiny. Takže za malej kus práce získáš svižnější aplikaci (nemusí si v mnoha případech říkat serveru o data)

(samozřejmě, tento přístup přestane bejt vhodnej v okmažiku, kdy bude tad tolik, že budou k rozumné práci potřeba indexy).
Ony existují i aplikace, které zpracovávají větší objem dat, než je nějaký blogísek. Filtrovací logika může být dost komplikovaná, např. se do SQL dotazu připojují další tabulky, které tam nejsou, když příslušný filtr není použit. Když to budete chtít řešit na klientovi, nebudete k němu po síti stěhovat jen celou tabulku, ale rovnou celou databázi.

To, o čem mluvíš teď je serverside prerendering JS-only aplikací.
To je druhá možnost. Já jsem ovšem psal o staticky generovaných webech (SSG). Což byste věděl, kdybyste četl komentáře, na které reagujete. Technologie za tím je stejná, jako SSR, nicméně když chcete rychlost zobrazení stránky, používá se právě to generování – protože se stránky vytvoří už v době buildu a jediné, co musí udělat server, je poslat už hotový soubor do prohlížeče. Což se krásně deleguje na hloupou edge cache, která nemusí umět zpracovávat žádný JavaScript, jenom odesílá soubory.

kterou jsem btw. ze svých tvrzení explicitně vylučoval, kdybys dobře četl...
To je právě váš problém. Nečtete komentáře, reagujete na své domněnky – a pak za to ještě vynadáte ostatním, že se drží tématu a ne vašich výmyslů.

která ovše s Tebou původně navrhovanou technologií, kterou jsme kritizovali:
Citace
Tak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky
....nemá společného vůbec nic.
Řeč byla o tom, zda se rychleji zobrazí HTML → nativní HTML parser → DOM, nebo JSON → nativní JSON parser → JavaScript → DOM. Na tomto příkladu je to dobře vidět, protože ta komplikace se SSG a SSR se dělá právě proto, že první cesta je pro zobrazení výrazně rychlejší. No a princip je úplně stejný, jako s tím mým příkladem – z hlediska rychlosti je prohlížeči jedno, zda parsuje celé HTML, nebo jen HTML fragment.

A protože jsme se opět dostali do fáze, kdy místo technických věcí řešíme to, že děláš z černé bílou, tak se z další debaty na toto téma omlouvám.
Přesněji řečeno jsme se opět dostali do fáze, kdy vy polemizujete s vlastními výmysly, které vás napadají volnými asociacemi nad některými slovy z mých komentářů. To, že se omlouváte z debaty, je tedy eufemismus – vy jste se jí doopravdy nikdy nezúčastnil.

1173
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 21. 05. 2021, 08:42:23 »
Jsou dvě možnosti. Buďto tvrdíš rychlejší ve smyslu CPU času. Pak je Tvůj argument mimo, protože CPU čas na klientovi při úloze tohoto rozsahu není problém (pokud se to napíše rozumně). Že ho tazatel řeší není zvolenou technologií (jak tu celou dobu implicitně tvrdíš), ale pouze nekvalitou zvoleného widgetu.
Anebo jsi myslel rychlejší ve smyslu rychlejší vývoj (což je dnes většinou poměrně podstatné kritérium)- a pak se prostě mýlíš, je to přesně naopak.
Nebo je ještě třetí možnost, ta nejlogičtější – jde o dobu, kdy se uživateli stránka zobrazí. To je totiž to, co se na webu řeší. Jestli uživatel pět vteřin kouká na bílou stránku a teprve pak se něco zobrazí, nebo jestli se mu něco zobrazí za 1 sekundu. Měří se to metrikami jako First Meaningful Paint nebo Time to Interactive, abych vybral ty dvě nejdůležitější.


Evidentně netušíš, jak se taková aplikace dá napsat
Ale vím. Přičemž to vaše filtrování na klientovi i na serveru je ta úplně nejhorší možnost, mnohem horší a koplikovanější, než kus stránky posílat ze serveru jako HTML.

Správně jsi vystihl, že sliná stránka tohoto řešení je SEO
A také pomalost, která je podle mne větší problém, než SEO – právě proto že vyhledávače si už s JS docela obstojně poradí.

A slabá stránka tohoto řešení je, že nějakým způsobem buďťo píšeš ty stránky defakto dvakrát (pokud tedy nepoužíváš např. nodejs, kde to může renderovat stejný kód na obou stranách, nebo nepoužíváš nějakej framework, kterej ti tu serverside stranu vygeneruje z clientside javascriptu sám), anebo se jiným způsobem drbeš se sešíváním HTML a JS části aplikace.
To platilo před několika lety, dnes už to není pravda.

1174
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 21:33:38 »
Generování DOM pomocí JS je - pokud se to dělá dobře - i v mnohatisíciřádkové tabulce naprosto dostatečně rychlé. Takže to není problém. (A pokud někdo tvrdí, že to problém je a že ten problém jde vyřešit jen složitým špatně čitelným kódem, tak prostě netuší, jaké jsou dnes možnosti vývoje webových aplikací).
Když se váš komentář tváří jako polemika, měl by se texte vztahovat k tomu, co citujete. Polemizovat s něčím, co nikdo nenapsal, je zbytečné.

Co problém je, je rychlost UI v "HTML only" aplikaci - protože v takové aplikaci musím dělat drtivou většinu věcí na serveru (např. jak mám filtrovat data, když přišli jako HTML snippet a "nevidím dovnitř"). Proto je JS implementace UI ve výsledku podstatně rychlejší, neboť odpadne pro uživatele vždy znatelný lag komunikace se serverem - stejně jako hromada problémů tohoto modelu vývoje (např. nutnost přenášet stav aplikace po bezstavovém protokolu, nebo implementace stavu pomocí cookies, jejíž problémy lze vidět např. na problémech tohoto fóra).
U stránkovací tabulky není nic lepšího, než filtrovat na klientovi… „Na této stránce odpovídají filtru 4 záznamy. Ale zkuste se podívat také na další stránky, třeba tam objevíte nějaké další.“ Nebo stáhnete do pohlížeče celou databázi?

Samozřejmě, pak je také možnost si posílat HTML, to na klientu parsovat a získávat z něj dále zpracovávatelná data pro filtrování a agregace a..... - ale nevím, proč bych takovou pitomost dělal, když si můžu rovnou poslat JSON, a odpadne mi jak kódování na serveru (místo psaní šablon zavolám jednu funkci) i na klientu.
To, že do prohlížeče pošlete první stránku už kompletně vygenerovanou a teprve pak na to napojíte JavaScript, se normálně dělá. První stránka se zobrazí rychle, dobře funguje SEO, a teprve následující požadavky se řeší přes JSON.

1175
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 19:49:14 »
Nejde jen o špičaté závorky. Data musí být patřičně ošetřena - přitom json_encode() to již má v sobě.
:D

že Javascript to umí zapisovat přímo do DOM a umí do něj doplnit i potřebnou bižuterii, kterou není nutné přenášet. Mezičlánek HTML je tedy možné vypustit.
Výše jsem vysvětloval, že nativní implementace HTML → DOM je výrazně rychlejší, než parsování JSONu a následná manipulace s DOMem pomocí JavaScriptu.

1176
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 19:17:16 »
Docela výrazně - generování JSON spotřebuje asi jednu desetinu výkonu oproti HTML.
Jo, ty špičaté závorky se v tom procesoru zasekávají, složené projdou mnohem líp… Na tohle se fakt nedá nic jiného napsat…

Navíc je zbytečné renderovat HTML i na klientovi, takže klient ho nemusí ani parsovat.
Nějak mi uniká, co jste touhle větou chtěl říct.

1177
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 19:14:56 »
Dobrý způsob řešení je nezobrazovat tisíciřádkovou tabulku.

Když se teda budeme bavit o tom, jak technicky řešit zobrazení takové tabulky. Použití kvalitního webového JS gridu by bylo dobré řešení, když to bude „na zelené louce“, nebude tam nic okolo. Jenže tazatel už tam JS framework má, cpát do toho nekompatibilní grid může být problematické. Doručit tam rovnou statické HTML může být bezpečnější. Které řešení je lepší tady nerozhodneme, když nevíme detaily. Ale jak jsem psal, důležitější je vyřešit UX, technický problém se tím nejspíš vyřeší sám.

1178
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 16:51:33 »
Citace
...a milionkrát užitečnější, než špatně udělaný grid...
Jasně. Tvoje řešení je nejlepší, protože bude udělané dobře, zatímco ostatní to udělaj blbě. Tomu říkám argument.
Já jsem nepsal nic o tom, jestli je něco moje řešení nebo řešení někoho jiného. Tomu, co jste ředvedl, se říká slaměný panák.

Existuje x JS webových aplikací, které takový problém zvládají dobře.
Zvládají to technicky dobře, ne dobře z hlediska UX. Bohužel pro vás tohle tvrzení není v rozporu s ničím, co jsem napsal, takže vaše teorie o tom, že s tím nemám zkušenosti, jsou jen další vaše demagogie.

To, co tvrdíš - že optimalizace znepřehledňuje kód - je sice teoreticky pravda, ale pouze od určité úrovně. Naopak do určité úrovně správně napsaný a tedy rychlý kód je přehlednější a použitelnější, než "bastl".
Děkuji za potvrzení mého tvrzení, že optimalizace znamená, že správně napsaný a přehledný kód v zájmu vyšší rychlosti nebo menší paměťové náročnosti přepíšu a bohužel ho při tom musím znepřehlednit. Pokud je nějaký kód napsaný špatně a já ho přepíšu, aby byl srozumitelný, a přitom se ten kód jako vedlejší efekt i zrychlí, není to optimalizace, ale obyčejná oprava špatně napsaného kódu.

A to, co řeší tazatel, se ani náhodou neblíží k limitu, kdy by to dobře napsaná webgui aplikace nezvládla.
Tazatele zřejmě řešení nezajímá, takže jsme se nedozvěděli, jak přesně ta tabulka vypadá. Je možné, že v těch tisíci řádcích opravdu je spousta interaktivních komponent – sice to z hlediska UX nedává žádný smysl, ale to nedává ani těch 1000 řádků. Výpis takové tabulky by samozřejmě trval dlouho, klidně je možné i se správným kódem se dostat na ty časy, které uváděl tazatel. Takovou tabulku (se zachováním funkčnosti) ovem moc optimalizovat nejde. Jediné, kde se ten problém dá řešit, je UX. Takže stále platí to, co jsem psal na začátku. Pokud se ten problém má opravdu vyřešit, je potřeba se zaměřit na UX. Až se vyřeší UX, technický problém nejspíš zmizí.

A navíc je to právě naopak, dobře napsaná JS aplikace má ty limity v některých ohledech podstatně dál, než aplikace která tahá ze serveru vygenerované html snapshoty. Z mnoha důvodů, např. že podstatně snáz se tam dělá cache a znovupoužití dotažených záznamů ze serveru.
Preo vás je možná limitem to, co se dělá snadno. Já mám limity dál a klidně se pustím i do věcí, které jsou obtížné.

Tvoje rada je podobnej nesmysl, jako svého času byly na webu zaručené rady, že používat JOINY je špatně, protože jsou pomalé.
Další slaměný panák.

Takže ještě budeš kombinovat dvě různé technologie a lepit je na sebe - a jako myslíš si, že tím vznikne rychlejší a nebo přehlednější kód. Hele, sorry, fakt je vidět, že mluvíš o věci, o který sis možná někdy něco přečet, ale zkušenosti s tím nemáš....
Optimalizace se nedělá proto, aby vznikl přehlednější kód. Právě naopak, optimalizace znamená, že se obětuje přehlednost v zájmu vyšší efektivity kódu. Zkuste to pochopit.

Jinak pro vaši informaci, parsování HTML prohlížečem do DOMu je podstatně rychlejší, než když parsujete JSON a pak z něj v JavaScriptu vyrábíte DOM. Proto jsou poslední dobou tak v oblibě generátory statických webů postavené na frontendových technologiích jako Gatsby, Next.js, Gridsome, Sapper apod. Ale můžete všem, kteří to používají kvůli rychlosti výsledného webu, vysvětlit, že vy jste ten odborník, a že to všichni dělají špatně, je to pro uživatele pomalé, a navíc se jim to bude strašně špatně vyvíjet, nemohou používat cache…

1179
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 13:42:46 »
Pokud se podívám na ten svůj Thunderbird, tak vidím nejprve tisíce záznamů
K čemu je to dobré? Pokud ten seznam e-mailů stahujete ze serveru, přenesou se ta data zbytečně, vy si pak můžete zanadávat, kolik paměti žere Thunderbird – a jinak?

Jo, můžeš. A taky se můžeš drbat levou nohou za pravym uchem.

Výsledek je hůře udržovatelnej kód a drbačka se synchronizací stavu na klientu a serveru (posílat stav všech - často na sobě nezávislých - renderovaných komponent, je fakt žůžo), za což ovšem získáš UI s podstatně pomalejší reakcí na vstup uživatele a problémy s asynchronicitou a přerenderováváním stránky (když uživatel "zběsile kliká").
Od týdle technologie se snažej všude, kde to jde (tedy není řešení postavený na legacy frameworcích) dát ruce pryč a vědí proč. Před deseti (dvaceti?) lety to na tehdejší "jednoduchý" weby byla rozumná technologie. Ale doporučovat to někomu dneska... no radši to nebudu dál komentovat.
Bavíme se o optimalizaci v případě, kdy by tazatel ověřil, že je problém opravdu v manipulaci s domem a že tam nemá nějaká zbytečná volání. To je holt nevýhoda optimalizací, že zpravidla znamenají hůže udržovatelný kód. Kdyby to šlo napsat efektivně a zároveň hezky, napíše se to tak rovnou a není potřeba to optimalizovat.

Jinak jste se rozvášnil zbytečně, já jsem psal jenom o těch datech tabulky. Jestli se uživateli zobrazuje tabulka s tisíci záznamy, a na každém řádku spousta komponent, jejichž stav může uživatel měnit, tak se nedivím, že je to pomalé. Akorát pořád nevím, co s tím bude ten uživatel dělat.


To je samozřejmě pravda, pokud ovšem existují předem jasně dané usecase. Což právě v případě analýzy dat není ani zdaleka pravidlem, protože dost často to, co člověk vlastně v datech hledá, se dozví až během analýzy.
Analýza dat je také use case. přičemž procházet ta data očima je zase ten nejméně vhodný nástroj pro analýzu dat. Pokud autoři aplikaci neumí zjistit, jak se data budou analyzovat, ať se vykašlou na zobrazení tisíců řádků ve webovém prohlížeči, což bude uživateli stejně k ničemu, a umožní mu vyexportovat ta data do Excelu. Tam už si s tím uživatel poradí mnohem lépe, než ve webové stránce bez nástrojů.

Např. filtrování je dobrý a řeší úplně všechno.... do tý doby, než např. zjistíš, že Tě nezajímají jen vyfiltrované položky, ale jejich okolí.
Zobrazení okolí filtrovaných položek není žádná magie, která by se nedala naprogramovat.

Pro tydle účely je nějakej datagrid s JS fitrováním a dynamickým dočítáním dat IMHO nejvhodnější technologie.
Pokud to někdo myslí vážně, že bude uživateli zobrazovat tisíce záznamů, je nejvhodnější technologie export do Excelu. Protože ten ty nástroje pro práci s daty má, uživatel si to tam už vyfiltruje, seřadí, seskupí a spočítá tak, jak potřebuje. Bude to podstatně užitečnější, než když to bude muset do Excelu kopírovat přes schránku (a milionkrát užitečnější, než špatně udělaný grid, ze kterého ta tabulková data nejdou přes schránku rozumně vykopírovat).





[/quote]

1180
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 09:58:48 »
V případě, že na data koukají stovky různých uživatelů a nikdo předem neví, co koho zajímá, je podle mě kombinace stránkování, řazení a filtrace to pravé, co snadno uspokojí všechny bez nějakého kouzelného UI.
Pokud je dat jen tolik, aby je snadno výkonnostně zvládnul klient, není problém mu je poslat všechna a vizualizaci nechat na něm, pokud je jich více, pošle mu server jen pohled na jejich část.
- stránkování snadno naznačí s jakým množstvím dat se pracuje, aniž by se data musela všechna najednou zobrazit nebo přenáet ke klientovi, není většinou přímo určené k tomu, aby uživatel všechny stránky prohlížel, ale ve specifických případech, kdy je řazení a filtrace nedostačující, to umožní, není omezený jen na rozsah dat určený natvrdo vývojářem (třeba prvních 10 vyhovujících záznamů).
- seřazení podle vybraného sloupce v kombinaci s filtrací je podle mě to pravé co poskytne rychlý přístup ke správným datům, aniž by bylo potřeba předem něco řešit za uživatele.
Pracuju vcelku často s aplikací, kde prohlížím tabulky s desítkami tisíc záznamů a hledám v nich ty správné - obecný textový filtr přes všechny zobrazené sloupce (s našeptávačem častých filtrů i s možností specifikace filtrace jen na vybraný sloupec) v kombinaci se správným řazením záznamů je pro mě opravdu to nejrychlejší, jak najít správné záznamy - v tomhle případě vše řešené na serveru, přenášet 100 000 záznamů na klienta už je neefektivní.
Všimněte si, že to, co jste popsal, má i technickou výhodu – nikdy nepotřebujete zobrazovat tisíc záznamů. Zobrazujete jen pár záznamů, které uživatele zajímají, případně celkový počet záznamů, který odpovídá zadaným podmínkám (takže není potřeba ani stránkování).

Nicméně to už se bavíme o UX. Ale je na tom vidět, že je dobré UX vyřešit dopředu, protože pak zjistíte, že vlastně vůbec nemusíte při vývoji řešit problém, jak uživateli zobrazit tisíc záznamů najednou.

1181
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 20. 05. 2021, 00:06:12 »
Ušetří se výkon, protože se negeneruje celá stránka ale jen data pro část stránky.
Nikoli. Explicitně jsem psal, že by se generoval HTML kód pouze pro tabulku.

Tohle je tak provařené téma, že mi přijde tristní o tom diskutovat?
Tak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky. DOM opravdu nemusíte jen vyrábět JavaScriptem, můžete ho získat i nativním parsováním HTML zabudovaným v prohlížeči.

Ohledně tabulky - velkou tabulku uživatel nebude číst řádek po řádku, ale okem proskenuje charakter záznamů a zopakuje filtrování, aby zúžil výběr.
Nebo může mít aplikace pořádné UX, aby to skenování záznamů očima mohl uživatel vynechat.

Nebo bude mít  třeba předpřipravené filtry, na které klikne.
K tomu ale není potřeba zobrazovat tisíc záznamů, že?

Data v tabulce uživatel zřídka čte celá, protože s nimi obvykle dále pracuje - hledá maxima, minima, zjišťuje počet
Kdyby tak uměly minimum, maximum a počet záznamů zjistit počítače. Bohužel to neumí, tak to musí dělat lidé.

záznamy edituje
Tisíc záznamů?

exportuje
Potřebuje ty záznamy před exportem vidět? Zase bude tisíc záznamů kontrolovat očima?

To myslím platí bez ohledu na počet řádků.
Pořád platí, že když musí uživatel číst tisíc řádků, je něco špatně. Od toho, aby pracovaly s velkým objemem dat, přece máme počítače. Počítači je jedno,jestli zpracuje deset řádků nebo tisíc, člověku ne.

Vaše argumentace je jako byste říkal, proč je v tabulkovém procesoru tolik řádků.
V tabulkovém procesoru žádné řádky nejsou, dokud je někdo nenapíše. A pokud je někdo napíše, dělá to proto, že je lidé chtějí číst. Číst mnohasetstránkové romány lidi baví. Číst tisíciřádkové tabulky nebaví nikoho. A dělají v tom lidé chyby, nějaké řádky přehlédnou apod.

V mailovém klientovi mám momentálně 11 tis. mailů a hledám v nich pomocí rychlého filtru a není v tom žádný problém.
Vida, hledáte pomocí rychlého filtru. Který vám zobrazí pár e-mailů. Neprocházíte tisíc e-mailů očima.

To je use-case, který mám na mysli. Výhoda živého hledání přitom je, že uživatel neztrácí kontext - pohybuje se stále na stejném místě aplikace a pracuje stále se stejnou sadou dat.
Akorát že to nevyžaduje zobrazovat tabulku s tisícem řádků.

Což neplatí po odstránkování nebo přerenderování stránky.
O přerenderování celé stránky tu ale píšete jenom vy.

A najdou se případy, kdy se živé hledání nehodí. Takže to už je diskuze jen kvůli diskuzi...
Na živé hledání jste se ovšem omezil jenom vy. Najdou se také případy, kdy se nehodí zorbazovat tisíciřádkovou tabulku – jsou to všechny případy zobrazení tisíciřádkové tabulky.

Ale samozřejmě, že někdy se vyplatí zobrazovat tisíciřádkovou tabulku – když je vývoj nákladnější, než práce uživatelů. Nicméně tazatel měl snahu vyjít uživatelům vstříc – a mnohem užitečnější, než zobrazovat uživateli tisíc řádků rychle, je poskytnout mu takové nástroje, aby těch tisíc řádků vůbec vidět nepotřeboval. Filtry, vyhledávání, zobrazení správných údajů (počty, extrémy), jiné formy vizualizace, než je tabulka.

1182
Vývoj / Re:Doporučte rychlý WWW widget pro view SQL tabulky
« kdy: 19. 05. 2021, 21:38:56 »
Pokud se html generuje na klientovi a interakce s ui je také řešena na klientovi, ušetří se výpočetní výkon serveru který je pak k dispozici pro obsluhu dalších požadavků. Část výpočetního výkonu se tedy distribuuje mezi klienty. Data se ze serveru přenáší typicky pomocí JSON. Co k tomu víc dodat?
Ten JSON se podle vás vezme kde? Nebo myslíte, že když bude server generovat {"jmeno": "Jiří Novák"} místo <td>Jiří Novák</td>, ušetří se tím nějak výrazně jeho výkon?

Pokud se místo JSON budou posílat HTML fragmenty (a z nich pak generovat DOM s nimiž se bude dále pracovat), je to spíš komplikace než výhra, ale ano, někdy to tak frameworky dělají.
Jak jsem psal, je to řešení případu, kdy generování DOMu na klientovi trvá dlouho. Což může být případ velkého objemu dat a starších prohlížečů, nebo třeba složité logiky, jak z dat to HTML generovat.

Nevím, proč by tabulka s filtrací nebyl nástroj na vyhledání záznamu?
Tabulka zobrazující tisíc záznamů (a ještě stránkovaně) není nástroj pro vyhledání záznamu.

Ale mít jednu tabulku s tisícem řádků nevidím jako nějaký principielní problém ani výkonnostně ani uživatelsky
K čemu uživateli těch tisíc zobrazených záznamů je? Bude je číst jeden po druhém?

1183
Vývoj / Re:Doporucte rychly WWW widget pro view SQL tabulky
« kdy: 19. 05. 2021, 21:33:41 »
jaky je tedy ten nastroj?
To záležína otm, co chce uživatel dělat. Což od tazatele nevíme. Akorát jsem si poměrně dost jistý, že uživatel nechce očima procházet tisíce záznamů.

1184
Vývoj / Re:Doporucte rychly WWW widget pro view SQL tabulky
« kdy: 19. 05. 2021, 16:04:56 »
Myslím, že anonacct chtěl říci, že správně udělané generování na klientovi zrychlí aplikaci jako celek i pro jednotlivce, při současném zlepšení uživatelské přívětivosti.
Myslím, že se v tom trochu zamotáváte. Pokud aplikace generuje na serveru celou HTML stránku, dá se odezva zryhlit tím, že se pomocí kódu na klientovi vymění pouze obsah tabulky, resp. příslušná část stránky se vymění za tabulku. Ušetří se tím, že se nemusí znovu stahovat arenderovat celá stránka.

Nicméně pokud se ten obsah tabulky na klientovi vytváří tak, že se ze serveru stáhne JSON a ten se pak v klientovi transformuje na HTML, dá se odezva stránky dále urychlit tím, že se DOM nebude vyrábět na klientovi z JSONu, ale z HTML. Ale to už je optimalizace až na krev, většinou není potřeba.

Hlavní problém ale pořád vidím v tom, že tazatel chce uživateli předhodit tabulku s tisíci záznamů, ať si tam něco hledá očima, místo aby mu poskytl nástroj, pomocí kterého mu najde potřebné záznamy počítač. A nikoli, tabulka s filtrací a řazením není ten nástroj. Tyhle tabulky mají rádi programátoři, protože nemusí nic vymýšlet, jenom zabalí SQL dotaz do GI (= graphical interface, na U se v tomto případě zapomělo).

1185
Vývoj / Re:Doporucte rychly WWW widget pro view SQL tabulky
« kdy: 19. 05. 2021, 08:50:32 »
Rozhodně nic negeneruj na serveru, zbytečně si budeš zabíjet čas serveru něčím, co může udělat klient...
Otázka: Zpracování na klientovi trvá příliš dlouho.
Odpověď: Rozhodně nic negeneruj na serveru, můžeš tím přece pěkně vytížit klienta.

Anonacct, pro vaši informaci, serveru bude trvat stejně dlouho, jestli ta data bude renderovat do JSONu nebo do HTML tabulky.

Asi děláš něco špatně (špatná komponenta).
Otázka: Můžete doporučit nějakou lepší komponentu?
Odpověď: Asi používáte špatnou komponentu.

To jsou fakt odpovědi za všechny prachy.

podporuje i miliony záznamů
Zobrazovat miliony záznamů uživateli v jedné tabulce? To se používá kde, v pekle?

Stran: 1 ... 77 78 [79] 80 81 ... 375