Saját JavaScript event dispatch-elése Flash-ből

Igen, ez a nagy kérdésem, hogy hogyan is lehetne ezt? Flash-ben bekövetkezett eseménykor szeretném, ha értesülne róla a JavaScript, tehát, hogy a beágyazott Flash Applet egy JavaScript event-et dispatch-eljen.

Valaki tud rá megoldást?

Nem, a fix metódusnév meghatározása nem jó, az nem Event driven megoldás lenne, és nekem nem is jó most!

Update: Kicsit kifejteném, mert kaptam visszajelzést, hogy nem eléggé érthető.

Amikor rákattintunk egy gombra, akkor az egy "click" típusú Event-et dispatch-el. Ugyanakkor lehetőségünk van arra is, hogy saját típusú Event-eket dispatch-eljünk, amikor csak akarunk. Ugyanilyen "tudással" bír az általunk beszúrt <object /> elem is, ami a fentebb említett Flash Applet-ünket tartalmazza. Na, én ebből a Flash Applet-ből szeretnék valahogyan az őt tartalmazó <object />-ünkön egy saját típusú Event-et dispatch-elni.

Ha valaki még mindig nem értené, szívesen elmagyarázom bővebben!

IPC2008 — Architectures for scaling AJAX applications

Igazából nem volt szó másról, minthogy egy oldal lekérésekor a teljes megjelenítési időnek:

• a 10%-a szerver-oldalon történik;
• a maradék 90% viszont a kliensnél, így ezen lehet a legtöbbet gyorsítani
  • a kliensnél 10% a HTML letöltése és feldolgozása
  • a maradék 90%-on osztozkodnak a JavaScript, CSS és egyéb média file-ok.

Az oldal felépítési optimalizációról később szeretnék majd írni, mivel úgyis kell belőle egy előadást tartanom a cégnél.

Ezen kívül sokszor elhangzott a widget kifejezés, mely most számomra új értelmet nyert. Itt most nem arról volt szó, hogy egy 3rd party widget-et szúrsz be az oldaladba, és ez tök jó lesz, hanem, hogy az oldalad felépítéséből adódóan — a HTML oldalak dobozokból épülnek fel — ezekre a dobozokra külön entitásként, widget-ként kell tekinteni, és egyesével érdemes őket lefejleszteni, kezelni. A közöttük fellépő interkaciót pedig ún. publish/subscribe módszerrel megvalósítani, ami a gyakorlatban event-ekre propagálást jelent JavaScript-ben.

Szó volt még a Client-side template-ekről, amiknek én nem nagyon látom értelmét, pláne, hogy azokat a szervertől kérnénk le minden esetben. Persze ha igény van rá, akkor kifejthetem!

IPC2008 — Mai napra várható előadások

• Architectures for scaling AJAX applications
• The Power of Refactoring
• Keynote — Web Standards to make life easier
• Ignore the DOM

Majd igyekszek írni mindegyikről, igérem!

IPC2008 — Partytime

Azt kell, hogy mondjam, a helyiek kitettek magukért rendesen! A szervezés nagyon jóra sikerült, a kaják és minden egyéb remek, azt hiszem a képek magukért beszélnek!

IPC2008 — WebSocket az Internet új úttörője

Bevezetés

Ma egy teljesen jó Keynote-on sikerült részt vennem.

A Kaazing.org egyik alapítója, Jonas Jacobi beszélt a jelenlegi HTTP hátrányairól. Legfőképp a Half-Duplex problémát és a ma egyre terjedő RI alkalmazások — számára a RIA "Richer, and Interactive Applications"-t jelenti — miatt felvetődött igényeket taglalta.

Előkerült, hogy a w3c és a HTML5-öt fejlesztő egyéb csoportok 2022-re tervezik kiadni a végleges specifikációt, ugyanakkor elmondta, hogy nem kell aggódnunk, azért is ilyen távlati időpontokat adnak meg egy-egy specifikáció véglegesítésére, mivel ha azt mondanák, hogy a specifikációt mondjuk 2010-re véglegesítenék, akkor azt megvárnák a böngésző-fejlesztők és ezzel önmagunkat hátráltatnánk. Emiatt viszont, hogy 2022-re tették a véglegesítés időpontját, a böngésző-fejlesztők apránként — ahogy az a <canvas> elemmel is megtörtént —, a véglegesítése előtt már implementálni kezdték.

