ugrás a tartalomhoz

Sütik írási sebessége.

therest · 2012. Május. 16. (Sze), 17.03
Helló!

Arra lennék kíváncsi, hogy vajon milyen sűrűn lehet a sütiket írni. Nekem kb 0,5-2 másodpercenként kéne beleraknom valami értéket. Megoldható ez? Ha jól tudom, akkor ezeket fájlba rakja ki a böngésző, ebben az esetben gondolom lehetnek gondok.

Még mindig ablakozok....
Mivel nincs egyetlen crossbrowser event sem, ami a böngésző bezárásakor lefutna, és nincs lekorlátozva a funkcionalitása, ezért megpróbálnám a gyermek ablakból egy süti értékét állítgatni sűrűn, a szülő ablakokban csekkolni hogy mi a süti tartalma. Ha a timestamp már "régi" akkor megejteni az ablak bezárásakor szükséges teendőket.
‹ Jquery.post fgv. nem működik Linuxon Modal dialog ›
 ■
1

Ez most így

inf · 2012. Május. 16. (Sze), 17.18
Ez most így komoly???

Sütiket olyan gyorsan lehet írni, ahogy bírja a fájlrendszer... Ha az egyik ablak lockolja írásra, akkor gondolom a másikkal nem fogod írni... A fájlrendszer műveletek elég gyorsak ezred másodperc, vagy annál is kisebb érték...
(Nem teljesen biztos, hogy de el tudom képzelni, hogy néhány böngésző memóriában tartja a sütiket, szóval azoknál még gyorsabb az írás.)

Mi ez az ablakozás? Te melyik században élsz? :D
4

Nagyjából egy pókerklienst

therest · 2012. Május. 17. (Cs), 00.20
Nagyjából egy pókerklienst képzelj el webre, ahol attól hogy fut 2-3 játékod, még navigálhatsz a lobbiban. Persze lehet mondani, hogy oldjam meg ajax-al, és div-ekkel, de az oldal elég komplex, sőt ennél már csak komplexebb lesz. Erre jön az a faktor, hogy a user szeret frissítést, vissza gombot, nyomni bármikor, aztán felháborodni, hogy az aktuális játék félbeszakadt. Ezért az ablakozás, mert így az egyes tartalmak függetlenek, és szerintem így biztonságosabb. Az ablakok követésére pedig kéne valami olyan rendszert építenem ami tudja, hogy melyik van nyitva, és milyen tartalommal. Ez - ahogy én látom nem egyszerű -, mivel sok faktor játszik, az említett frissítés és elnavigálás, a lobbi oldal többszöri (több fülön való) megnyitása, stb. Sok esetben elveszik a gyermekablakra mutató referencia.
Egyik lába lenne ennek a rendszernek, hogy a gyermek ablak a "id" nevű sütibe kirak egy timestampet, a fő, lobbiablak pedig ezeket az infókat nézi meg, és ebből állapítja meg, hogy nyitva van-e még az ablak. Minél sűrűbb a süti írása, annál precízebb a dolog.

Köszi a sebességgel kapcsolatos infókat, mindazonáltal a stílus nem volt túl baráti. :)
Ha van építő jellegű ötleted,kritikád,infód kérlek oszd meg.
7

Az ablak bezárását azt hiszem

inf · 2012. Május. 17. (Cs), 10.01
Az ablak bezárását azt hiszem onbeforeunload + prompt -tal szokták megakadályozni, jobban jársz ajax-al, korántsem lesz annyira bonyolult vele, csak egy map kell, amiben tárolod az ablakok neveit, meg azt, hogy nyitva vannak e ...

Ha több ablakkal csinálod, akkor is úgy tolnám, hogy van egy központi ablak, amiben az információkat tárolod, minden új ablak átveszi a központi ablak info tároló objectjét. Így biztosan nem veszik el semmi, hiszen minden ablak ugyanazt az objektumot írja és olvassa...

