Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Standa Blábol 18. 05. 2021, 15:05:16

Název: Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Standa Blábol 18. 05. 2021, 15:05:16
Pisu ted jednoduchy nastroj (Spring Boot 2.4.5), ktery prijima eventy na REST a uklada je do Postgresql tabulky pomoci PLSQL procedury, ta interne provadi deduplikaci eventu se stejnym ID pomoci "INSERT ... ON CONFLICT DO UPDATE ..."

TO vsechno funguje pekne, je to rychle, udruzuje se v tom cca 20-30k eventu.

REST API "getAll" mi vysype vsecky  udalosti CURLem za cca 800ms, po restartu Springu i Postgresu, pak se to po nakesovani zrychli  na cca 250ms, download speed 22MB/s, naprosto postacuje.
Chome dtto, zobrazeni raw JSON textu prakticky okamzite

Problem mi nastal, kdyz se pokousim ty data vizualizovat na webu, obvykle pouzivam JSF2 widget Primefaces::Datatable s paginaci, zatim jsem pouzival paginaci cca 30 radku, tam to funguje skvele.
Nyni potrebuju paginaci radove 1000 zobrazenych radku (nebo uplne bez paginace), a tam mi pri paginaci 1000 radku trvalo robrazeni Primefaces Datatable pres minutu.

Vystup profileru:

Kód: [Vybrat]
971 ms  Loading
13791 ms  Scripting
36149 ms  Rendering
7187 ms  Painting
4322 ms  System
4115 ms  Idle
66534 ms  Total

Load dat pod sekundu, pak tam Chrome neco pres minutu vyrabi. Klientska stanice je pomerne vykonna, Lenovo P50 s Core i7 a 64 GB RAM

Muze nekdo doporucit neco lepciho, cim se da zobrazit na webu vetsi tabulka dat s podporou paginace, filtrovani, sortovani?
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 18. 05. 2021, 16:35:52
Pro prohlížeč bude určitě rychlejší, když HTML vygenerujete na serveru a prohlížeč ho jenom vyrenderuje.

Ale tabulka zobrazující 1000 záznamů je špatně z pohledu UX, navíc ještě stránkovaná. To bude někdo prohlížet tisícovky záznamů očima? Lepší by bylo poskytnout uživateli takové nástroje, aby tolik záznamů zobrazovat nemusel.
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: A.P.Hacker 18. 05. 2021, 17:11:55
jak pise Jirsak, zobrazovat 1000 zaznamu je spatne. Snad vsechny backendove frameworky maji nejakou hotovou podporu pro datatables, vcetne strankovani, filtrovani, razeni.

ja v djangu pouzivam https://pypi.org/project/django-datatables-view/
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 18. 05. 2021, 18:07:03
Html tabulku s 1000 řádky dnes prohlížeče zvládají levou zadní (alespoň na desktopu). Při vhodném realtime hledání to může být i uživatelsky přívětivé a s okamžitou odezvou - lepší než čekat na refresh jsonu ze serveru nebo dokonce celé html stránky. Viz např. https://www.materialsproject.org/static/components/listjs/website/examples/performance-test.html

Pokud je to pomalé, viděl bych to na nějakou implementační chybu nebo použití nevhodného nástroje.
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: anonacct 18. 05. 2021, 19:54:58
Rozhodně nic negeneruj na serveru, zbytečně si budeš zabíjet čas serveru něčím, co může udělat klient...

Asi děláš něco špatně (špatná komponenta). Přetransformovat 1000 řádků v JSON do nějaké tabulky by mělo i v javascriptu trvat max pár ms. Podívej se na slickgrid nebo něco takového - podporuje i miliony záznamů
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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?
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 19. 05. 2021, 14:39:23
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?

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. Jde přitom o dnes běžný postup. Ten listjs u mě renderuje html tabulku s 100 tis. řádky asi 0.3s a filtrování řádků je skoro okamžité. Takže pokud má kolem 1 tis. záznamů tak bych se nerozpakoval je vypsat naráz a ušetřený čas věnoval na kvalitní a názorné filtrování nebo přidání nějaké vizualizace.

