Keskustelu: Nettisivujen teko: Ylimääräiset \-merkit JSON-datassa

En tiedä onko otsikko oikein, mutta tällainen pikku ongelma:

MERCHANTT<\/p>

Palaa takaisin verkkokauppaan<\/a><\/p>"

Kyseessä on curl yhteydellä palaava teksti, joka sisältää html-muotoiluja. Miten nämä muotoilut saa toimimaan, koska javasript lisää noita kenoviivoja kovin.

Mikä on curl-yhteys? Liittyykö se jotenkin curl-komentoon tai libcurl-kirjastoon? Miten Javascript lisää kenoviivoja? Minkälainen Javascript-koodi sinulla on? Mitä sinä ylipäänsä yrität tehdä?

fergusq kirjoitti:

Miten Javascript lisää kenoviivoja? Minkälainen Javascript-koodi sinulla on? Mitä sinä ylipäänsä yrität tehdä?

Näin yksinkertiainen on koodi:

$('#checkout-fi-box').html(json);

Nuo kysymäsi lisätyt kenoviivat näkyvät edellisessä viestissäni.
Edeltävä php koodi on tällainen:

        $json = $response;

		$this->response->addHeader('Content-Type: application/json');
		$this->response->setOutput(json_encode($json));

json_encode lisää kauttaviivojen edelle kenoviivat. Ne ovat osa JSON-formaattia ja niiden pitäisi hävitä, kun parsit JSON:n. Et kai sinä laita JSON-koodia sellaisenaan HTML:n sekaan?

Eli siis nyt lähetät JSON-muotoista koodia etkä HTML-koodia. Sinun pitää muuntaa se takaisin HTML-muotoon ennen kuin laitat sen sivulle esimerkiksi JSON.parse()-funktiolla.

Jos et lähetä muuta kuin HTML-koodia, voisit lähettää sen suoraan HTML:nä.

Tai toisaalta, jos PHP:ssä $json-muuttuja sisäältää jo JSON-enkoodattua dataa (tämä on varmaan se "curl-yhteydellä palaava teksti"), sitä ei pidä enää itse uudestaan enkoodata, eli json_encode on silloin väärin.

Ota selvää, mitä $json-muuttuja sisältää, ja sen perusteella päätä, onko json_encode enää tarpeen.

Sitten ota selvää, mitä JS-puolella json-muuttuja sisältää, ja sen perusteella päätä, olisiko JSON.parse tarpeen.

Kiitoksia näistä vastauksista. Sain tämän toimimaan siten että poistin kokonaan tuon enkoodauksen.
Löysin lisäksi javascriptiä varten tekaistun pienen strpos funktion. Sen avulla näen, sisältääkö paluuviesti virheviestiä ja voin tulostaa viestit sivulle eri tavalla, jos toiminto etäpalveliemlle ei onnistu esim. virheellisten tunnusten takia.

Javascript ei tarvitse mitään kotikutoista strpos-funktiota. String-oliolla on metodi indexOf. Yleensä ottaen vastauksen voi tutkia virheviestin varalta katsomalla status-arvoa. Koodi 200 tarkoittaa onnistunutta suoritusta, nelosella ja vitosella alkavat jonkinlaista virhettä. Huonosti toimiva sovellus voi tietysti kertoa tilakseen 200:n ja silti palauttaa jonkinlaisen virheilmoituksen, mutta jos se on json-muotoista dataa, niin totta kai silloin sitä käytetään kuten normaaliakin json-tietoa, eikä arvailla tutkimalla merkkijonon sisältöä.

The Alchemist kirjoitti:

(17.07.2016 13:47:32): Javascript ei tarvitse mitään koti­ku­tois­ta...

Javascriptissä on hyvä käyttää "kotiskutoisia" funktioita, jos ne on riittävän laadukkaita. Tuo yhden lyhyen rivin pituinen strpos funktio on tähän ihan hyvä.
Tarvitsee tarkistaa vain 2 virhettä, "failed" (yteys etäpalvelimeen ei onnistu) ja "Error" (jokin lomakkeen kentistä sisältää virheellistä dataa).

