JavaScript - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Když diskuse,
tak s Lopuchem

Lopuch.cz

	Klub JavaScript [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
	Archiv - http://al3x.3web.cz/js/ - najdete zde zaklady javascriptu je tam i docela dobre vysvetleny cookies - specifikace ECMAScriptu - standard založený na JavaScriptu a JScriptu.

Nastavení klubu

Nastavení práv

Homepage

Anketa

[ 398 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 20.8.2009 21:57	467
	hm, zkusim to konkretne: potrebuju aby mi ve vypisu tabulky, treba 10 bunek melo odkaz kterej na onclick posle na server Request kterym dotahne dalsi data a injektuje je pod odkazem. umim najit vsechny ty prvky, umim jim dat onclick ale problem nastava v okazmiku kdy Request musi obsahovat pro kazdej element posilat jiny data! V requestu potrebuju samorejem vzdy odeslat par cisel podle nichz server vybavi vysledek. A ted je otazka kam si ulozit ty data z nichz se na onclick ten request sestavi... je to takhle jasnejsi? jinak mootools vyber provedou a nastavej pekne paralelne vsem elementum patricich do tridy: $$(".class_k vyberu").onEvent('click', function(event)... ale ta onclick funkce potrebuje pro kadej element jiny data, vetsnou nejaky cisla id pro databazi a ty dumam kam je koser ulozit. muzu nekam v tom elementu dat csskem skrytej podelement s hodnotou, nebo snad do idcka kazdyho toho elementu ty data zasifrovat a pak aby je ze sveho id desifroval ale oboji mi prijde jako ponekud neciste.


	Johny_G - Relaxační terapie pro lopušáky ZDARMA! 20.8.2009 19:17	466
	Nápodobně.


	Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 20.8.2009 17:03	465
	OK, cetl jsem to dvakrat a ani jednou jsem ani priblizne nepochopil zamer. Snad bude nekdo uspesnejsi (nebo to nejak rozved, mne prijde, jak kdyby to bylo finsky).


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 20.8.2009 16:21	464
	ulozeni dat pro js kod v dokumentu?kterak opravdu cistym zpusobem, kdy v dokumentu nebude js kod, riradim skupine nejakych elementu funkce ktere delaji HttpRequesty ale potrbuji k tomu tim padem pro kazde misto v dokumentu jina data a ty ale nechci nikmu ukazovat? napada me to vsadit do html a skryt pomoci css coz nevim jak je cista metoda, dal me pak leda napada sifrovat to do nazvu tridy a pak to parsovata le to mi prijde taky jako prasarna... vypada to, ze nakonec asi stejne skoncim u onclick natvrdo v html kodu a parametru vlozenych tam... mate na to nekdo vhodnej postup?


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 17.8.2009 15:42	463
	Problem byl ve fazi nacteni, pred plnym nactenim byla velikost neznama a tedy shodna s prirazenym mistem, po nacteni obsahu iframe uz je pristup k vlastnosti scrollHeight zakazan :( Takze JS neni pruchodnej ani z jedny strany...


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 17.8.2009 15:22	462
	jinak uvitam jakekoli reseni


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 17.8.2009 15:21	461
	iframe 100% heightje nejakej zpusob jak zaridit aby iframe mel automatickou vysku podle jeho obsahu i ve firefoxu? nasel jsem akorat nejaky JS reseni ale tam je bezpecnostni problem problem kdyz mam iframe a hlavni stranku na jiny domene... v takovym pripade nemam pravo menit velikost svyho prostoru v tom nadrazenym okne. zkousel jsem to i obracen ale js ma nejakou divnou logiku: document.getElementById('xframe').contentDocument.body.scrollHeight je cislo odpovidajici zhruba vyhrazenemu mistu na strance zatimco v iframu samotnym mi vyhodnoceni document.body.scrollHeight vrati opravdovou vysku... nemely by ty hodnoty byt shodne?


	24.7.2009 10:24	460
	tvxKdyž mu dáš datum expirace, tak by neměl. Nevýhodou je, že jej pak nemůžeš tak rychle měnit, protože při změně budou klienti ještě po určitý čas používat jeho starou verzi.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 24.7.2009 09:56	459
	Bredypri zapnutym cachovani JS mi ale bude browser stejne navazovat spojeni se serverm aby zjistil esli je ten JS dostatecne aktualni nebo ne?


	24.7.2009 09:40	458
	Podmínkou je, mít u toho JS zapnuté cacheování. Nicméně pokud máš těch kusů JS víc, tak bych to lepení neřešil, protože možná první použití každého JS se protáhne, zbytek se nacacheuje. Horší by bylo, kdyby se ten JS soubor sestavoval pro každý request jinak. To je pak lepší ho narvat do toho HTML celý. Totéž platí pro CSS i jiné zdroje.


	24.7.2009 09:38	457
	tvxRychlost počítače (parsování) je nesrovnatelně vyšší vůči rychlosti přenosu po síti. U requestu nezapomen započítat odezvu (Ping). Pokud nepředpokladáš Keep-Alive, tak každý request znamená sekvenci (Send,Receive): S(Sync),R(Sync,Ack),S(Ack),S(Request),R(Reply),S(Ack)... což udělá 5 kol (SRSRS), pokud máš ping 500ms, dělá to 1.25 sekund (500/2 * 5).. a to jen v ideálním případě, pokud se Reply podaří přenést naráz, bez potvrzování. Rychlost parsování bude podle mne nesrovnatelně vyšší. Jakmile máš JS v cache, prohlížeč si na něj pouze sáhne na disk a může pársovat v době, kdy se stahuje zbytek stránky (i kdyby to ten prohlížeč neměl takhle optimalizovaný... přenos po síti většinou na pozadí zajišťuje OS).


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 24.7.2009 09:25	456
	Jeden velkej JS bude urcite i pro moji manipulaci snazsi.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 24.7.2009 09:23	455
	Bredyhm, o to sem uvazoval, ze js bude servirovanej serverem podle seznamu js ktery jsou pozadovany, server to slepi do jednoho baliku a posle, tam ale vidim bud problem s tim, ze i stranky ktery js temer nepotrebujou nebo vyuzujiu jen zlomek toho baliku ho budou zbytecne parsovat. Druhej problem pokud bude kazda stranka vazne chtit jen to co potrebuje je u jednoho veilkyho baliku prave to cachovani, bude tak jeden balik pro kazdej okruh stranek a ten bude jinej. Otazka kterou nedokazu posoudit je, zda je lepsi prumer 100k kodu a treba 6 requestuu a nebo konstantne 200-250k parsovanyho js kodu a jeden request (proste balik vseho co kdy kde muze byt potreba).


	23.7.2009 16:12	454
	tvxVíc souborů naráz zvyšuje množství requestů z browseru, ale protože většina JS se neměnní, tak zvyšuje účinnost cachování. Podle mne je nejefektivnější variant jednoho velkého JS souboru (klidně poskládaného na serveru s dílů) se zapnutým cacheování. Mimochodem, taková zajímavost, Google snižuje množství requestů na server tak, že všechny obrázky má naskládané do jednoho obrázku a pomocí CSS zobrazuje jednotlivé výřezy.


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 23.7.2009 12:32	453
	konkretne resim, zda bude vzdy rychlejsi tahat nekolik ruznych souboru ale jen potrebnych a tim mensi objem a nebo jeden velkej ale nejaendou ale pak bude browser zbytecne parsovat kod co nepouzije.

[ 398 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


(c) 2001-2011 Lopuch.cz Kontakt