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.
...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.
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ě.
Rozdíly tam pořád jsou a dají se změřit a změřit.Cože???? To fakt myslíš vážně????
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ž 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....
Když DOM staví skript, jsou už to živé objekty, ke kterým se podle toho musí chovat, např. je zamykat.
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 pomalAno, 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í.
Někdy bylo v módě načítat celou tabulku do pamětiJsou 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.
Ale vím,... filtrování na klientovi i na serveru je ta úplně nejhorší možnost, mnohem horší a koplikovanější, než kus stránkyNevíš. Protože
posílat ze serveru jako HTML.
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/
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:
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.
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ší"
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.
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.
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í).
...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.
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.
Jinak jste se rozvášnil zbytečně, já jsem psal jenom o těch datech tabulkyTakž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áš....
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.
Ale je na tom vidět, že je dobré UX vyřešit dopředuTo 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í.
mozno som pri vybere sietovky neklikolNo jo, klikání :-). Zlatej
ip addr...som skusal...Takže ji máš opravdu dynamickou a přidělenou DHCP. Chybu bych tedy hledal tam, zkus prohledat logy DHCP serveru, jestli Ti něco nenapoví.
nastavit IP rucne,A že nepomohlo ruční nastavení.... hmmm, a nastavil jsi ji opravdu dobře :-)? Např. častá chyba je nenastavit (správně) netmask. :-)A fakt to teda znamená, že jsi tu IP adresu opravdu od GW nedostal? Nebo jsi nějakou dostal, tu jsi odstranil a dal tam jinou? Nebo že byly nastavené dvě na stejném subnetu?
pfSence mam nastavene mapovanie MAC na IP adresuA to znamená co? Že je tak nastavený DHCP server? Že je tak nastaven Firewall? Obojí? :-)
Ja som sa nedostal ani na GWA co s tím má co dělat ta Gateway, když jsi se podle svých slov nedostal ani na další zařízení v síti? To přece vůbec přes žádnou GW nejde. Z toho, co píšeš, jsem pochopil, že komunikace uvnitř vnitní sítě fungovala, kromě toho desktopu, kterej byl z nějakýho důvodu odříznutej. Ovšem zpravila to restart GW. Tedy je otázka, jak může GW ovlivnit provoz uvnitř sítě, teda provoz, kterej přes ní vůbec neprochází.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.