Jinak pokud to v té komponentně trvá dlouho, tak se například může dělat nějaký callback po přidání každého řádku, ale správně se má použít API na dávkové vložení řádků, aby se callback provedl až na konci. To je jen příklad problému, které si může programátor způsobit když k tisíci záznamů přistupuje jak předtím k jednomu. Tazatel by se měl podívat, zda něco takového nepřehlédl.
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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).
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: A.P.Hacker 19. 05. 2021, 20:38:35
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).

jaky je tedy ten nastroj?
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 19. 05. 2021, 20:42:46
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? Nemám dojem, že by v tom bylo něco zamotaného. 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í.

Nevím, proč by tabulka s filtrací nebyl nástroj na vyhledání záznamu? Může nad tím mít celý widget s tlačítky a hejblátky a tím omezovat výběr. Zda je to vhodný nástroj záleží na typu aplikace, samozřejmě. Asi narážíte na tu paginaci, kde zobrazovat stránku s 1 tis. řádky na každé stránce je nesmyslný koncept, protože paginace a filtrování jsou do určité míry konfliktní koncepty (z hlediska UI - v závislosti na konrétní situaci). Což může být vidět i na tom datatable widgetu, který možná vůbec nepočítá s takovým počtem řádků. Ale mít jednu tabulku s tisícem řádků nevidím jako nějaký principielní problém ani výkonnostně ani uživatelsky, pokud je k tomu filtrování či případně i vhodná vizualizace. Ano, předpokládám, že to není tak, že by se tam vypsala celá sql tabulka a filtrování že by pak suplovala sql dotazy, takové řešení by asi zarazilo každého.

Nebo si možná vůbec nerozumíme, nicméně vše podstatné podle mě bylo řečeno, tak ať si to tazatel přebere sám.
Název: Re:Doporucte rychly WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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ů.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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?
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 19. 05. 2021, 23:39:55
Ušetří se výkon, protože se negeneruje celá stránka ale jen data pro část stránky. Samotné generování JSON bude typicky také rychlejší, pokud porovnáme s generováním html pomocí šablonovacího nástroje (což je typická technologie pro generování celé stránky). Lze samosebou najít i protipříklady, ale já mluvím o typických rysech daného řešení. Tohle je tak provařené téma, že mi přijde tristní o tom diskutovat?

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 bude mít  třeba předpřipravené filtry, na které klikne. Ušetřený čas může programátor věnovat vizualizaci dat v grafu nebo jakkoli jinak, což přidá další dimenzi pro orientaci v datech. Data v tabulce uživatel zřídka čte celá, protože s nimi obvykle dále pracuje - hledá maxima, minima, zjišťuje počet, záznamy edituje, exportuje apod. To myslím platí bez ohledu na počet řádků.

Vaše argumentace je jako byste říkal, proč je v tabulkovém procesoru tolik řádků. 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. 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. Což neplatí po odstránkování nebo přerenderování stránky.

A najdou se případy, kdy se živé hledání nehodí. Takže to už je diskuze jen kvůli diskuzi...
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: hechj 20. 05. 2021, 00:26:50
Napište si tu vizualizaci sám. Jestli ten widget chroupe nějaký obecný json nebo váš konkrétní json, tak to může být velký rozdíl. Já bych si teda posílal tabulku ze serveru a pustil bych na to widget, který uchopí hotovou tabulku (filtrable, sortable table).

offtopic
Pro kolik je to uživatelů, že řešíte úsporu výkonu serveru? 100 000?

Nikdy jsem neviděl, že by skládání DOM v prohlížeči byla levná operace. A taky je otázka, proč zobrazovat 1000 záznamů najednou. Nejspíš je to pro někoho, kdo ví, co ta tabulka obsahuje. Proto bych použil ajax a ze serveru posílal filtrovaná data.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 20. 05. 2021, 00:35:02
Já bych rozhodnutí zda zobrazovat 1000 nebo jeden řádek nechal na tazateli a jeho uživatelích. Mě šlo pouze o to, že zobrazit 1000 řádků z JSON nebo je následně filtrovat není výkonnostní problém. Rychlost jsem ilustroval na listjs a uživatelský usecase na Thunderbirdu, kde vidím v tabulce 10 tis. mailů a filtruju mezi nimi. Jiné ambice jsem v této diskuzi neměl a ani nyní nemám  :)
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Tomas-T 20. 05. 2021, 08:23:47
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í.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 20. 05. 2021, 11:41:01
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í).

