Keskustelu: Nettisivujen teko: [JS] Tekstin jakaminen

Esitän nyt tyhmän kysymyksen.
Itselläni näet hyvin heikko tuntemus JavaScriptistä.

Olen siis tekemässä hedelmäpeliä Ajaxilla. Toteuttaminen on muuten ok, mutta haluaisin, että JavaScript jakaisi palvelimen palauttaman numerosarjan kolmeen osaan. Palvelin palauttaa JavaScriptille numerosarjan muodossa ?|?|? (esim. 1|2|3). JavaScriptin tehtävä on jakaa nämä kolme eri lukua omaan variableensa. Miten teen?

Googlea käyttämällä en saanut mitään järkevää aikaiseksi.

Eka osuma: http://www.developertutorials.com/tutorials/php/javascript-php-explode-function-051018-1025/

Hakusanat: Javascript explode

Aikaa meni: .000000001sec

JSON helpottaa elämääsi suuresti, varsinkin kun nyt uuden ECMAScript 5:n myötä JSON on kielessä natiivina (ja kirjastot mahdollistavat myös vanhojen selainten tukemisen). Eli seuraavanlaisesti:

Palvelimella

<?php
echo json_encode($arr);
?>

Selaimessa

var arr = JSON.parse(data);

Kysymykseen on suuri määrä aika helppoja vastauksia ja epäilemättä myös muita vastauksia. Niistä on varsin vaikea sanoa, mikä on paras.

Yksinkertaisuudellaan ja luettavuudellaan yrittää viehättää

var arr = data.split("|");

Jos palvelimen palauttama data on muuttujassa data, niin tuo purkaa sen muuttujiin arr[0], arr[1] ja arr[2]. Tässä yhteydessä on varmaankin syytä tarkistaa, että arr.length == 3 ja että data on muutenkin oikeaa muotoa. (Palvelimesta tulevan datan tarkistus on terveellistä vainoharhaisuutta.)

Toisaalta datan muototarkistusten takia parempi ratkaisu voisi olla match()-metodin käyttö. Sopivan lausekkeen kirjoittaminen sitä varten vaatisi kuitenkin tarkan tiedon siitä, mitä önumerosarjaö tässä tarkkaan ottaen tarkoittaa.

Mikäs siinä JSONissa on, että omatekemä vempele sen peittoaa? Varsinkin kun data on toivottavasti alun perinkin jossain muodossa, joka on helpompi muuttaa JSON-muotoon kuin putkimerkeillä erotelluksi. Jos data tulee valmiina noin, suosittelen vaihtamaan datan tallennusmuotoa.

JSONin kanssa tarkistus toimii try-catch -lauseella, JSON.parse heittää SyntaxErroria epäonnistuessaan. Jos palvelimen palauttamaa dataa tarvitsee tutkiskella vielä tarkemmin, Array sisältää nykyään apumetodeja, jotka saa helposti ujutettua samaan syssyyn, esim.

JSON.parse(data)
    .filter(function (value) {
        return typeof value === "number";
    });

tsuriga kirjoitti:

Mikäs siinä JSONissa on, että omatekemä vempele sen peittoaa? Varsinkin kun data on toivottavasti alun perinkin jossain muodossa, joka on helpompi muuttaa JSON-muotoon kuin putkimerkeillä erotelluksi. Jos data tulee valmiina noin, suosittelen vaihtamaan datan tallennusmuotoa.

Mikäs natiivi javascriptissä on vikana kyseisessä tapauksessa?

Sain tuolla Jimi-Kimin kertomalla jutulla toteutettua.
Päädyin Googlella jo aiemmin samaiseen paikkaan, mutten kiinnittänyt huomiota tarpeeksi tuon pikku skriptin löytämiseen.

tsuriga kirjoitti:

Mikäs siinä JSONissa on, että omatekemä vempele sen peittoaa?

Mitähän omaatekemää ajattelet olevan standardifunktiossa split()?

tsuriga kirjoitti:

Jos data tulee valmiina noin, suosittelen vaihtamaan datan tallennusmuotoa.

Kysymys koski dataa, jonka palvelin lähettää tietyssä muodossa. Kysymyksessä ei edes vihjattu siihen, että tätä muotoa voisi tai saisi muuttaa.

tsuriga kirjoitti:

JSON.parse heittää SyntaxErroria epäonnistuessaan.

Sanan öepäonnistuaö joillakin arvoilla. Esittämäsi koodi kuitenkin varmasti epäonnistuu sen datan käsittelemisessä, joka kysymyksessä kuvattiin.

