Objekti meetodi kontekst JavaScriptis

Kuidas saada teada, millisele objektile viitab this vaikimisi kui tegu on objekti meetodiga? call, apply ja bind abil saab seda ka ise muuta, kuid mis on selleks vaikimisi?

Rusikareegel on, et tuleb vaadata funktsiooni käivitamise hetkel (st. sellel kohal, kus funktsiooniväärtuse taga on sulud) käivitatava väärtuse vasakut poolt - misiganes sealt vastu ei vaataks, see ongi kontekst.

Math.round();  // meetodi *round* kontekst on *Math*
window.Math.round(); // kontekst on *window.Math*

Juhul kui seal pole midagi, on kontekstiks window.

alert(); // funktsiooni *alert* kontekst on *window*

Kui tegu on callback funktsiooniga, siis on kõik sama - arvestada ei tule mitte selle seadmise hetke, vaid käivitamise hetke

function foo(callback){
    callback();  // <-- siin toimub käivitamine
}
foo(console.log); // <-- siin seadmine

Näites ei ole käivitatava meetodi log kontekstiks mitte console vaid window! Kuna konteksti seab käivitamise hetk ning lause callback(); juures, erinevalt lausest foo(console.log) enam konteksti määratud pole - vasakul pool kävitatavat väärtust pole märgitud midagi.

Et mitte jätta konteksti juhuse hooleks tasub tagasikutsefunktsioonide juures kasutada väärtuse seadmise hetkel meetodid bind (ES5 lisa, töötab vaid moodsaimates brauserites, samuti ka NodeJS platvormil) või käivitamise hetkel meetodeid call või apply.

// tagasikutsefunktsiooni kontekstiks saab *console*
foo(console.log.bind(console));

või

// käivitatava funktsiooniväärtuse kontekst on *console*
function foo(callback){
    callback.call(console);
}

Täpsustuseks märgiks veel ära, et kirjeldatud kontekst this olulisus seisneb selles, et kontekst viitab “iseendale”. See tähendab, et objekti meetodi sees saab kasutada objekti muid omadusi ja meetodeid, ilma et oleks vaja teada objekti nimetust vms viidet.

foo = {
    bar: 1,
    foobar: function(){
        alert(this.bar); // <-- kontekstiks on objekt *foo*
        // *this.bar* on sama mis *foo.bar*, kuid konteksti
        // tõttu pole vaja *foo* nime teada
    }
} 

NB! Kui tagasikutse funktsioonile on meetodiga bind kord juba kontekst seatud, siis seda call või apply abile muuta enam ei saa.