Pokud se podívám na ten svůj Thunderbird, tak vidím nejprve tisíce záznamů, které rychle zúžím na počet, který mi vyhovuje (což může být i těch tisíc, pokud je třeba někam přesouvám). Je to rychlé a není to problém ani pro mne ani  pro počítač. Je to jen můj názor, nikomu ho nenutím.

Celá debata je tedy jen o tom, jaký maximální počet ještě počítač a uživatel zvládne. Ať si to uživatel klidně někde nastaví - pan Jirsák si tam dá 1 řádek a bude spokojen :D
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 20. 05. 2021, 11:59:16
Standa:
Koukni na react-table. Akorát je trochu drbačka s rozchozením reactu (ale na to najdeš tutoriál), ale pak to umí všechno, co IMHO budeš od visualizace tabulkových dat potřebovat (včetně dočítání dalších dat ze serveru)

Filip:
Citace
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.
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.

Citace
Ale je na tom vidět, že je dobré UX vyřešit dopředu
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. 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í.

Pro tydle účely je nějakej datagrid s JS fitrováním a dynamickým dočítáním dat IMHO nejvhodnější technologie.





Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: robin martinez 20. 05. 2021, 13:11:00
tvl, uz chapu, jak vznikaji mizerni programatori :D

Ale je pravda, ze se dost casto setkavam s lidma, co jsou liny a nechteji resit strankovani, tak vyblejou na web celou databazi. Pecka
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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]
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: A.P.Hacker 20. 05. 2021, 13:45:02
tvl, uz chapu, jak vznikaji mizerni programatori :D

Ale je pravda, ze se dost casto setkavam s lidma, co jsou liny a nechteji resit strankovani, tak vyblejou na web celou databazi. Pecka

nejsou lini, spis ignoranti. Strankovani je bezpracne, pokud pouzijete hotovy widget.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 20. 05. 2021, 15:21:58
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.

Jinak export do Excelu od určité velikosti záznamů má velkou nevýhodu v tom, že narozdíl od webgui Ti neumožní dotahovat další data, takže musíš vyblejt celou datbázi najednou, což je v mnoha případech (např. kdy se běžně dívá na logy z posledního dne a jen zřídka potřebuješ jít dál) zbytečné.
Citace
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.
A toto právě dokládá to, že "děláš chytrého" ve věci, s kterou evidentně nemáš žádné zkušenosti. Existuje x JS webových aplikací, které takový problém zvládají dobře. Tedy evidentně Tvoje "že by to tak bylo nutně napsané dobře", je nesmysl. Tazatel si prostě vybral špatnou knihovnu, nikoli špatnou technologii.

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". A to, co řeší tazatel, se ani náhodou neblíží k limitu, kdy by to dobře napsaná webgui aplikace nezvládla. 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.
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é. Což byla pravda.... pokud znal člověk jen MySQL a neuměl používat pořádný databáze. Pak ano, pak bylo lepší používat nástroje z doby krále klacka. Tvoje rada tazateli je "z podobného ranku".

Citace
Jinak jste se rozvášnil zbytečně, já jsem psal jenom o těch datech tabulky
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áš....

Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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…
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 20. 05. 2021, 18:38:15
Filip:
To, proč je Tebou navrhovaný přístup dle mého názoru špatně, proč navrhovaná technologie IMHO není vhodná, a proč IMHO volba kvalitního webového JS gridu je dobrý způsob řešení toho problému jsem již napsal. To je pro tazatele podstatná informace, a k tomu nemám co dodat ani co doplnit.

Nic z toho, čím jsi na to reagoval to nijak nevyvrací - jen jsi buďto nepochopil, co jsem se Ti snažil sdělit, nebo to úmyslně překroutil. A protože to není poprve, tak sorry, ale do další nesmyslné diskuse se vtáhnout nenechám.



Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Kit 20. 05. 2021, 19:13:38
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?