Megoldás (?)

Hogy mi az, amivel Jacobi a megváltás reméli számunkra, RIA fejlesztőkre? A neve WebSocket. Igazából nem másról van szó, mintsem, hogy engedjék a böngészők, hogy hozzáférjünk a TCP réteghez, ami ugyebár a HTTP alapja, és így kétirányú, Full-Duplex kapcsolatot építhessünk ki.
var myWebSocket = new WebSocket('ws://my.example.com/application');


Ennyi a kód, amivel létrehozhatunk majd JavaScript-ben egy ilyen WebSocket-et. Ennek az objektumnak három Event Handler-t állíthatunk be:

• Open
• Message
• Close

Open

Amikor a kapcsolatunk létrejött hívódik meg.

Message

Minden, a szerver által push-olt üzenetkor hívódik meg. A kapott üzenetet az Event Handler-nek átadott event objektumon keresztül érhetjük el.

Close

A kapcsolat lezárásakor hívódik meg. Ezt a lezárást mind a kliens, mind a szerver kezdeményezheti.

A lényege

A WebSocket Server bármikor küldhet üzenetet a kliens számára, így nem kell a kliensnek a mai megoldásokkal időközönként ping-elni a szervert. Ezzel a megoldással időt, pénzt spórolhatunk meg:

• Időt és pénzt, mert az ilyen alkalmazások (IM, mail, tőzsdei figyelő, játékok, stb.) fejlesztési ideje töredékére csökken.
• Időt, mert az eseménykor azonnal megjelenik a kliensnél az eredmény, nem csak X idő múlva.
• Pénzt, mert felesleges sávszélességtől kíméljük meg a szerverünket.

Nagy jövőt látok a WebSocket-ben, szerintem hatalmas fejlődés lesz az internet történetében ez, az 1992-es HTTP modellt megújító megoldás! Mostmár csak a böngészőknek kell implementálniuk a WebSocket-et, amint lesz belőle draft specifikáció.

IPC2008 — PHP Konferencia 2008, Mainz, Németország

Kint vagyok, majd később írok is az itt látottakról, hallottakról. Két előadásonvagyoktúl, remélem a többi is ilyen jó lesz!

• IPC2008 — WebSocket az Internet új úttörője

jEdit nem indult el Java frissítés után...

..., mindezt tegnap vettem észre. Rég nem kellett már használnom, ezért sem tűnt fel, pedig az Apple még szeptember végén adta ki ezt a frissítést. Hát igen, mostanában — már vagy másfél éve — nem dolgozok itthon egyáltalán, emiatt sem volt a jEdit-re szükségem. Most is csak egy bent felfedezett Internet Explorer-es renderelési bugot akartam megfejteni, és írni róla ide, emiatt indítottam volna el. Nem indult! Google-ben keresés után akadtam rá erre a cikkre. Ami érdekes, hogy ha a jedit symlink-et a megfelelő útvonalra is módosítom, akkor sem fog működni! Vajon ez az egész helyzet amúgy most kinek a hibája? jEdit fejlesztők csináltak valamit szarul, vagy az Apple módosított önkényesen? A /System/Library/Frameworks/JavaVM.framework/Versions/ alatt egy rakat symlink (dőlt) és könyvtár található:

• 1.3 ⇒ 1.3.1
• 1.3.1
• 1.4 ⇒ 1.4.2
• 1.4.1 ⇒ 1.4
• 1.4.2
• 1.5 ⇒ 1.5.0
• 1.5.0
• 1.6 ⇒ 1.6.0
• 1.6.0
• A
• Current ⇒ A
• CurrentJDK ⇒ 1.5

A jEdit eredetileg a A/-ra mutatott, szerintem a legjobb itt is a Current/ lett volna, de szakértők szerint ez sem megoldás, mivel ilyenkor nem kapta volna meg az ott található JavaApplicationStub az eredeti könyvtárat, és emiatt nem működött a frissítés után a jEdit. Szóval a megoldás az az lett, hogy a JavaApplicationStub-ot át kellett másolni jedit néven. Bámulatos. És akkor most a következő Java VM frissítéskor mi lesz?