function bar(){
    alert(this.baz);
}
function foo(callback){
    callback.call({baz:1}); // <-- ei muuda enam midagi
}
foo(bar.bind({baz:2}); // <-- bind seab konteksti

iPhone rakenduse tegemine

Eelmises postituses mainisin, et minu matemaatiliste valemite rakendust on praeguseks alla laetud 1000 korda, siinkohal siis valgustaks veidi tagamaid.

Ma ei teinud seda rakendust erilise eesmärgiga, soov oli vaid proovida läbi kogu töövoog alates sellest et on idee, kuni selleni, et rakendust saab AppStorest alla laadida. Idee teket täpselt ei mäleta, igatahes sai selleks matemaatika valemite kuvamine - sisuliselt on tegu spikriga, valid teema ning näed vastavaid valemeid (nt. ruutvõrrandi valemit). Kuna eeldatav sihtrühm krediitkaarti ei oma (tegu siiski kooliõpilastega), siis oli plaaniks teha rakendus tasuta ja selle eest mitte raha küsida.

C keeles ma suurt ei orienteeru, viimased katsetused jäid aastate taha kui tegin TTÜ’s mingeid kodutöid, seega sellele väga keskenduda ei tahtnud. Õnneks on praeguseks saada ka erinevaid toolkit‘e, mis võimaldavad mugavamalt hakkama saada. Minu esimeseks valikuks sai PhoneGap, mis on sisuliselt UIWebView wrapper. Teed HTML lehe, paned selle JavaScriptiga “elama” ja pakid rakenduseks kokku.

Twitterist sain vihje, et on olemas ka parem süsteem nimega Appcelerator, mis sisuliselt on sama, aga ainult UIWebView asemel pakub ehitusklotsidena kõiki native UI elemente ning selmet veebilehena asja kuvada, kompileerib eraldiseisvas failis oleva JavaScripti koodi iPhonele arusaadavaks - ühesõnaga veebilehe asemel kompileeritakse programm native app‘iks.

Struktuur

Rakenduse struktuur on väga lihtne. Põhivaade koosneb kahe elemendiga TabGroup objektist. Esimene element sisaldab “sisukorda”, teine valitud teema valemeid.

Sisukorravaade koosneb TableView elemendist, mille sees on üksikud TableViewRow elemendid. Kusjuures, igale reale on seatud eraldi “onclick” kuular, nii et kui mõnel real vajutada, avatakse valemite vaates vastavad valemid.

Valemite vaates on põhielemendiks WebView, mis kuvab lokaalseid HTML faile. Kõik valemid on GIF pildid, mis asuvad HTML failidega samas kaustas rakenduse sees. Uue teema valimisel näidatakse kasutajale aktiivsuse indikaatorit, mille kaotab WebView küljes olev onload sündmus.

Administreerimine

Valemite sisestamiseks kirjutasin lihtsa veebiliidese, mis võimaldab tekitada kategooriad ning nende alla valemeid sisestada. Kui valemid on sisestatud, käivitan täiendava skripti, mis genereerib rakenduse jaoks vajalikud HTML failid ning koostab ka JSON formaadis sisukorrafaili, mille alusel rakendus faile näidata oskab.

Sisukorrafaili sisu on järgmine:

[
    {
        "title": "Aritmeetika",
        "file": "f3f80b155d7d9af6c53bcfe23f1ea1a5.html"
    },
    {
        "title": "Algebra",
        "file": "589e1e9e690257c13858583381062e49.html"
    },
    {
        "title": "Võrrandite lahendid",
        "file": "54a2708351b891702815e787feed5f69.html"
    },
    {
        "title": "Planimeetria",
        "file": "7a1970deec26f4b79b4c245c03c5f345.html"
    },
    ......
]

Nii on rakenduse sisu lihtne uuendada - tuleb genereerida uued failid (iga kord on failinimed unikaalsed, et vältida puhverdamist) ja rakendus loeb need andmed kindla nimega JSON failist kenasti sisse.

Kood

Kood on kirjutatud täielikult JavaScriptis (lisaks standardsetele võimalustele on kasutusel Appceleratori API’id). Toon siin ära põhiloogika bloki, mis laeb JSON failist sisukorra ja genereerib selle alusel sisukorra tabeli read.

// funktsioon laeb sisukorrafaili ja genereerib
// massiivi tabeli rea elementidega
function generateIndex(){
    var data = [], json, rows = [], row,
        file = Titanium.Filesystem.getFile(
            Titanium.Filesystem.resourcesDirectory,
            "topics", "quefile.json");

    // lae failist JSON
    if (file.exists()) {
        json = file.read();
        try{
            data = JSON.parse(json);
        }catch(E){}
    }

    // koosta tabeli read
    for(var i=0; i<data.length; i++){
        if(!i){
            // globaalne muutuja
            firstpage = data[i].file;
        }
        row = Titanium.UI.createTableViewRow({
            title: data[i].title
        });

        // kuna tegu on tsükliga, loo lokaalne kontekst
        // kahjuks bind puudub, seega vaja nikerdada
        (function(f, t){
            row.addEventListener("click", 
                function(){displayPage(f, t)},
                false);    
        })(data[i].file, data[i].title);

        rows.push(row);

    }
    return rows;
}

Kusjuures rakenduse skriptiosa on ainult 99 rida pikk ja saaks ka veel lühemalt, kuna see on optimeerimata, sisaldab katsete käigus tekkinud jäänukelemente jne.

Valmis rakenduse saab iPhone, iPod ja iPad seadmesse laadida siit.

NB! Et saada õigus iseenda(!!!) telefonis rakendust katsetada ning hiljem valmis rakendus AppStore‘i üles laadida, tuli liituda Apple Developers programmiga, mille aastatasu on $99. Kusjuures, makset ei saa teha online vaid tuleb välja printida avalduse vorm, täita see ära (sh. kanda vormile krediitkaardi andmed) ja see faksida (!!!) Apple numbrile. Kasutasin faksimiseks online teenust, kuhu laadisin üles PDF faili (allkirja ei pannud ise, vaid kopeerisin eesti.ee portaalist enda rahvastikuregistri andmete juurest). Kahjuks ei kasutanud SEB virtuaalkaarti vaid reaalset kaarti ning et igaks juhuks vältida tulevasi probleeme panin kasutatud krediitkaardi hiljem kinni. SEB virtuaalkaardiga seda muret poleks tekkinud.

1000 allalaadimist AppStores

Minu tasuta matemaatika rakendust on praeguseks AppStores alla laetud juba üle 1000 korra. Kuna tegu on eestikeelse rakendusega ning seda ongi alla laetud praktiliselt ainult Eestis (kusjuures iga allalaadimine tähendab üht unikaalset seadet, mitte mitu korda per seade), siis minu arust tegu täitsa toreda saavutusega :)