(Ja tegnap nem voltam barátkozós hangulatban, mert volt egy probléma, amit 3 hétig nem sikerült megoldani. Aztán persze tegnap este valahogy összetákoltam. Nagyon nem szeretem a telepítést és konfigurálást, mindig beleakadok valami hülyeségbe...)
10

Az onbeforeunload-ot elég

therest · 2012. Május. 17. (Cs), 14.43
Az onbeforeunload-ot elég szigorúan kezelik a böngészők, és saját scriptet nem tudom mennyire lehet olyankor lefuttatni, pl ha jól olvastam a chrome kizárólag egy confirm-ot enged. Itt nem elsősorban az a cél hogy a user ne csukhassa be az ablakot ha nagyon akarja, inkább, az hogy ne nyithasson rá egy már meglevőre, és főleg ne akkor ha abban aktív folyamatok vannak.

A központi ablakkal az a gond, hogy a user hajlamos elnavigálni, meg frissítést nyomni, ilyenkor a teljes kliensoldali infó elveszik. Erre az egyik megoldás ez a sütis dolog. Persze az ablakok infóját át lehet menekíteni szerver oldalra, és ajax-al kérdezgetni/beállítani de ilyenkor meg ugye olyan kérdések merülnek fel, hogy mi van ha a szerver mondjuk túlterhelt, a válasz késik. Ilyenkor mondhatom azt, hogy az ablak tuti nyitva van, vagy zárva van? Nem mondhatom. A felhasználó meg türelmetlen, ha nem dobja fel az ablakot vagy a "már meg van nyitva" üzenetet a rendszer a klikk után közvetlenül, akkor sokszor elkezd ész nélkül klikkelni, frissít, stb és ez egyre kevésbé kiszámítható működést eredményez.
11

Azt hiszem nehezen értjük meg

inf · 2012. Május. 17. (Cs), 15.17
Azt hiszem nehezen értjük meg egymást. Én a helyedben egy ajax-os oldalt csinálnék, ahol a mostani ablakok helyett abs pozícionált divek lennének a központi ablakban valami drag-drop-os rendszerrel (elég sok van ilyen, simán le lehet tölteni). A központi ablak véletlen bezárását meg onbeforeunload-dal akadályoznám meg. Persze fejleszthetsz helyette saját rendszert a saját elgondolásaid szerint, csak kétszer annyi idő alatt leszel kész vele...

Néhány éve a meebo-nál mindkét változat között lehetett választani (nekem mint felhasználónak akkor is a div-es megoldás jött be, gondolom sokan vannak így vele most is ...). Nem tudom a mostani meebo milyen, de érdemes lenne ránézned.
13

Értem amit mondasz, sajnos

therest · 2012. Május. 18. (P), 15.29
Értem amit mondasz, sajnos van itt több olyan faktor (branding - nem csak css, js szinten, 3rd party integration, már meglévő szerver oldali mvc keretek) amik miatt egy totálisan ajax-ra épülő rendszernél nem vagyok teljesen biztos abban, hogy meg tudnám valósítani amit kell.

Azt is jó dolognak tartom, hogy a user akár el is navigálhat a főoldalon akárhova, akár abban az ablakban is ahol eredetileg a lobbi volt, közben a popupban tovább vár a torna következő meccsére, stb.
2

Ha már ebből az irányból

kuka · 2012. Május. 16. (Sze), 17.26
Ha már ebből az irányból közelíted meg, esetleg Cross-document messaging nem lenne jobb? Egészen jó a támogatottsága, persze az Explorer hiányosságait leszámítva.
3

Van megoldás

Poetro · 2012. Május. 16. (Sze), 17.43
Ráadásul van megoldás IE esetén is. Természetesen ehhez ismernünk kell az ablakokat, és azokhoz kell, hogy legyen referenciánk. De akkor tökéletesen működik, és lehet közöttük adatokat küldözgetni, legfeljebb párszáz millisec (a fenti szkriptben pont 100ms) késéssel. Ennek elégnek kell lennie. Nekünk third-party oldalba való integráció miatt kellett, mert volt egy widgetünk egy iframe-ben, amit a tartalomhoz képest át kellett méretezni, és ez csak kívülről lehetséges.
5