Docela výrazně - generování JSON spotřebuje asi jednu desetinu výkonu oproti HTML. Navíc je zbytečné renderovat HTML i na klientovi, takže klient ho nemusí ani parsovat.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Pixe 20. 05. 2021, 19:23:49
Necháme kluky ať se vydiskutují a mezitím se vrátíme k tématu. Jakým způsobem ta data to té komponenty láduješ? Používáš ten LazyDataModel? Nemáš například volání repository v get metodě? Přímo v dokumentaci je ukázka pro 20k záznamů, takže pokud tam někde nepácháš nějaké harakiri, tak by to ta knihovna měla pobrat

http://primefaces.org/showcase/ui/data/datatable/scroll.xhtml?jfwid=046d1


...
Problem mi nastal, kdyz se pokousim ty data vizualizovat na webu, obvykle pouzivam JSF2 widget Primefaces::Datatable s paginaci, zatim jsem pouzival paginaci cca 30 radku, tam to funguje skvele.
Nyni potrebuju paginaci radove 1000 zobrazenych radku (nebo uplne bez paginace), a tam mi pri paginaci 1000 radku trvalo robrazeni Primefaces Datatable pres minutu.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Kit 20. 05. 2021, 19:33:11
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…

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ě.

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.

ž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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: M_D 20. 05. 2021, 19:45:16
Uff, jak bych byl rád, kdyby uživatelé po nás chtěli jen tabulku o jednom tisíci řádků. Ty junioři analyzátoři chtějí tabulku o 4 až 5000 řádků. Jejich plesnivej šéf tabulku o 50.000 řádcích. Žádné filtrování, žádné stránkování, to zdržuje, vyhoď do prohlížeče tabulku, já chytnu posuvník a projedu ji za cca 30 sekund odshora dolů a vím jak zkouška dopadla, voko totiž není <pííp> a vidí.... A nemusím čekat, až oddělení výpočtů a analýz to vedle přechroupá za 5 hodin a vypadne z nich je OK/není OK. :-)
Pár sloupců - název relátka/spínáče, čas posledního sepnutí na milisekundy, stav, doba přepnutí.... Pozice řádků je pevná, takže vyhledávání na řádek dělá tak, že najede posuvníkem na naučenou pozici, zkrátka to zná po paměti (jen když dostane nový monitor a myš, tak chvíli trvá, než se přeučí na aktuální geometrii). A ten poloslepej plesnivec se nesplete. Když neměl prohlížeč v PC, tak před 30-ti lety to vyhodnocoval tak, že mu to ADT4500 vytisklo na balík papíru, který si protočil přes mandl a měl výsledek také (na tom ADT to pak analyzovali cca týden, co on na tom mandlu z traktorového papíru sjel okometricky za pár minut).
Nu, a když nezkoumá zrovna zkoušku, tak v si tabulku zobrazí pro radost a řádky se v ní ještě živě aktualizují, cca desítky-stovky řádku/sec (a dost se ukazuje, že posílat data k aktualizaci přes MQTT embedované ve websocketu jako JSON zprávy je dost omyl, prohlížeč je z toho na prášky).
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Pixe 20. 05. 2021, 19:45:59
Jakou má prosím souvislost json_encode() s Java aplikací?

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ě.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 20. 05. 2021, 21:13:05
Citace
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.
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í).

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).

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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 20. 05. 2021, 22:54:33
Citace
Polemizovat s něčím, co nikdo nenapsal, je zbytečné.
Psal jsi: "Výše jsem vysvětloval, že nativní implementace HTML → DOM je výrazně rychlejší"
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.

Citace
U stránkovací tabulky není nic lepšího, než filtrovat na klientovi… „Na této stránce odpovídají filtru 4 záznamy.
Nikoli. Bude tam "z dosud načtených záznamů vyhovují tyto"....a zatím tahám další. Takže uživatel vidí a může zpracovávat aspoň něco, než request doběhne, takže ho to tolik nezdržuje. Evidentně netušíš, jak se taková aplikace dá napsat (včetně prefetchingu atd...). A navíc, ta data nahrávám jednou, ne že uživatel čeká po každém kliku. Což je při analýze dat (kdy delší dobu pracuji s jednou sadou dat) velká výhoda.