Kaubamärgi registreerimisest ja Blog.tr.ee’st

Kaubamärgi registreerimine ei ole keeruline, küll aga jube pikk protsess. Näiteks 27. märtsil 2009 (umbestäpselt 2 aastat tagasi) andsin Tr.ee OÜ, mille juhatusse ma tollal kuulusin, nime alt sisse kaubamärgi registreerimistaotluse nimele “Blog.tr.ee”. Aeg kulus, aegajalt tuli registreerijal (Tr.ee OÜ) järjekordse etapi puhul riigilõivu maksta ning siis selle kuu alguses (täpsemalt 07.03.2011) sai see lõplikult registreeritud.

Kokkuvõttes - kaubamärgi registreerimise protsess võttis aega 20 päeva vähem kui 2 aastat. Mina olin otseselt sellega seotud ainult alguses, kuna lahkusin ettevõttest juba 2009 a. suvel, kuid kuna olin taotluse esitaja, saadeti ka edaspidi kõik seonduv post minu aadressile.

Siinkohal mainiks ära, et viimasel ajal on mulle silma hakanud mitmel pool blogides kriitika Blog.tr.ee kohta seoses postituste mitte ilmumise ja aeglusega. Teema pole mulle sugugi võõras. Tundub aga, et asjad ei taha kuidagi paremuse poole liikuda.

Meenus, et kunagi ammu aega tagasi liikusid plaanid teha MTÜ Eesti Blogiliit, mis haldaks ise sarnast lehte kuna Blog.tr.ee laiutas turul ja ei toiminud alati korrektselt või ootuspäraselt. Kahjuks midagi sellist kunagi ei sündinud. Aga et asjale siiski nüüd tagantjärele (parem hilja kui üldse mitte) omalt poolt hoogu anda, algatasin avatud lähtekoodiga blogikataloogi projekti tööpealkirjaga Blogipunkt, millega võib igaüks kaasa lüüa või sellest soovi korral oma klooni teha. Ma ise ei tahaks väga valmis saiti hallata, sain seda Blog.tr.ee ajal küllalt teha, aga et anda soovijatele võimalus, siis saigi projekt ette võetud.

Kuidas töötab e-post

E-post oma olemuselt on üsna lihtne teenus. Sellisel kujul kui meie seda tunneme, on e-post töötanud sisuliselt aastast 1982 - mil loodi SMTP protokoll kirjade edastamiseks. E-kirju saadeti ohtralt ka varem, kuid neid edastati arvutist arvutisse FTP ehk failiedastuse protokolli abil, spetsiaalselt e-kirjade edastamiseks mõeldud protokolli veel polnud.

Sisuliselt võib öelda, et kui kiri mis saadeti välja aastal 1982 ning adressaadini jõudmata sattus mingisse interneti Bermuuda kolnurka, igavesse tsüklisse, siis sellest tsüklist pääsenult oleks praegune võrk võimeline sedasama kirja ilma mingite modifikatsioonideta endiselt adressaadini toimetama. Kõik täiendused, mis vahepeal on tehtud, on lisatud uue kihina olemasolevale, mitte ei ole põhimõtteliselt muudetud süsteemi ennast.