Hát igen, itt a

therest · 2012. Május. 17. (Cs), 00.36
Hát igen, itt a referenciákkal van a nagy bibi, mert ezek egyáltalán nem biztos hogy megvannak. De nem is az ablakok közötti kommunikáció a lényeg, hanem inkább az, hogy főablakok tudjanak a gyermek-ablakokról, és ne engedjék a usert újra megnyitni egy aktív ablakot, stb.
Az ablakhoz rendelt saját rendszeremen belüli id-ket tudom, és így lehet vizsgálni a sütikben a létezésüket. A sütikkel kapcsolatos sebesség kérdése azért merült fel, mert ha a user bezárta az ablakot, akkor utána viszont minél hamarabb jó lenne ha újra ki tudná nyitni.
Amikor bezárja akkor ugye nem frissül a sütiben a timestamp, a főablakban ezt olvasom, a sütit pedig törlöm, ha az aktuális idő és a sütis időbélyeg közötti különbség túl nagy. Az ablak feldobásakor pedig nyilván azt nézem van-e süti az adott id-vel, ha nincs mehet, ha van nem mehet.
Az a kérdés, hogy vajon egy ennyire sűrű süti írás/olvasás okoz-e valamiféle problémát.
8

sűrű süti írás/olvasás

Pepita · 2012. Május. 17. (Cs), 14.10
Tekintve, hogy a süti fájlban van, semmi gond, annyi írás/olvasás a lemezen. De.

Mivel olyan adatokat tárolsz (és ráadásul csak néhány byte-ot), amik sűrűn változ(hat)nak, gyakran kell elérni, stb., sokkal célszerűbb memóriában tartani, mint a vrinyón. Mert gyorsabb, "csendesebb", stb.

Arra viszont - igen sajnálom, de - nincs konkrét ötletem, hogy ezt hogy oldd meg nem HTML5-ös eszközökkel. (Asszem valaki már említette a storage-lehetőségeket.) Ha sikerül (az adattranzit), légyszi írd le, hogy csináltad!
9

Tekintve, hogy a süti fájlban

kuka · 2012. Május. 17. (Cs), 14.38
Tekintve, hogy a süti fájlban van, semmi gond, annyi írás/olvasás a lemezen. De.
Erre azt mondanám, hogy attól függ. Tapasztalatom szerint legalábbis a Mozilla alapú böngészők megspórolják a munkamenet sütik kiírását. Azaz ha nem állítasz be expires dátumot és a böngésző zárásakor úgyis törölni kellene, akkor nem kerül be a cookies.sqlite (régebben cookies.txt) állományba.

Persze valahol máshol valószínűleg csak feljegyezi, hiszen erőszakos leállítás után ha kérjük a korábban használt fülek visszaállítását, akkor a munkamenet sütiket is visszaállítja.
12

50% jó hír

Pepita · 2012. Május. 17. (Cs), 16.16
Ez már fél jóhír. Akkor valszeg az olvasás a memóriából megy, íráskor meg (ha változás is van) ment egyet.

Elképzelhetőnek tartom - de nem tudom -, hogy IE is ilyen, az alapgondolkodás Microsoft-éknál is nagyjából az, hogy ami lehet, legyen RAM-ban (ezért is olyan memóriazabálók a windows-ok).
6

Ez nagyon érdekes téma, köszi

therest · 2012. Május. 17. (Cs), 00.37
Ez nagyon érdekes téma, köszi a linkeket, sajnos 7-ig támogatnom kell az ie-t is, szal ott meg lettem lőve.

Ez kuka hozzászólására ment volna eredetileg...
14

Mivel sokan írtatok (köszi),

