'webfejlesztés' kategória archívuma.

Hogyan működik a CSS float?

Ritkán látni olyan leírást, mely a CSS float tulajdonsága kapcsán nem csak azt mondja el, hogy eredetileg mire szánták, illetve hogy hogyan működik, de azt is részletesen, ábrákkal és példakódokkal bemutatja, hogy mire és hogyan használható, milyen problémák léphetnek fel, s ezekre mi a megoldás. Az All About Floats című írás ezt a feladatot elég jól teljesíti. Tudtad, hogy a “float” gumimatracot is jelent?

Lebegő Homer

A képekkel elég gazdagon (és jól) illusztrált írás bemutatja, hogy a float tulajdonság segítségével lehet egész oldalrészek, és kisebb elemek megjelenését is módosítani, és felsorolja a lehetséges problémákat, mint a csak floatolt elemeket tartalmazó elem “összecsuklása”, a clear és az új sor kapcsolata, a túl hosszú tartalmak miatt széteső oldal. És persze részletes választ és megoldási módokat is kínál.

A float kapcsán azért még érdemes megemlíteni a Floatutorial című összefoglalót, mely konkrét példák megvalósításán keresztül járja be ezt a kérdéskört, a Smashing Magazine CSS Float Theory írását linkekkel gazdagon illusztrálva, és magát a W3C “szabványt” is persze.

A DOM defaultValue trükk

Azt hiszem nem sokan ismerik a beviteli elemek (<input/> és <textarea/>) már 2000-ben DOM által specifikált, és a böngészők által is támogatott egyik lehetőségét, a defaultValue (és defaultChecked) tulajdonságát. Ha beviteli mezőkbe szeretnénk példa vagy súgó szöveget elhelyezni amíg azok nem kerülnek szerkesztésre, akkor ezek a tulajdonságok sokat segíthetnek.

"HTML sorcerer"

Az input és textarea elemek defaultValue tulajdonsága azt az értéket tartalmazza, mely a value segítségével eredetileg be volt állítva (vagy pedig amit korábban beállítottunk – írható érték). Ezt tudjuk kihasználni egy súgószöveg elhelyezésére:

<input id="email" type="text" value="ide írjad az email címed" />

Majd pedig hozzárendelünk JavaScript eseménykezelést:

var iEmail = document.getElementById("email");
iEmail.onfocus = function() {
  if (this.value == this.defaultValue) {
    this.value = "";
  }
}
iEmail.onblur = function() {
  if (this.value == "") {
    this.value = this.defaultValue;
  }
}

Ha az input mező fókuszba kerül, és a súgószöveg az értéke, akkor töröljük azt, ha elveszti a fókuszt, és még nem írt bele a felhasználó semmit, akkor pedig visszaállítjuk az eredeti értéket.