Zuhanás (The Fall)

Megnéztem, és már az elejétől ámulatba ejtőek a képek, amik fogadnak. Végig kísérnek az élénk színek, a látványos elemek, a történet... és hát a mi kis hősnőnk, Alexandria (Catinca Untaru): tüneményes, aranyos, édes, megfogó! És remekül játszik!

Szükséges a 10 ujjal gépelés?

Nemrég megjelent egy blogmark a weblabor.hu-n egy cikkről. A cikk írója szerint 10 ujjas gépelés nélkül nem lehet az ember jó fejlesztő. Szerintem pedig nem a gyors írás a jó ismérve a jó fejlesztőnek, hanem az, hogy jól működő —, hiba mentes — kódot írjon. Vagy talán nincs igazam?

Példálozzunk az Apple, vagy a Microsoft fejlesztőivel. Persze, tök jó lenne, ha "évente" jönnének az új OS X-ek, meg Windows-ok, de nem hiszem, hogy ezen múlik.

Vagy tanuljak meg én is 10 ujjal gépelni, nem csak 8-cal, és akkor én is tök jó leszek, minden háttérszemlélet nélkül?

Adobe Flash Player és Internet Explorer FlashVars bug

Amint azt ígértem korábban, egy újabb felfedezett bug-ot írok le. Úgy egy héttel ezelőtt ráment egy egész délutánunk, hogy rájöjjünk a megoldásra.

Kitérő

Egy eléggé nagy oldalnak a sitebuildere vagyok, így eléggé érdekes dolgokba tudok belefutni. Egy más oldalakba beágyazható videólejátszót készültünk a publikum számára elérhetővé tenni, viszont a tesztek során — ami persze a fejlesztés során minden más böngészőben (fejlesztés alatt Mozilla Firefox és Safari böngészőket használok) jól működött — előjött, hogy Internet Explorer-ben természetesen nem működik tökéletesen.

Alap elgondolásban úgy működött volna az egész, hogy a felhasználó egy állandó kódot ágyaz be az oldalába, mert ezt természetesen később nem tudjuk megváltoztatni, ahogy a youtube.com sem tudja. Így a beszúrt lejátszó útvonala tartalmazta volna a videó azonosítóját és query string-ben egy szín hexa kódját, ami a videó háttérszínét határozhatja meg.

Ezután a megadott URL mögötti kis okosság tovább dobja a lejátszó aktuális címére, query string-ben a videó azonosítójával, a megadott színnel és egyéb paraméterekkel felvértezve.

Példában: <object/> forrásának ez van megadva: http://example.com/videoid?color=eeeeee, ami átirányit így: http://example.com/player.swf?id=videoid&color=eeeeee&foo=...

Szóval ez volt az alap elképzelés, de valamiért csak a color változót látta a lejátszó, és nem értettük! Végül rájöttünk!

Megoldás

Az ActiveX-es Adobe Flash Player valamilyen okból kifolyólag a beszúráskor, tehát a HTML-ben megadott query string-et veszi alapul flashvars-nak. Az átirányítást figyelembe veszi, tehát a végleges cél flash file-t fogja betölteni, de az ott megadott query string-et már nem fogja flashvars-nak beadni. Ez csak akkor történik így, ha a HTML-ben van query string. Ha nincs, akkor az átirányításkor megadott query string-et teljes mértékben felveszi a flash applet. Megoldásként tehát azt alkalmaztuk, hogy nem color=eeeeee, hanem a videó azonosítójához hasonlóan, az URL részeként kell átadni.

Példában: http://example.com/videoid/eeeeee és ezt már átirányíthatjuk az előbb megadott címre, és az applet is jól fogja lekezelni.

Szóval újfent azt mondom, hogy utálom az Adobe Flash-t!

Flash beágyazása jQuery-vel

Minden simán ment, amíg a flash applet nem akarta használni az ExternalInterface-t, ugyanis bár meghívta a JavaScript metódust, de annak visszatérési értékét már nem kapta meg. Internet Explorer alatt. Csini mi?