therest · 2012. Május. 21. (H), 11.10
Mivel sokan írtatok (köszi), elmondom végül mire jutottam.
A gyermekablakok 10 másodpercenként írják a saját sütijüket. Ez nem olyan őrülten gyakori.
Amikor a user új gyermekablakokat akar nyitni akkor a főablakban az ablakokat kezelő osztályban meglesem van-e referencia az adott ablakra. Ha van, akkor valami függvényhívással lehet ellenőrizni, hogy él-e az adott ablak.
Ha nincs ref akkor végignézi a rendszer a sütiket, és a bennük lévő timestamp-eket.
Ha nem talál a megfelelő id-vel, vagy olyat talál ami 10 mp-nél öregebb akkor a gyermek ablak nem létezik (mivel 10 másodperce nem írta a sütit).
A 10 másodpercnél öregebb sütiket törli.
Ha van azonos id-jű, és 10 másodpercnél fiatalabb süti, akkor feldob egy divet: "Úgy tűnik ez az ablak már nyitva van, kérlek várj pár másodpercet amíg leellenőrizzük." Visszaszámol 10-től.
Ez alatt nézi, hogy frissül-e a süti, ha a visszaszámlálás alatt nem, akkor az ablak már bezárásra került, és megnyitja újra. Ha frissült, akkor szól a felhasználónak, hogy az ablak már nyitva van.
A fentieken túl van egy érdekes dolog még. A window.opener kapcsán játszottam azzal, hogy több fület megnyitottam/bezártam/frissítettem a böngésző főablakában, és egy gyermekablakból próbáltam hívni az opener egyik függvényét. Elég érdekes működést leltem, hol elérhetetlenné vált az opener, hol egész sok interakció után is elérhető maradt. Arról még gőzöm sincs, hogy milyen eltérések vannak böngészőnként.
A gyermek ablakban ezután definiáltam egy checkIn függvényt, amit setInterval-al hívok pár másodpercenként. Ez megpróbálja elérni az opener ablakkezelő osztályának childCheckIn függvényét. Ha sikerül, akkor paraméterként átadja a window ref-jét, tehát gyakorlatilag lejelenti magát. Ezek után már lesz referencia a gyermekablakra a főablakból.
Mindez csak mellékesen használható a sütis módszer mellett, mert az opener létezése teljesen bizonytalan.
15

Ügyes

Poetro · 2012. Május. 21. (H), 11.30
Ügyes, és köszönjük, hogy megosztottad a megoldást.
16

+1

Pepita · 2012. Május. 21. (H), 12.26
Csatlakozom Poetro véleményéhez. Köszi!
17

Grat! :-) Az opener létezése

inf · 2012. Május. 21. (H), 12.38
Grat! :-) Az opener létezése miért teljesen bizonytalan? Ez böngésző függő? Ha a window.opener nem létezik, attól még a szülő ablakból megpróbálhatnád átvinni az értékeket a gyerekhez, hátha úgy mégis működik a kommunikáció. Ha esetleg küldenél egy példát az opener nem létezésére, amit tudunk tanulmányozni, azt megköszönném.

No közben én is írtam egyet. Amin teszteltem: ff 12.0, ie 9.08, op 11.52, ch 19.0.1. Mindegyik alatt létezett a window.opener, az onunload nem futott le opera és chrome esetén. Gondolom ki lehet váltani annak ellenőrzésével, hogy a window object, amit letároltunk tényleg él e. Az ablakokat azért __blank-ként hozom létre, mert ha a rendes nevüket kapnák, akkor egy böngészőben csak egy példány lehetne belőlük azzal a névvel. Amit még meg kéne oldani, hogyha a főablakkal kapcsolatot vesztenek az al-ablakok, akkor ne működjenek.

a.html