E-kiri koosneb laial saastus kolmest eraldi elemendist - kirja sisust, kirja päisest ja “ümbrikust”. Kirja pärises asub igasugune kirjaga seotud meta-info, näiteks mis on selle pealkiri ja kellele see on adresseeritud. Küllap paljud ei tea, aga tegelikult kirja päises olevad aadressid (To, Cc ja Bcc väljadel) ei mängi edastamisel mitte mingisugust rolli - need aadressid kuhu kiri tuleb edastada, määrab hoopis “ümbrik.”

Kirja päises olevad aadressid on ainult informatiivseks kasutamiseks e-posti kliendile ning spämmitõrjele. Tegelikud aadressid liiguvad kirjast eraldi info ehk “ümbrikuna” e-posti edastusserverilt -serverile.

E-posti edastus

SMTP serverile öeldakse MAIL FROM ja RCPT TO parameetritega ära esiteks kirja saatja ning seejärel kõik saajad, hoolimata kas need asuvad To, Cc või Bcc real. Kusjuures edastatakse ainult need aadressid, mida vastuvõttev server peab teadma. See tähendab, et kui e-posti klient võtab ühendust väljuva SMTP serveriga, siis vuristab ta ette kõik adressaadid, kuid kui väljuv SMTP server võtab ühendust vastuvõtva SMTP serveriga, edastatakse vaid need aadressid, mis kuuluvad selle konkreetse vastuvõtva serveri juurde.

Üldiselt liigub siis e-kiri järgmist rada pidi

1. Saatev e-posti klient (MUA - Mail User Agent, n. Outlook, samuti ka webmail) võtab ühendust väljuva SMTP serveriga (MTA - Mail Transport Agent), edastab saatja ja saajate andmed ning seejärel kirja enda.
2. Väljuv SMTP server (MTA) vaatab kes on addressaadid, ning laeb @ märgi järel oleva serveri nimeserverist (n. @hot.ee) MX (mail exchanger) kirje järgi vastuvõtva serveri aadressi (MTA, hot.ee puhul on selleks mx1.hot.ee).
3. Väljuv SMTP server võtab ühendust vastuvõtva serveriga (port 25) ning annab teada kirja saatja andmed ning saaja aadressidena kõik sellele serverile suunatud adressaadid. Seejärel edastatakse kiri ise.
4. Vastuvõttev SMTP server edastab kirjad vastuvõtvale e-posti serverile (MDA - Mail Delivery Agent), mis salvestab kirja adressaatide kaustadesse.
5. Addressaadi e-posti klient (MUA) võtab POP3 või IMAP protokolli abil e-posti serveriga (MDA) ühendust ning saab nüüd kirja lõpuks kätte. Vastuvõttev e-posti klient enam “ümbrikut” ei näe, tema saab vaid kirja enda. From, To, Cc väljadel oleva info kuvatakse kasutajale kui kirjaga seotud addressaate

Kirja enda ehitus on sarnane teiste tekstipõhiste protokollidega, nagu näiteks HTTP. Kiri algab päiseosaga, mis kestab kuni esimese tühja reani (kaks reaeraldussümbolit “\r\n” järjest), edasi järgneb juba kirja sisuosa.

Päised

Reegliks on, et üks päisekirje asub ühel real. Erandiks on vaid pikemad kui 80 sümboliga kirjed - need volditakse mitmele reale laiali, aga nii et esimene rea puhul algab tekst esimesest sümbolist, järgnevatel on esimeseks sümboliks alati tühik. Nii oskab vastuvõttev server hiljem read tagasi kokku voltida - juhul kui rida algab tühikuga, liidetakse see eelneva rea lõppu.

From: andris@kreata.ee
To: addressat1@example.com, addressat2@example.com,
    addressat3@example.com, addressat4@example.com

Näiteblokis jätkub To: kirje uuelt realt kuna addressat3... ei alga rea algusest, vaid selle ees on tühikusümbolid.

Oluliseimad kirjed oleksid From, To ja Subject - kui need on täidetud, on kirja võimalik juba saata.

Sisu