Strpos ei voi olla laadukas, koska se kopioi String.indexOf:n toiminnallisuuden tehden siitä itse asiassa jopa huonomman.

Huoh. Tuo koko pistemiehen ohjelma kuulostaa täydeltä purkalta (jos se on lähelläkään tätä...). Mitä väliä?

Yleispätevä sääntö: jos se on tehty JavaScriptillä ja HTML:llä, se on purkkaa. jQuery? Purkkaa. Node.js? Purkkaa. Angular? Purkkaa. JSONP? Purkan ultimaattisin muoto, silkkaa pahuutta. Taivas meitä varjelkoon pimeyden voimilta ja antakoon meille voimaa nukkua siitä huolimatta, että olemme nähneet tämän hirviön.

Jos koodaa JS:ää, on jo joutunut likaamaan kätensä. Pikkufunktiot eivät paljoa hetkauta.

fergusq kirjoitti:

(17.07.2016 20:49:34): Huoh. Tuo koko pistemiehen ohjelma kuulostaa...

Kiitos mileipiteestäsi :)
Oikeasti javascript ei ole tämän ohjelman kannalta ollenkaan välttämätön, haluan vain tehdä siitä laadukkaamman, kuin mitä olisi Opencartin oma maksutapa toteutus. Curl kirjaston ja javascriptin käytön ansionsta virhetilanteen sattuessa ei verkkokaupan kassalla tule sellaista ikävää yllätystä, että selain siirtyisi odottamatta checkout.fi:n sivulle.

pistemies kirjoitti:

haluan vain tehdä siitä laadukkaamman, kuin mitä olisi Opencartin oma maksutapa toteutus.

Ongelma tässä on vain se, että jos esimerkiksi virheviestin formaattia muutetaan tulevaisuudessa, koodisi ei enää toimi. Kuten The Alchemist sanoi, sinun pitäisi tutkia status-arvoa tai muuta koneluettavaa dataa. Jos OpenCart lähettää virheellisen status-arvon tai sen rajapinta tuntuu muuten huonolta, niin voit muuttaa sitä, onhan se avointa lähdekoodia. Jos muutoksesi on hyödyllinen, voit laittaa sen pull requestina OpenCartin GitHub-sivuille, jolloin kaikki OpenCartin käyttäjät pääsevät siitä nauttimaan.

Mutta JavaScriptin toteuttaminen kunnolla ei sekään ole tyydyttävä ratkaisu. Virheviestit pitäisi alunperinkin näyttää kunnolla back-endin puolella, eikä korjailla niitä myöhemmin JavaScriptillä.

fergusq kirjoitti:

Ongelma tässä on vain se, että jos esimerkiksi virheviestin formaattia muutetaan tulevaisuudessa, koodisi ei enää toimi. Kuten The Alchemist sanoi, sinun pitäisi tutkia status-arvoa tai muuta koneluettavaa dataa. Jos OpenCart lähettää virheellisen status-arvon tai sen rajapinta tuntuu muuten huonolta, niin voit muuttaa sitä, onhan se avointa lähdekoodia.

Kiitos, vaihdoin tuohon sen indexOf funktion, niin vähentää hiukan koodia. Tosin se toimii aika tavalla samoin kuin aikaisempi strpos funktio.
Tämä Checkout Fi maksutapa ei kuulu Opencartin sisäänrakennettuihin maksutapa laajennuksiin. Mutta sen ja monen muun maksutapa moduulin rakenne on jäljitellyt Opencartin rakennetta eli käyttänyt html-lomaketta Curl kirjaston sijaan. Ehkä tätä voisi soveltaa valmiisiin paypal ja klarna-moduuleihin.
Tuo Githubin käyttö on minulle ollut vähän ongelmallista, huonon englannin kielen takia. Tunnukseni siellä on pekka2.