<script>
windowManager = {
	map: {},
	create: function (name){
		try {
			if (name == "")
				throw new Error("Invalid window name.");
			if (this.map.hasOwnProperty(name))
				throw new Error("Window "+name+" already exist.");
			var subWindow = window.open("b.html", "__blank");
			subWindow.name = name;
			this.map[name] = subWindow;
		} catch(e){
			alert(e);
		}
	},
	setContainer: function (container){
		this.container = container;
	},
	displayWindows: function (){
		var display = "";
		for (var name in this.map)
			if (this.map.hasOwnProperty(name))
				display += "<div>"+name+":"+this.map[name]+"</div>";
		this.container.innerHTML = display;
	},
	close: function (name){
		delete (this.map[name]);
	}
};
window.onload = function (){
	windowManager.setContainer(document.getElementById("rows"));
	document.getElementById("button").disabled = false;
	setInterval(function (){
		windowManager.displayWindows();
	}, 1000);
};
</script>
<div id="rows"></div>
<form action="#" onsubmit="windowManager.create(document.getElementById('name').value) ;return false;">
<input id="name" type="text" />
<input id="button" type="submit" disabled="disabled" />
</form>
b.html

<script>
window.onunload = function (){
	window.opener.windowManager.close(window.name);
}
</script>
Persze cross-browser esetén ez esélytelen. Ha más domain van az al-ablakban, akkor kétlem, hogy engedné bármelyik böngésző a javascriptes kommunikációt, bár ez gondolom attól is függ, hogy milyen header-eket küldesz ki ezek mellett... Majd valamikor kipróbálom, hogy cross-domain hogyan megy.
18

Pontosabban fogalmazok, az

therest · 2012. Május. 21. (H), 14.10
Pontosabban fogalmazok, az window.opener úgy működik ahogy kell,csak a rendszer szempontjából ez azonban kevés, mert a user interakciója kiszámíthatatlan. Ha az adott fülön történik a tetszőleges interakció, akkor mivel a window változatlan akkor a gyermekablak el tudja érni a szülőt, még akkor is ha a felhasználó elnavigál majd visszatér, vagy ha frissít is. A gondok ott kezdődnek ha új fület nyit, és a régit bezárja, mert ez is elképzelhető.

A beforeunload,unload,close ezeket eléggé megnézegettem, és nekem úgy tűnik, nem sikerült egyetlen eseményt sem találni a böngésző fejlesztőknek (bah), ahol tutira adnának esélyt az oldalnak valamiféle bezárás előtti akcióra.

A cross-domain dolgokkal még hatalmas szívás lesz, amikor integrálni kell más rendszerekbe, előre fogom a fejem.
19

Hát nem kis fába vágtad a

inf · 2012. Május. 21. (H), 14.17
Hát nem kis fába vágtad a fejszéd... :D Sok sikert!
20

Alternatívák?

Hidvégi Gábor · 2012. Május. 21. (H), 15.40
Miért nem csinálod meg Flash-ben vagy bármiben, ahol saját ablakkezelőt írhatsz?
21

Flash esetében is elveszik a

therest · 2012. Május. 21. (H), 16.06
Flash esetében is elveszik a tartalom elnavigálás/frissítés esetén.
A felhasználók egy része amellett, hogy nem képes megérteni, hogy nem frissíthet(mert neki nem elég a percenkénti status update), vagy navigálhat el (tesztere válogatta eddig, de simán voltak akik amíg játékra (ellenfélre) vártak, meg akartak nézni valami youtube-on), kellőképpen arrogáns ahhoz, hogy úgy vélje neki van igaza. Az ablak bezárást mindenki ismeri, és érti, hogy az azt jelenti, hogy akkor annak ami az ablakban volt kaput.
Popupokban szépen le van választva az adott játékhoz szükséges rendszer, gyakorlatilag egy külön kis "app"-ként működik, kommunikál a szerverrel, stb.

Utolsó érvként azt mondanám, hogy bár a flash pont jó játékokhoz, animációkhoz, szerintem nem érdemes már a lobbit, és a többi hasonló funkciót abban megoldani. Itt a hml5, websocket-ek egyéb hasznos funkciók, adja magát, hogy minden mást a konkrét játékon kívül html+js alapon csináljak meg, és így pár év múltán, amikor már alap lesz a technológia nem kell flash alól áthúzni az egészet.
(Ez teljesen személyes vélemény, semmi html5 vs flash vitát nem akarok elindítani, mert mindkettőt nagyon jónak tartom, csak másra).