Két dolgot lehet még javítani a kódon. Az egyik, hogy alapból adunk egy class="default" osztályt az elemnek, ami felel a szöveg elszürkítéséért (color: #888; – vagy bármilyen más módon jelzi a felhasználó számára, hogy ezt nem ő írta be. Ezután a fókuszkor nem az egyezőséget, hanem ennek az osztálynak a meglétét kell ellenőrizni (JS kódkönyvtártól függő módon vannak erre függvények, pl. this.hasClass("default")), és ha megvan akkor leszedni, fókusz elvesztésekor pedig ha üres volt a mező értéke, akkor az érték visszaállítása mellett visszaállítani az osztályt is (this.removeClass("default") és this.addClass("default")). Ezzel azt a hibalehetőséget is megoldjuk, ha a felhasználó ugyanazt az értéket írja be, mint ami a súgószövegünk volt.

A másik javítási irány a form elküldésekor a súgószövegek eltüntetése az input mezőből, ez kiegészíthető a mező kitöltésének ellenőrzésével, kliens oldali validációval is persze. A szerver oldali validációt lehet, hogy célszerű kiegészíteni a súgószövegre szűréssel is.

A defaultValue mind input, mint textarea esetében működőképes, sőt, a defaultChecked segítségével rádiógombok, checkboxok esetén is lekérdezhető az alapbeállítás (már kérdés, hogy ott nincs sok értelme a fent leírt módszernek).

Nem mondod!? Ugye?

Még a mai napig is tartja magát pár hülyeség webfejlesztői körökben. Amikor meghallom ezeket a gondolatokat Mr. Webmester tolmácsolásában, az az érzésem támad hogy én vagyok Pókember. Íme a Webakadémia szégyenfala. Tudsz hasonló idézeteket?

Mr. Webmester

(1) “Az Internet Explorer a legszabványkövetőbb böngésző, a többi böngésző is másolni igyekszik, nézd meg például az XMLHttpRequest megvalósítást!” Hát nem. Az Internet Explorer 6 egy modern böngészőnek számított amikor megjelent, de nem volt tökéletes. Több nem szabványos lehetőséget is implementáltak bele a verseny hevében, így adatlekérdezést is oldalfrissítés nélkül. Ezek a megoldások azonban nem voltak szabványosak, és nem is lettek azok csak azért, mert az IE6 támogatta azokat. A szabványok nem feltétlenül változtak, de az Internet Explorer bizony elavultnak számít ma már. Az új Internet Explorer 7 egy nagyon kicsit jobb, de szabványközelíségről majd csak az 8-as változat esetén beszélhetünk majd. A többi böngésző folyamatos fejlesztéssel, új verziók gyakori megjelenésével bizony hatalmas előnyre tett szert a szabványok követését illetően.

(2) “Ne használjunk az oldalon PNG-t, mert az IE6 nem támogatja az átlátszóságot!” Használjunk nyugodtan PNG-t, az IE6 is támogatja. Az átlátszóságát is. Amit nem támogat, az az áttetszőség. Az áttetsző PNG-knek tényleg vannak az IE6 miatt korlátai, de attól még a PNG simán használható, és sokszor tömörebb képet eredményez a GIF-nél.

(3) “A JavaScript egy nagyon lassú, buta és ronda nyelv, kínszenvedés benne a fejlesztés.” A JavaScript szabványosított változata, az EcmaScript egy nagyon modern nyelv. Ehhez egy IE6 implementáció is közel áll. Funkcionális, objektum alapú programozást, moduláris fejlesztést tesz lehetővé, egyáltalán nem nevezhető buta nyelvnek. Egyes megvalósításai lehet hogy lassúak, de ez az adott implementáció miatt van így, nem a nyelv miatt. A fejlesztés pedig egyáltalán nem kínszenvedés JavaScript-ben, szintén csak az egyes implementációkkal van, lehet gond. Ha az elterjedtebb böngészők alatt működő és jól működő kódot szeretnénk írni, akkor ne a JavaScriptben keressük a hibát, hanem nézzünk körül pl. a DOM (és egyéb) szabványokat illetően.

(4) “A JavaScript a Java nyelv script változata.” Nem, a két nyelvnek a nevükön kívül gyakorlatilag semmi közül egymáshoz (ez sem igaz így, de hát Leonardo DiCaprio és a dobókocka hasonlóságáról sem szoktunk beszélni csak azért, mert mindkettő atomokból épül fel a tudomány mai állása szerint). A konkrét történet fellelhető például a Wikipédián.

(5) “Az IE és a Firefox nem egyformán értelmezi a margint.Egy oldal készítésekor első lépés a DOCTYPE beállítása. Utána bizonyos hibáktól eltekintve (pl. IE6 féle double-margin) alapvetően ugyanazt a szabványos dobozmodellt használja a fellelhető böngészők 99.999%-a.

(6) “A jobb egérgomb letiltásával hacker biztossá tettem az oldalt!” Ezzel maximum egy naív ügyfelet lehet jól átverni. Egyrészt a legtöbb böngészőben elég egyszerűen letiltható a JavaScript és így az egérgomb letiltása is megszűnik, másrészt az oldal használhatósága rendkívül romlik. JavaScript letiltása nélkül is könnyen kinyerhető az oldal tartalma, ha más nem a képernyő mentésével…

(7) “Java Script-ben hogy lehet meghívni mysql adatbázist?” Rossz a kérdés, legalábbis ha egy böngészőben futó JavaScript (egybeírandó, S nagybetűs) segítségével szeretnénk elérni a szerveren levő MySQL-t (ezt meg így kell írni). Konkrétan a válasz így az, hogy sehogy, a részletesebb válasz pedig az, hogy közbe kell iktatni egy szerver oldali PHP kódot, amivel már el lehet érni az adatbázist.

(8) “PHP-ből hogyan tudok alert() ablakot nyitni?” Ugyanaz a probléma, mint az előbb, összemosásra kerül a kliens oldal és a szerver oldal az illető fejében. Tanulmányozni kellene azt, hogy mitől, milyen folyamat során kerül megjelenítésre a böngészőben egy weblap. PHP-ből “sehogy” sem lehet alert() ablakot nyitni a böngészőben, de össze lehet rakni egy olyan weboldalt, aminek része egy JavaScript kód, ami lefut az oldal megjelenítésekor.

(9) “Táblázatokkal olcsóbb és hatékonyabb a layout elkészítése.” Nem az, ma már semmiképp sem az. A sitebuilder szakmának nem volt könnyű az átállás a beidegződések miatt, de CSS-t használni layout készítésére kevesebb HTML kódot, kevesebb képet, kliens oldalon nagyobb arányban cache-elhető kódrészeket, gyakorlatilag gyorsabb oldalt eredményez. A legtöbb igény megvalósítható CSS alapú layouttal, s míg vannak kivételek, ezeknél sem árt elgondolkodni, hogy tényleg úgy akarjuk-e. Sajnos a jelenlegi CSS szabványok sem a layoutra termettek, és bizony hasonló hackelésnek számítanak mint a táblázatok anno, de így is jóval több előnyös oldala van ennek a megoldásnak, mint a táblázatosnak volt.

Figyelem, pár idézet majdnem szó szerint lett átvéve innen-onnan, 2008-as fórumbejegyzésből! A szomorú amúgy nem az, hogy ilyenek előfordulnak (de, az is az), hanem hogy nem ismerek olyan magyar nyelvű oldalt amelyre át lehetne irányítani az abszolút kezdőket, és ahol átfogóan, korrektül össze lenne foglalva a webfejlesztés filozófiája, története, és hogy merre lehet tovább olvasgatni.

Ezzel a bejegyzéssel nem a kezdők pellengérre állítása a cél. Ha végképp nincs egy jó szavunk se valakire, akkor sokkal okosabb inkább egyedül hagyni, mint felesleges flame-t kiváltva válaszolni neki. Ha van időnk rá, akkor próbáljuk meg így vagy úgy a jó irányba terelgetni a kezdőket, ha válaszolunk nekik, akkor gondolkodjunk el hogy mit terjesztünk, ne írjunk le féligazságokat félinformációk alapján, és nézzünk utána a dolgoknak! Persze kezdőként sem árt, ha néha rákeresünk bizonyos témákra, mielőtt kérdeznénk valamit. És bár szép életcél, de ne akarjunk egy hétvége alatt összedobni olyan dolgokat, melyek kifejlesztése előzetes kutatások garmadáját, és több hónapos fejlesztési időt igényel. És tudást.

Mennyibe kerül egy honlap?

Bár nyilvánvalóan politikai ügy, és bár nyilvánvalóan nem kerülhet 200 millióba egy olyan honlap, mint a kormányszóvívő.hu, és már a csapból is ez a téma folyik, sokaknak azért jópár hülyeséget sikerült leírniuk a témában, ezért gondoltam hozzáteszem az én hülyeségeimet is. Ennél jobban már nem folyhat a csapból, ugye.

A kérdés kapcsán fontos látnunk azt a tényt, hogy nem a versenyszférában, hanem állami megrendelésre készült el a honlap. A közbeszerzés adottságai, a “nagy pénzek” miatt errefelé alapból drágább a honlapok készítése, mint amúgy azt általában gondolná az ember. De még ha a versenyszférában is vagyunk, sohasem fog egy hasonló minőségi weblap 100.000 Ft-ból elkészülni. Köszönöm, de 4 óra alatt készült gagyi honlapból (készülhet tőlem 1 hétig is) nem kérek. Hogy a jelenlegi honlap minőséginek mondható-e, azon persze lehet vitatkozni, de azért akárki akármit mond, legalább van egy összeszedett megjelenése. Sajnos profinak nem nevezhető sem a (látható HTML) kódja, sem a kialakítása, sem más okok miatt.

Az oldal nagy valószínűséggel Ruby on Rails-ben készült, erre lehet következtetni abból, hogy milyen JavaScript könyvtárat (Prototype), és hogy milyen kiszolgálót (Mongrel) használnak. Van más, Mongrelt használó, Ruby alapú megoldás is, de a RoR a legvalószínűbb. Ennek a környezetnek a használata Magyarországon mondhatni újdonságnak számít, nagyon kevés honlap mögött van ez a technológia, mivel a Ruby megjelenése a webfejlesztésben viszonylag új, és mivel normális üzemeltetéshez speciális kiszolgálót (Mongrel) igényel.

De lássuk, hogy mennyibe kerül egy ilyen honlap. Nagyságrendileg 1-1 cégvezetői, üzletkötői, rendszergazdai, designer+sitebuilderi és programozói hónap lehet mögötte, beleszámolva az olyan extra köröket is, hogy a döntéshozó politikus azt mondta, hogy a designt újra kellene csinálni, mert az a zöld árnyalat nem tetszett, vagy mert a dark egyelőre még nem divat az állami honlapokon. A rendszergazdának is meg kellett ismerkednie a Mongrellel, utánanéznie, hogy milyen módon lehet jól üzemeltetni, hogyan lehet védeni, stb. A hónapnyi munka lehet hogy nem hangzik reálisan, de már csak a bürokrácia miatt is az.

A cégvezető havi juttatását illetően ebben a közegben számolhatunk 1.5 millió Ft-os (járulékokkal, mindennel) fizetéssel, a többi résztvevőnél lőjük be ezt az összeget 800.000 Ft-ra (mégegyszer, nem ennyit kap kézhez). Ezek reális árak, el tudom képzelni, hogy akár még alul is becsültem az összegeket. Osztás és szorzás után így 4.7 millió Ft összeg jött ki az emberi költségekre. Ami a hardvert illeti, egy jódrága szerver 1.5 millió Ft-ra is rúghat. Licencdíjakról is szó volt, mondjuk hogy Oracle adatbázist tettek teljesen indokolatlanul az oldal mögé, ami legyen 1 millió Ft (fogalmam sincs az Oracle áráról, valószínűleg olcsóbb). Ez eddig 6.7 millió Ft.

A fenntartásért, üzemeltetésért, adattöltésért is előre fizettek 1 évnyi költséget, itt mondjuk van 6 hónapnyi cégvezetői, 12 hónapnyi rendszergazdai, és 12 hónapnyi adatfeltöltői díj. Az adatfeltöltő nincsen jól megfizetve, legyen az ő díja havi 400.000 Ft. Így erre 23.4 millió Ft összeg jön ki. Az ez idő alatt fellépú fejlesztői, designeri költségek mondjuk benne vannak már ebben az árban.

Összességében 30.1 millió Ft-nál járunk, ami akármennyire is felháborító egy ilyen honlapért, és bőven felette van annak a díjnak, amennyit elkérne a honlapért egy versenyszférában dolgozó nagyobb cég (mondjuk 5 millió), de nagyságrendileg sajnos reális összeg. A különbség azonban még így is 170 millió Ft, amit egyszerűen fogalmam sincsen hogy mire költöttek.

És azt is nehéz megérteni, hogy miért készült el a honlap egyáltalán, amikor már létezik egy gyakorlatilag ezt a funkciót is ellátó honlap, a meh.hu (ennek történetesen én csináltam a HTML+CSS kódját jópár évvel ezelőtt, de ez egy másik történet).

Mivel a kérdés politikai és nem szakmai, ezért teljesen feleslegesen született meg ez a blogbejegyzés. Politikai töltetű mondatot tartalmazó hozzászólások egy az egyben ki lesznek moderálva, mert nem érdekelnek még a józan szidalmazások, kesergések sem.

Firefox 3 újdonságok – webfejlesztői szemszögből

Kedden megjelenik a Firefox 3, ennek kapcsán átnéztem, hogy milyen újdonságokat kínál webfejlesztői szemszögből. Ezt mondjuk nem nehéz, végigolvastam ezt a listát: Firefox 3 for developers. Ebben a bejegyzésben innen szemezgettem: pár érdekesebb újdonságot sorolok fel.

A kép egyébként egy poén a Firefoxban (illetve a béták információs oldalán voltak robotos grafikák), ha megnézzük (FF3 alól) az about:robots oldalt, akkor olvashatjuk a szöveget.

Online/offline állapotváltás események

A WHATWG felől érkező szabvány vezette be az online/offline állapot lekérdezhetőségét, illetve a váltáskor lefutó eseményeket. A “navigator.onLine” értéke igaz vagy hamis lesz attól függően, hogy éppen van-e a böngészőnek internet kapcsolata, illetve két új esemény is van (az onclickhez hasonlóan), például:

<body ononline="alert('online lettünk!'" onoffline="alert('offline lettünk!'">

Bővebben az erről szóló Firefox doksiban. Ezeknek nyilván akkor vesszük hasznát, ha egy offline is működni képes alkalmazás megvalósításába fogunk bele.

Protokoll kezelők

Például webmail szolgáltatóknak lehet érdekes az a lehetőség, mely lehetővé teszi JavaScriptből adott protokollhoz (itt most a mailto:) URL hozzárendelését. A JavaScript függvény meghívásakor a böngésző rákérdez, hogy valóban regisztrálni akarjuk-e ezt a szolgáltatást, és ezentúl ide lesznek irányítva ezek a kérések.

CSS újdonságok

Olyan CSS újdonságok nincsenek, melyek a napi lehetőségeinkre hatással lennének, az inline-block, inline-table, font-size-adjust, a negatív z-index helyes kezelése, a keretek lekerekítésének javítása (háttér rondán nézett ki nagy radius beállításakor) voltak érdekesek számomra.

DOM újdonságok

A DOM adta lehetőségek között vannak olyanok, melyek érinthetik a napi feladatainkat is, persze csak óvatosan használjuk ezeket (nem minden másik böngészőben vannak jelen!). Ilyenek az Internet Explorerrel való kompatibilitást javító, annak nem szabványos lehetőségeit megvalósító clientTop, clientLeft, elementFromPoint, oncut, oncopy, onpaste lehetőségek. Értelmezésem szerint ezek nem azért kerültek megvalósításra, mert a Firefox olyannyira közelíteni szeretne az Internet Explorerhez, hanem mert ezek a lehetőségek egyszerűen hasznosak.

A JavaScript függvénykönyvtárak által behozott, a HTML 5 által szabványosított megoldás, a getElementsByClassName() is hasznos lehet, nem az újdonsága, hanem a sebessége miatt.

A window.postMessage lehetőségét is a HTML 5 által szabványosította, ez a metódus különböző domainek között üzenetek küldését teszi lehetővé, viszonylag biztonságos módon.

JavaScript 1.8

Bár hatalmas jelentősége valószínűleg nem lesz a webfejlesztő életében (a kiterjesztés fejlesztők minden további nélkül tudják használni), de jó, hogy a JavaScript nyelvet is folyamatosan fejlesztik, és most a JavaScript 1.8 be is kerül a böngészőbe. Az nem túl tiszta, hogy az oldal végén emlegetett JSON kódolás, dekódolás végül bekerül-e a Firefox 3-ba, az egy jó lehetőség lenne biztonságos és gyors JSON kommunikációra.

Egyebek

Azért persze egy halom más újdonság is van Firefox 3-ban, a canvas-ra szöveg írásának lehetőségétől a hasFocus támogatásig, a fenti oldal szépen fel is sorolja ezeket. A felhasználó számára a legfontosabb újdonság persze nem ezek, hanem a helyrerakott memóriahasználat lesz, ami a tapasztalataim szerint egész jól sikerült.

Webakadémia vs. iPhone

Az Apple (indirekt) bejelentette, hogy érkezik az iPhone Magyarországra is, ennek örömére bejelentjük a Webakadémia iPhone Editiont, avagy a blog iPhone-ra optimalizált változatát. A megtekintéshez nem kell semmi különöset tennünk, csak meglátogatni az oldalt iPhone vagy iTouch segítségével.

Webakadémia iPhone változat

Persze hatalmas fejlesztéseket nem hajtottam végre, egyszerűen felpakoltam WPTouch nevű kiterjesztést az oldal mögött levő WordPressre, és már működik is a dolog. A mondanivaló azonban nem ez, hanem az, hogy ha valóban jön hamarosan Magyarországra az iPhone, és valóban jó áron (akár tényleg 199 dollárért, akár bárhol 100.000 Ft alatt, ez azt jelenti, hogy itt az ideje elkezdenünk weblapjainkat erre az eszközre is optimalizálni, mert divattelefon lesz az iPhone-ból. És még ha nem is lesz hatalmas arányban az iPhone-t használó közönség az oldalunkon, egy jó marketing eszköz lehet annak reklámozása, hogy támogatjuk ezt az eszközt.

Nitobibug – keresztböngészős debugolás

Bár a Firebug utolérhetetlennek látszik ha webfejlesztésről van szó – azok a próbálkozások, melyek más böngészőkön próbálták megvalósítani a funckióit eléggé gyengére sikerültek (persze a fejlesztésük nem állt meg) -, most itt egy ígéretes, a főbb böngészőkön működő megoldás, a Nitobibug.

Nitobibug

A Nitobibug nem kínál semmi extrát, “csak” egy a Firebug konzoléhoz hasonló dives popup ablakot, ahova az oldal kódjából üzeneteket küldhetünk, és ahonnan lekérdezhetünk különböző változó értékeket. Még mindig elég távol van a Firebugtól a dolog, de ez már egy használható megvalósításnak látszik, például képes összetett objektumok értékének megmutatására is (szemben a Firebug Lite-tal, mely hasonló, de ezt nem tudja) – elérte azt a szintet, hogy elő fogom venni, ha Explorer alatt kell hibakeresnem.

A nem böngészőbe épített megoldás előnye, hogy egy ügyes kis bookmarkletet összedobva bármely weboldalba be tudjuk tölteni, így akár egy éles rendszert is tudunk a segítségével debuggolni különböző böngészők alatt.

Innen üzenem a Firebug fejlesztőinek, hogy nagyon várom már a Firefox 3 alatt is használható megoldást, a jelenlegi béták bár javulnak, de nagyon sok memóriát zabálnak.

SquirrelFish: új JS motort kap a Safari

Új JavaScript motort kap, kapott a Safari, illetve a mögötte levő WebKit böngészőmotor – a motor kódneve SquirrelFish. Az új JavaScript virtuális gép gyorsabb az összes eddigi konkurenciánál, konkrétan az előző WebKit megoldásnál, és a Firefox SpiderMonkeynál és a Flash ActionScriptjéből örökölt, a tervek szerint a Firefox jövőbeni JavaScript motorját adó (FF4-től) Tamarinnál is. A “mókushal” (használt magyar kifejezés) egyébként akármilyen hülyén is hangzik, egy létező alfaja(?) a halaknak, latinul Holocentrinae néven szokás emlegetni őket, és kifejezetten bamba a fejük.

Kis biológiai kitérőnk után visszatérve a JavaScript virtuális gépekhez, a SquirrelFish egy elég modern alapokra építkező, mindenféle bűvszót felsoroló motor, mely már akár ki is próbálható (WebKit Nightly Builds), aki a pontos részletekre kiváncsi, az olvassa el a bejelentést. További jó hír, hogy tovább szeretnék optimalizálni a motor teljesítményét, és elviekben még van is hova. A sebességnövekedés mindenesetre látványos (hozzáteszem, a WebKit 3.1-ben a gyorsítást részben különböző ügyes trükkökkel érték el, nem pedig a konkrét motor gyorsításával):

A hír azért érdekes egyébként, mert egyre több helyen találkozunk JavaScriptre épülő megoldásokkal a weben kívül is, és a modern JavaScript motorok képesek megközelíteni (ha nem meghaladni) az egyéb virtuális gépekre építő nyelvek sebességét, s mivel maga a JavaScript még bőven modern nyelvnek is nevezhető, egy egyre jobb és szélesebb körben is használható nyelvet fogunk kapni. Persze ha a böngészőkben is nő a teljesítmény, és egy AJAX-os oldal nem fekteti kétvállra a böngészőnket, akkor az se egy utolsó hír.

Kipróbálva a fent belinkelt WebKit-et, szubjektíve nem éreztem jelentős gyorsulást JavaScriptet extrém módon használó oldalaknál, de az tény, hogy szépen és gyorsan teljesített a motor. A Mozillások is végeztek teszteket (ennél objektívebb módszerekkel), így jött ki, hogy 40-50%-kal gyorsabb ez a motor a Mozillás implementációknál. Persze ők sem fognak a babérjaikon ülni – a lecke fel lett adva. Jó látni, hogy erős fejlesztések vannak ezen a téren.

Elindult a Netvibes.org

Elindult a Netvibes.org címen a Netvibes nyílt forrású projektjeivel foglalkozó oldala, és Párizsban elkezdődött az ezzel kapcsolatos fejlesztői party is. A lépéssel a Netvibes gyakorlatilag közzéteszi oldalának alapjait, bízva abban, hogy így egy widget platform fejlesztői közösség alakulhat ki, mely további innovációkhoz vezethet a személyes kezdőoldalak terén, és még több érdeklődőhöz eljuthat ez a technológia.

A mostani nyitás egyből három komponens forráskódját teszi elérhetővé, ez az UWA JavaScript Runtime (az egyes widgetek futtatását teszi lehetővé saját oldalakon), és az Exposition névre keresztelt platform két szerver oldali része, az Exposition PHP Libraries (az UWA widgetek futtatásához szükséges szerver oldali komponenseket tartalmazó függvénykönyvtár), illetve az Exposition PHP Server, mely az UWA widgetek külünböző platformokra történő hordozhatóságát oldja meg.

UWA JavaScript Runtime

A csak JavaScript kódot tartalmazó csomag az UWA widgetek futtatását lehetővé tevő kódot tartalmazza, vagyis azt a függvénykörnyezetet, mely egy UWA widget számára elérhető. Aki átnézte már az UWA lehetőségeit, annak nem fog újat mondani a rendelkezésre álló függvények listája, ezzel együtt talán érdekes lehet a teljes forráskód akkor, ha valaki ki szeretné egészíteni a lehetőségeket további funkciókkal, illetve saját maga szeretné hosztolni ezeket a fájlokat. Ezen komponensekkel válik lehetővé saját domainen, “inline” futtatni UWA widgeteket.

Exposition PHP Libraries

Ez a csomag azokat a szerver oldali komponenseket tartalmazza, melyek a kliens oldali kódokat egészítik ki, melyek lehetővé teszik egy widget futtatását. Például az UWA formátumot feldolgozó script, a widget kiszolgálását lehetővé tevő kódok, adat proxy-k és egyebek képezik részét.

Exposition PHP Server

Ez a widget szerver teszi lehetővé az UWA widgetek különböző környezetekben történő futtatását, az UWA compilereket foglalja magába, melyek a támogatott widget platformokra történő fordítást végzik el. Az Exposition PHP Librariest is tartalmazza, a célja annak bemutatása, hogy hogyan építhető fel egy widget szerver.

Előzetes

Bár a PHP és JavaScript kódok viszonylag jól dokumentáltak és átláthatóak, egyelőre nincsenek közzétéve részletek azt illetően, hogy hogyan működtethetőek ezek a komponensek együtt. Ez alól kivételt képez az Exposition PHP Server beüzemeléséről szóló gyorstalpaló, de ez sincsen túlrészletezve. Ezt illetően számos konkrét leírás fog napvilágot látni a közeljövőben, és én is próbálok majd ezekről írni bővebben is.

Yahoo! BrowserPlus™

Úgy tűnik hogy egy nagyon aktív hétnek nézünk elébe – így a hét közepén. Most van a Google IO, pénteken Netvibes esemény (angolul megemlíti Tariq Krim is), amiről pedig most írok, az a Yahoo! találmánya, a BrowserPlus. Avagy egy olyan böngészőkiegészítő előzetese, ami erősen kiterjeszti a jelenlegi lehetőségeket, s talán a – most 1 éves – Google Gears versenytársának lehet tekinteni.

Míg a SearchMonkey a kereső optikai tuningja (a találati lista okos információkkal való kiegészítése) volt, addig a BrowserPlus egy másik fronton támadja be a Google-t: egy a Google Gears-hez hasonló böngészőkiterjesztés létrehozásával. A BrowserPlus segítségével képeket méretezhetünk át (egy képgalériába feltöltés előtt ez nagyon sok sávszélességet megtakaríthat), adatokat tárolhatunk, fájlokat drag’n'drop-olhatunk be a böngészőbe, JSON-t tölthetünk be idegen domainről, üzeneteket küldhetünk (lásd LacKac Callout-ja) és egyebek – kis, egymástól független pluginekről van szó, melyek a felhasználó hozzájárulása után gyorsan feltelepülhetnek a böngészőbe, és kifejthetik ott áldásos tevékenységüket. Majd, mert ez most csak egy előzetes betekintő amit láthatunk. Annak viszont nagyon szép, a kiterjesztés hozzáadásához nem kellett még a böngészőt sem újraindítanom, nagyon kényelmesen, gyorsan, flottul feltelepült (még Firefox 3-ra is!). Nem néztem utána, de gyanítom egy mini webszerver települt a gépemre, amin keresztül kommunikálni tud a böngészőben futó JavaScript a külvilággal – másképp ez nem nagyon lett volna lehetséges.

Meglátjuk mi lesz a dologból, de az előzetes elég pozitív képet ad erről a kiterjesztésről, a Yahoo! úgy tűnik hogy az előre menekülést választotta, és belead apait-anyait ami az innovációt illeti. Várom a következőket, ez így nagyon szimpatikus. A Google-nél kicsit berozsdásodtak a fogaskerekek.