Muutama syy siihen, miksi oletan datan lähetysmuodon olevan vaihdettavissa: Ensinnäkin, data tulee usein putkimuodossa siksi, että aloittelijan opas X on niin ohjeistanut. Petja ilmaisi olevansa aloittelija JavaScriptin kanssa. Myös viestimäärä ja muut Petjan viestit antavat olettaa, että kyseessä on suhteellisen aloitteleva koodimaisteri. Toisekseen, oman palvelimen todennäköisyys lienee suurempi kuin sen, että joku pyörittää (hedelmäpeli)palvelinta, joka palauttelee putkieroltetua numerodataa.

Näin ollen kyseessä olisi siis datan välittäminen ohjelmien välillä, eli juurikin se, mihin JSON on tehty. Muutama syy, miksi JSON-muotoinen data on ohjelmien väliseen tiedonsiirtoon tekstimuotoa parempi vaihtoehto:

• Yksinkertaisuus. Ei tarvitse lähteä enää miettimään palvelimella, että mitä voidaan käyttää erotinmerkkinä, eikä koodaamaan itse datan muuttamista lähetysmuotoon ja sen purkamista vastaanottopäässä. Sama koodi toimii aina, erotinmerkin vaihtuessa joudutaan taas muuttamaan koodia sekä palvelimen että vastaanottajan päässä.
• Semanttisuus. Jos data on tallennettu (indeksoitu) järkevästi, datasta nähdään helposti, mihin se on tarkoitettu. Self-documenting code on pop. Semanttisuuteen liittyy myös JSONin MIME-tyyppi application/json sekä tiedostopääte .json, jotka erottuvat selkeästi text/plainista ja .txt:stä. Tämä helpottaa palvelinasetusten kohdistamista ohjelmien väliseen tiedonsiirtoon. Näitä asetuksia voivat olla mm. pakkaus- ja loggausasetukset.
• Loogisuus. JSON-siirrosta nähdään heti kyseessä olevan tiedonsiirron ohjelmien välillä. Loogisuus yhdessä semanttisuuden kanssa helpottavat sovellusten jatkokehitystä, varsinkin ulkopuolisten jatkokehittäjien tapauksessa.
• Yhdenmukaisuus. JSONin toteutukset eri kielissä toiminevat yhtenevästi, kun taas tekstimuotoisen datan parsiminen välttämättä ei.
• Laajennettavuus. Tietorakenteen monimutkaistuessa lähetys- ja vastaanottokoodi pysyvät samana.
• Merkistövarmuus. JSON on standardin mukaan aina UTF-8 -muotoista, kun taas tekstimuotoiselle datalle tämä pitää palvelimen asetuksista riippuen määritellä erikseen.
• Virheherkkyys. Ei siis herkkyys vialliseen toimintaan, vaan datan hylkiminen virheellisen datan tapauksissa. Virheherkkyys estää väärin muodostetun datan syöttämisen sovellukselle. Skeemauksella saadaan luotua helposti tarkistussäännöstö datalle. Yksinkertaisissa validointitapauksissa ei siis tarvitse kirjoittaa erillisiä tarkistuslauseita, riittää kun dataan kohdistaa halutun skeeman. JSON Schema on toistaiseksi vielä vedosasteella, eli tämä on tulevaisuuden hienouksia. Halutessa tuosta löytyy kyllä toki jo toteutuksia. Nykyisellään JSON.parse osaa jo tarkistaa JSON-validiuden automaattisesti parserointivaiheessa, kun taas tekstimuotoisen datan yhteydessä tarkistaminen vaatii omat ehtolausekkeensa. Suosittelen kuitenkin tarkistamaan virheet myös JSONia parsiesssa ja lisämään sovellukseen käyttäjälle selkeät virheilmoitukset virhetilanteissa.

Othnos: Natiiviahan se JSONikin nykyään on. Ei splitissä sinänsä vikaa ole, se vaan lienee tässä tilanteessa huonompi ratkaisu, kun ajatellaan kokonaistilannetta. Se, että JSONin käyttäminen tässä tapauksessa lisännee siirrettävän datan määrää, kun datan esitysmuoto on pidempi ja jos halutaan tukea myös vanhoja selaimia, ei luultavasti näillä siirtomäärillä vielä riitä perusteluksi JSONin hylkäämiselle. Jos kyseessä tosiaan on ulkoinen palvelin, eikä Petjan itse muotoilema data, toki split on silloin ns. The Sh*t, yo.