Citace
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á.
Ano, existuje více možností, jak napsat webapp: kde má každý svojí silnou a slabou stránku. Správně jsi vystihl, že sliná stránka tohoto řešení je SEO (i když dneska dobré boty - např. google interpretují i JS, takže to už není tak nutné jako dřívé). 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.

Tedy tato technologie tedy může bejt vhodná např. pro eshop, kde Ti jde o SEO v první řadě, a UI nedosahuje velké složitosti. Ale nevím, proč bych měl tuto technologii používat pro stránku s reportama, kde mne SEO nezajímá, a tedy nemám důvod psát tu stránku dvakrát, když jde napsat jednou. Obzvlášť, když se dá čekat, že tam bude složité UI, což ještě zvýrazní nevýhody Tebou navržené technologie.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 21. 05. 2021, 11:37:16
Citace
Ale vím,... 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.
Nevíš. Protože
a) 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ří
b) a 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).

Citace
právě proto že vyhledávače si už s JS docela obstojně poradí.
JS only page je pro crawlery furt poněkud problematická a nedoporučuje se. Viz např.https://www.searchenginejournal.com/seo-javascript-good-bad-uncertainty/346708/
Citace
To platilo před několika lety, dnes už to není pravda.
To, o čem mluvíš teď je serverside prerendering JS-only aplikací. Tedy rozumná (či spíše velmi dobrá) technologie (kterou jsem btw. ze svých tvrzení explicitně vylučoval, kdybys dobře četl...), 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. 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Kit 21. 05. 2021, 12:49:05
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.

Někdy bylo v módě načítat celou tabulku do paměti a pak teprve zpracovávat v PHP? No fuj!

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.

Stačí klientovi poskytnout view.
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.

Správně, nenechme se zmást benchmarky, které tvrdí opak.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 21. 05. 2021, 15:40:06
Filipe:
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 (jo, před patnácti lety to opravdu pomalejší bylo, ale jaksi je rok 2021). To, proč se používá SSG či prerendering je nutnost nahrát celý JS a inicializovat aplikaci a celý JS framework před tím, než se něco zobrazí. Tedy to, že se používá SSG a prerendering řeší úplně jiný problém, než rychlost vytváření DOM pomocí JS - a tedy celé Tvoje teorie, které sis kolem toho vybudoval a tady razíš, jsou nesmyslné.
Debata začala od toho, že jsi to navrhoval konkrétní problémřešit pomocí dohrávání HTML snippetů. A u této technologie -- která už je léta považovaná za antipattern, byť se pořád používá: ze setrvačnosti nebo proto, že frameworky nepodporují modernější a praktičtější možnosti -- se (přinejemenším obvykle i v tomto konkrétním případě) prostě žádná podstatná výhoda SSR se neprojeví, zatímco nevýhody ano.

Promiň, ale z toho co píšeš, je naprosto evidentní, že web nevyvíjíš, praxi v tom nemáš (teda doufám, to by tomu dalo nový rozměr hrůzy :-) ) - a jen sis o tom občas někde něco přečet, a myslíš si, že rychle vygooglenejma věcma někoho uzemníš.