Vaikimisi on tekst 7 bitises US-ASCII kodeeringus. Kõik mis järgneb päise lõpus olevale tühjale reale, ongi kirja sisuks. Ilmselgelt jääb sellest väheks, kuna nii ei ole võimalik isegi täpitähti kasutada, hieroglüüfidest jms. rääkimata. Samuti ei ole erilisi võimalusi teksti vormindamiseks ega manuste lisamiseks. Kõigi nende nimetatud asjade jaoks võeti kasutusele multimeili laiendused (MIME), kuid nendest hetkel pikemalt juttu ei tee. Sisuliselt on tegu täiendava kihiga tavalise tekstiformaadi peal.

Seega kõige lihtsam kiri võiks välja näha nii

From: andris@kreata.ee
To: andris@node.ee
Subject: Kiri endale

Tere maailm!

Esimesed kolm rida moodustavad päise, järgnev tühi rida on päise lõpu markeerija ning rida “Tere maailm!” moodustab kirja sisu.

Kirja edastamise näide

Seda, kas kirjeldatud e-kirja koostamise viis ka töötab või mitte, on igalühel võimalik kergelt järgi proovida. Vaja on telnet nimelist programmi ja ligipääsu SMTP serverile (soovitavalt mitte-autentimisega, kuna ise käsklusi trükkides on paroole raske sisestada).

Esiteks tuleb käivitada telnet SMTP serveri pihta. Mina kasutan näites hot.ee SMTP serverit, kuna see on Elioni võrgust kasutades vaba ligipääsuga.

telnet mail.hot.ee 25

Trying 194.126.101.116...
Connected to mail.hot.ee.
Escape character is '^]'.
220 hot.ee HOT-Relayhost1.estpak.ee

Server vastas teatega “220…” mis tähendab, et ühendus on avatud ja server on valmis meid kuulama. SMTP puhul tähistavad koodid algusega 2 ja 3 edu, aga 4 ja 5 ebaõnnestumist.

Järgmisena tuleb end identifitseerida ja anda teada mis tüüpi protokolli toetatakse, kas tavalist SMTP või laiendatud versiooni ESMTP. Seda saab teha käskudega HELO ja EHLO millele järgneb iseenda masina nimi. Näites kasutame tavalist SMTP versiooni ja seega on käskluseks HELO.

HELO minaise
250 HOT-Relayhost1.estpak.ee

Nüüd saab hakata “ümbrikut” kokku panema. Selle jaoks tuleb sisestada saatja aadress ja ükshaaval saajate aadressid. Need sisesatud aadressid saavad tegelikeks adressaatideks, kirja sees olevad on ainult informatiivse iseloomuga.

MAIL FROM:<andris@kreata.ee>
250 2.1.0 Ok
RCPT TO:<andris@node.ee>
250 2.1.5 Ok

Kui formaalsused on korraldatud, saab minna edasi juba tegeliku kirja edastamisega, selle jaoks tuleb kasutada ksäklust DATA. Edasi on kogu sisestatav tekst osa kirjast ning seda kuni üksiku punkti sisestamiseni omaette real. Vältimaks segadust, peab klient kirja edastades kirja sees kõik rea alguses olevad punktid topeltpunktidega asendama.

DATA
354 End data with <CR><LF>.<CR><LF>
From: andris@kreata.ee
To: andris@node.ee
Subject: Kiri endale

Tere maailm!
.
250 2.0.0 Ok: queued as 01E7F49A

Peale punkti sisestamist loeb server kirja sisu lõppenuks ning võtab selle edastamiseks üle. Klient võib nüüd ühenduse sulgeda.

QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Kokkuvõtteks

Selline on siis suures plaanis e-posti liigutamise mehhanism. Võibolla võtan kunagi ka MIME pikemalt lahti kirjutada, seniks aga võib vaadata minu e-posti saatmise kliendi Nodemailer lähtekoodi, mis on täiesti MIME sõbralik, võimaldades kasutada UTF-8 kodeeringus teksti, lisada manuseid jne.

JavaScripti omistamislause

Ja nüüd midagi, mis on mul huvitaval kombel siiani kahe silma vahele jäänud, aga mida lugesin Stoyan Stefanovi raamatust JavaScript Patterns ja mis tagantjärele tundub täiesti loogiline.