Három napi bugkeresés után rájöttem, hogy ha a jQuery append(), prepend() vagy html() metódusok egyikével szúrom be a generált HTML-t, akkor bizony nem működik, ha pedig innerHTML-lel, akkor igen. Az már külön hab volt korábban a tortán, hogy ha nem generálok Internet Explorer alatt az applet-nek ID-t, akkor ugyan nem kapja meg az applet ígyse-úgyse a visszatérési értéket, de legalább JScript hibát is dob.

Adobe Flash Player 10

Mostanában jelent meg az Adobe által megvásárolt Flash Player új, 10-es verziója. Szükség is volt az új verzió kiadására, mivel nemrég jelent meg a CS4, amit telepakoltak ugye új "jóságokkal", aminek sokan örültek, mert most majd húdejó csillivilli effektekkel tudják ellátni, az amúgy is lassan erőművet igénylő oldalaikat.

Értem én, hogy fejlődik a technika, újabb és újabb ötleteket gyártanak Adobe-nál is, amit szeretnének millió oldalon használva látni, és milliárd gépen futni látni. Viszont mi lesz majd azokkal a hibákkal, amiket — ugye egyrészt az új funkciókkal beletettek, és amiket — korábban benne hagytak?

Későbbiekben — eddig kettőt biztosan — fogok írni ezekről az idegesítő hibákról, amiket munkám során megtapasztaltam vele kapcsolatban. Ezek nem csak a Flash használatával, belső működésével kapcsolatos hibák lesznek majd, hanem a már elkészült applet-ek beszúrása kapcsán előtárulkozó idiótaságok is.

Szóval köszöntsük az új verziót, várjuk a hibajavításokat (9-es playerből 124 release készült, szóval lesznek)!

Fotóalbum nyomtatása

Szeretném a nyaralások alkalmával készített fotókat könyv formájában is a polcra helyezni. Erre annó ugyebár alpból a fotóalbumot használtuk. Kétoldali ragasztó, előhívva a fotó az ofotértben, és már ott is díszelgett.

Manapság a digitális időkben ez nem annyira móka, sokkal nagyobb az elvárásunk.

Normális fotóalbumot akarok, amit akár a könyvesboltban is árulhatnának. Erre több megoldás is létezik:

• Otthon kinyomtatom, könyvkötészetbe elviszem: hátulütője, hogy nem tudod jó minőségben kinyomtatni szerintem otthon, pláne nem tartósan, és nem olyan minőségű papírra. A borítót meg pláne nem tudod megcsinálni jól!
• Gyorsnyomda: nem érzem, hogy szintén jó minőséget produkálhatna, jó áron (egy példány).
• Digitális nyomda: jó minőség, valószínű egy példány miatt vagy nem állnak velem szóba, vagy horribilis áron.
• Online könyvrendelés: ez tűnik a megfelelőnek, de vajon melyik? Van kismillió, mint az interneten bármiből (Apple Book, Blurb, VioVio, MyPublisher, etc.)
• Apple Book: a választásom.

Azért is az Apple Book, mert a neten különböző blogokat olvasva ők nyújtják:

1. a legjobb minőséget;
2. elfogadható árat;
3. gyors teljesítést (állítólag 1 hét);
4. nagyon jó supportot (tapasztaltam már, tényleg jók!).

Vagy van valakinek más javaslata? Esetleg próbálta már valamelyiket?

Amit igazából szeretnék, az elvárásaim:

• kemény borítás;
• úgy 80-90 oldal;
• remek minőség.

Beköszöntő

Újra elérkezettnek láttam az időt arra, hogy megosszam a publikummal a véleményeimet, szenvedéseimet, ötleteimet, tapasztalataimat. Remélhetőleg lesz majd itt szakma (web), fotó és új vásárlt dolgok által keltett érzésekről szóló bejegyzések is. Ez egy blog szerűség, amit naplóként is szoktak emlegetni, szóval ha valakinek nem tetszik a véleményem, leírhatja — ha engedem majd —, vagy nem kell legközelebb ide látogatnia!