Citace
Někdy bylo v módě načítat celou tabulku do paměti
Jsou případy, kdy je vhodné tahat data na klienta (především pokud je předpoklad, že většinu z nich bude klient stejně chtít zobrazit) a jsou případy, kdy je to špatně. Tazatel popisoval případ, kdy na klientu ta data zobrazovat chce, tedy je rozumné si je tam dotáhnout a ne je tahat furt dokolečka znova.
Takže tato Tvá snaha o zesměšnění je jen demagogie.



Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 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 (https://quirksmode.org/dom/innerhtml.html) a změřit (https://measurethat.net/Benchmarks/Show/6964/0/dom-manipulation-vs-innerhtml#latest_results_block).

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.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 21. 05. 2021, 23:04:05
Ok, tak teď když si tazatel otestoval maximum možného, je vše v pořádku a může přeskočit celou diskuzi a věnovat se opravě toho svého řešení, kde nejspíš stačí opravit nějaký přehmat :)
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 22. 05. 2021, 19:16:20
Citace
Rozdíly tam pořád jsou a dají se změřit (https://quirksmode.org/dom/innerhtml.html) a změřit (https://measurethat.net/Benchmarks/Show/6964/0/dom-manipulation-vs-innerhtml#latest_results_block).
Cože???? To fakt myslíš vážně????

 První odkaz měří např. FF 3.x - 13 let starej browser (a to je ještě z těch novějších v testovací sadě). To fakt se snažíš "svoji pravdu" dokazovat takovým podvodem a myslíš si, že Ti na to nepřijdem? Nebo jen nejsi schopen si všimnout ani tak základního problému odkazovaného?
 Druhej odkaz pak neporovnává totéž, anžto je napsanej blbě (psal jsi ho Ty? nebo jen si vygooglil první blbost, která podporuje "Tvoji pravdu" a nejsi schopen ji ani zkontrolovat?)? Když ten odkaz opravím tak, aby fungoval stejně (tzn. aby druhá možnost nedělala s každou iterací větší a větší dokument, a zahrnu čas i na sestavení toho HTML, které někde sestaveno být musí), tak mi vyjde rychlost 72 ku 78 - čili manipulace HTML vyjde dokonce pomaleji.

https://measurethat.net/Benchmarks/Show/13130/0/corrected-dom-manipulation-vs-innerhtml (https://measurethat.net/Benchmarks/Show/13130/0/corrected-dom-manipulation-vs-innerhtml)
(Pokud nezahrnu sestavování HTML tak je HTML o cca 10% rychlejší, což je pořád zanedbatelné - a také to ukazuje, že manipulace s DOM není natolik drahá operace, aby mělo smysl dělat takovéto fine-grade optimalizace). Takže sorry, prostě tu sebejistě prohlašuješ nesmysly.

Citace
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.
Když stavím dom "mimo dokument" a pak ho tam jedním appendChild přivěsím, zamykat musím úplně stejně jako když ho tam zavěsím pomocí innerHTML. Javacript v browseru je multithreadový pouze pomocí Worker threadů, které nemají přístup k DOMu. Žádnej problém navíc s race conditions tam prostě není. Takže pohádky si vymejšlíš hezké, ale to je tak vše....

Citace
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
Ano, a právě proto tvrdím, že navrhuješ kravinu. Použití HTML snippetů by žádnou podstatnou rychlost navíc nepřineslo. Problém tady  vůbec není v tom, že by použitá technologie byla znatelně pomalejší než snippety,ale čistě v tom, že uživatel použil špatně napsanej grid, kterej je zbastlenej a nezvládá větší objemy dat. Proto se tazatel zcela korektně ptá, kterej jinej - lépe napsanej grid použít. Jednoduchá otázka s jednoduchou odpovědí.

A ty, místo toho, co bys tazateli poradil na co se ptá (a pokud nevíš, tak mlčel), tak na základě zastaralejch znalostí, které už dávno neplatí, tady radíš kraviny a chceš po něm, aby místo jednoduché výměny gridu, kterou jde zvládnout za pár hodin, začal experimentovat s předpotopní technologií, řešení zcela překopal a tím zbytečně spálil hodin desítky, a jsi ve svý aroganci přesvědčenej, že víš líp než tazatel sám, co vlastně řeší za problém a co tazatel potřebuje, čímžs ten dotaz úplně zabil. Sorry.

A když Tě ostatní upozorní, že tvrdíš nesmysly, že problém není tam, kde ho hledáš, tak místo toho, aby sis pořádně svá tvrzení ověřil, nebo dokonce třeba se dokonce nechal poučit od lidí, kteří danou věc umějí a mají s ní reálné zkušenosti, tak tu celej thread zničíš tím, že dokolečka opakuješ nesmysly, který se snažíš obhájit dalšíma nesmyslama vycucanejma z prstu a prasecky napsanejma testama, který jestli něco dokazujou, tak to, že nedokážeš pochopit, co ve skutečnosti udělá párřádkovej JS kód. Sorry  za otevřenost.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 22. 05. 2021, 21:56:27
První odkaz měří např. FF 3.x - 13 let starej browser
To je váš problém, že používáte FF 3.x. Já jsem to měřil ve Vivaldi 3.8.

A ty, místo toho, co bys tazateli poradil na co se ptá
Já jsem mu poradil, jak problém vyřešit. Nemůžu za to, že vy máte nutkavou potřebu opravovat věci, které nikdo netvrdil. A ještě se u toho tváříte, že vaše slovo je zjevená Pravda, a pokud snad nějaký důkaz je v rozporu s vaším tvrzením, je to chyba toho důkazu.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Logik 22. 05. 2021, 22:44:45
Filipe:
Citace
...To je váš problém, že používáte FF 3.x...
Tak nevím - fakt Ti dělá problém interpretace jednoduchého textu a nepochopil jsi, co jsem psal? Anebo pochopil a úmyslně tu lžeš? Fakt nevím, jak si Tvoji poslední odpověď vysvětlit jinak.
- Jediný člověk, kdo se tu oháněl rychlostí FF 3.3, jsi byl Ty sám: ve svém prvním odkazu v předchozím postu.
- Měřit rychlost svým browserem jsi pak mohl ve svém druhém odkazu. Ovšem tam je implementace testu DOM udělaná úplně blbě (což neodhalit to, když je to pár řádků i je chybný výsledek vidět, je dost umění) a když se to opraví (viz odkaz v minulém postu), tak ten test naopak prokáže, že "modifikace dom" je v moderním browseru naprosto srovnatelně rychlá jako užití innerHTML ( a to i ve Vivaldi 3.8 ), ač jsi zde tvrdil opak a snažil ses vymýšlet nesmyslné pohádky, proč by jako tomu tak mělo být.

Citace
Já jsem mu poradil, jak problém vyřešit.
Ano, vím, že jsi se snažil radit. Jenže když někdo někomu radí vyměnit technologii a přístup - a přitom plave v tom, jaké jsou vlastně výhody a nevýhody daných technologií - tak prostě radí blbě.

Omlouvám se, ale protože veškeré technické věci už byly vyřešeny a už je debata jen o tom, že neumíš uznat omyl, tak se z další debaty omlouvám.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 22. 05. 2021, 23:14:38
Jediný člověk, kdo se tu oháněl rychlostí FF 3.3, jsi byl Ty sám: ve svém prvním odkazu v předchozím postu.
Ne.

Měřit rychlost svým browserem jsi pak mohl ve svém druhém odkazu.
I v prvním.

Takže stránku s prvním benchmarkem jste si nepřečetl, ale víte, že je špatně. A můžu za to já.

tak ten test naopak prokáže, že "modifikace dom" je v moderním browseru naprosto srovnatelně rychlá jako užití innerHTML ( a to i ve Vivaldi 3.8 ), ač jsi zde tvrdil opak
Já jsem tvrdil, že nativní parsování HTML je rychlejší, než manipulace s DOMem. Což potvrzují všechny benchmarky, včetně toho vašeho. Ale ne, vy prostě budete tvrdit, že černá je bílá.

Ano, vím, že jsi se snažil radit. Jenže když někdo někomu radí vyměnit technologii a přístup
Problém je, že se pokouší uživateli zobrazit 1000 řádků. To je uživateli k ničemu, nikdo nedokáže přečíst tisíc řádků a neudělat při tom chybu. Proto jsem poradil zaměřit se na tohle, protože tohle je problém. Ale nečekám, že byste to napopáté pochopil.

Omlouvám se, ale protože veškeré technické věci už byly vyřešeny a už je debata jen o tom, že neumíš uznat omyl, tak se z další debaty omlouvám.
Ale kdepak, já vaše omyly uznávám, opakovaně na ně upozorňuju. Ale vy je neuznáváte. Tvrdím, že je něco rychlejší, vy to rozporujete, změříte, že je to opravdu rychlejší, ale stejně trváte na tom, že jste měl pravdu vy… A ještě se u toho tváříte jak mistr světa, který se nemůže v ničem mýlit.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Ondrej Nemecek 23. 05. 2021, 00:14:27
Křečovité držení se své pravdy přes důkazní materiál vede k dalšímu ztrapňování se. Navíc je to od začátku off-topic.
Název: Re:Doporučte rychlý WWW widget pro view SQL tabulky
Přispěvatel: Filip Jirsák 23. 05. 2021, 09:55:37
Křečovité držení se své pravdy přes důkazní materiál vede k dalšímu ztrapňování se. Navíc je to od začátku off-topic.
Souhlasím.