var a = b = c = 5;

Ei ole sugugi sama, mis

var a = 5;
var b = 5;
var c = 5;

Vaid hoopis

var a = 5;
b = 5;
c = 5;

Ehk et muutujatest b ja c saavad lokaalsete asemel hoopis globaalsed muutujad!

Samal teemal veel

Igaks juhuks märgin ära veel samasse teemasse kuuluva, aga juba tuntud probleemi

a = b = [];
c = d = {};
e = f = 5;

Sellise omistamise korral ei saa me mitte 2 massiivi-, kaks objekti- ja kaks numbriväärtust, vaid kaks numbriväärtust (e ja f, mõlema väärtuseks nr 5) ja ühe massiivi- ning ühe objektiväärtuse.

a ja b ei ole mitte eraldi väärtused, vaid kaks muutujat, mis viitavad ühele ja samale massiiviväärtusele. JavaScriptis on objektide edastamine (ka massiiv on objekt) alati BY REFRENCE.

Seega lause

a = b = [];

võib lahti kirjutada ka kui

a = (b=[]);

ehk

b = [];
a = b; // BY REFRENCE!

Kindle e-luger

Kaalusin kaua, kas hankida endale e-luger, oodata ära kuni iPad kohalikku kaubandusvõrku saabub või lugeda e-raamatuid arvutiekraanilt/telefonist. Kuna ka meie jaoks on mõnda aega avatud Amazoni e-raamatute pood, siis installisin arvutisse ja telefoni Kindle aplikatsiooni, mis neid raamatuid ette näidata oskaks ja proovisingi paari raamatut lugeda. Paraku ei olnud tulemus väga hea, ikkagi üsna tüütu on arvutiekraanilt pikemat teksti ette võtta. Ka iPadi tulek ei tundunud enam nii roosiline, kuna iPadi näol on tegu sisuliselt järjekordse arvutiekraaniga.

Ühesõnaga, otsustasin proovida e-lugerit. Eestis pakutav valik on üsna kehva, Rahva Raamat küsib Cool-er’i eest tutvumishinnaga 3900 krooni, mis on päris soolane. Koos Kindle raamatute müügi avamisega, hakkas aga Amazon tarnima Kindle e-lugereid ka Eestisse, kuid selle lugeja hind (kuigi tegu peaks olema tunduvalt parema seadmega kui Cool-er) on letil juba ainult $139 + kulud. Kuludeks on siis transport ja impordimaks. Pakkumine tundus soodne ja tellisingi ära.

Reedel panin tellimuse sisse, esmaspäevaks oli pakk Tallinnas (UPS kulleriga). Kuna pakki oli vaja tollis deklareerida, ei saanud kohe kahjuks kätte. Teisipäeva hommikul käisin tollis (esitada tuli UPS’i poolt e-postiga saadetud dokumendid + reisija deklaratsioon), maksin impordimaksu ära ja sain UPS’ist oma lugeri kätte. Väga kiiresti käis.

Hind kujunes siis järgmiselt:

• Seadme hind 1 556,98 kr ($139)
• Transport kulleriga 235,00 kr ($20.98)
• Impordimaks 362 kr

Kokku siis 2153.98 kr, mis on Rahva Raamatu poolt pakutud Cool-er’i hinnast ligi kaks korda väiksem.

Seade oskab suhelda WiFi võrguga ning ka USB kaabli abil arvutiga (sama kaabel on kasutusel ka aku laadimiseks). Amazonist ostetud e-raamatud ilmuvad seadmesse võrgu olemasolul automaagiliselt, kuid peaks saama ka USB kaabli abil neid sinna saata. Tavalisi PDF faile jms võib seadmesse lihtsalt “lohistada,” kuna seade ilmub kaabliga ühendamisel arvuti töölauale tavalise välise kettana.

JavaScripti testimine

Kuigi testimise valdkond on suur ja lai, siis üks kindel asi mida tagada tuleb, on eri platvormide testimine. Alati ei ole aga kõiki võimalikke brausereid ja operatsioonisüsteeme käepärast ja tuleb kasutada alternatiivseid vahendeid. Kõige kiirem ja lihtsam nipp erinevate platvormide testimiseks oleks browsershots lehe kasutamine:

• tee testleht, mis kontrollib erinevaid kindlaid asju (unit tests)
• tulemused peaksid olema esitatud tabelina (et oleks kergelt aru saada, mis mida tähendab) ja testi läbinud read oleksid näiteks rohelised ja mittetöötavad punased
• mine browsershots.org lehele ja sisesta testlehe aadress
• oota kuni pildid on valmis ning vaata nendelt, millised testid on läbi kukkunud

Alati ei anna browsershots pildid õiget tulemust, kuna brauserid ei ole kontrollitud. Võibolla näiteks on konkreetne brauser seadistatud nii, et test ei saagi seal läbi minna (näiteks on küpsised välja keeratud, kui neid oleks vaja jne), samas aga kuna puudub info konfiguratsiooni kohta, on raske ka järeldusi teha. Küll aga kui kõik on roheline, võib omadega rahul olla.

Mina olen seda strateegiat kasutanud näiteks jStorage testimiseks (testleht).

Veebipõhised protokollide haldajad

Kes on vähegi HTML’iga kokku puutunud, teab et linkidel käib ees protokolli nimetus- tavalingi puhul on selleks http: või https:, FTP serveri puhul ftp:, e-maili aadresside korral mailto: jne. Klikkides lingil, avatakse protokolliga seotud rakendus. Veebilinkide puhul on selleks brauser ise, aga ftp, mailto jne juba reeglina mõni muu.

Erinevad aplikatsioonid saavad registreerida brauseris ka oma kohandatud protokolle, nii teeb näiteks Skype - skype:kasutajanimi?call. Vähe aga teatakse, et näiteks Firefox brauseris saab protokolli kindla rakendusega siduda ka suvaline veebiteenus - sellisel juhul on protokolli avavaks rakenduseks enam mitte väline rakendus vaid määratud veebilink, mis saab parameetriks lingi väärtuse. Nii näiteks saaks veebipõhine e-posti klient suunata endale kõik mailto: lingid - kasutaja klikib sellisel lingil, kuid Outlooki või Thunderbirdi avamise asemel avatakse veebipõhine e-posti teenuse leht.

Protokolli saab enda veebiteenusega siduda järgmise käsuga:

navigator.registerProtocolHandler(protocol,
          handling_url,
          name);

Kus protocol on protokolli eesliide (näiteks mailto), handling_url on aadress, kuhu päring suunatakse (aadressis olev %s asendatakse lingi väärtusega, nb - aadress peab asuma samas server, kui päringut teostav veebileht) ja name inimloetav protokolli nimetus. Loomulikult ei lisata sellist protokolli registreerimist automaatselt, vaid enne küsib brauser kasutaja luba nagu kõigi muude taoliste tegevuste korral.

Näide

Kui kasutajalt küsida mailto linkide suunamist järgmise käsuga

navigator.registerProtocolHandler("mailto",
          "http://emaili-server.ee/new?to=%s",
          "Minu E-post");

ja seejärel kasutaja klikib suvalisel veebilehel järgmise kujuga lingil

<a href="mailto:kasutaja@server.ee">saada kiri</a>

siis avab brauser veebilehe aadressiga

http://emaili-server.ee/new?to=mailto:kasutaja@server.ee

Katsetada saab siin ja täpsemalt uurida Mozilla MDC Web-based protocol handlers lehelt.

Töötab - Firefox 3.x. Webkiti core’s on olemas juba aasta aega kuid miskipärast ei Chrome ega Safari seda veel ei toeta. Tulevikus aga kindlasti. IE kohta ei oska öelda.

Update

MongoDB probleemi sain osaliselt lahendatud, nüüd saab binary andmeid edasi ja tagasi GridFS vahel jooksutada. Küll aga tekkis uus probleem - kuna see klient on suhteliselt “noor”, siis GridFS’i andmete salvestamine striimina töötab korrektselt, aga lugemine mitte. Ehk et kirjutada võin jupikaupa, aga välja lugeda saan ainult korraga (liides teeb küll nägu, et annab mulle vajadusel jaokaupa infot, aga tegelikkuses on tal terve fail mällu loetud). not cool