Nörttinurkka (ohjelmointiaiheista ongelmanratkontaa)

[Tomi Männistö 0]

Miksi alla oleva ei toimi? Eli siis jos lomakkeelta tulee merkkijono, niin alla olevan operaation jälkeen muuttujat ovat kyllä integereitä, mutta niiden arvona on nolla. Jos alustan muuttujan itse, homma toimii ja stringit vaihtuvat integereiksi ja säilyttävät arvonsa, eli esimerkin tapauksessa 75 ja 300. Type Castingistä ei ole apua eikä stringien trimmaaminen trim-funktiolla ei ratkaise ongelmaa. Onko lomakedatassa kuitenkin joku piilomerkki, jota trim() ei putsaa?

 

<?php
function search(){

//Alla olevilla kahdella kommentoidulla rivillä tyyppimuunnokset menevät oikein
//$limits = " 75 - 300 ";
//$amounts = explode("-", $limits);

//Seuraava rivi ei toimi, eli lomakkeelta tulevien muuttujien arvo muuttuu nollaksi.
$amounts = explode("-", $_POST['amount']); 

$amountMin= $amounts[0];
$amountMax= $amounts[1];
echo $amountMin." ".gettype($amountMin)."<br/>";
echo $amountMax." ".gettype($amountMax)."<br/>";
$amountMin = $amountMin*1;
$amountMax = $amountMax*1;
echo $amountMin." ".gettype($amountMin)."<br/>";
echo $amountMax." ".gettype($amountMax)."<br/>";
}
?>

[John Firth 2]

Miksi alla oleva ei toimi?

 

En osaa PHP:ta, mutta oletko yrittänyt ottaa stringin omaan muuttujaansa postista ja sitten explodaa sen? Jotain tyyliin;

 

$limits = $_POST['amount'];
$amounts = explode('-',$limits);

[Lauri Liuhto 0]

En osaa PHP:ta, mutta oletko yrittänyt ottaa stringin omaan muuttujaansa postista ja sitten explodaa sen? Jotain tyyliin;

 

Sama vika kuin Johnilla, eli PHP ei kuulu varsinaisesti repertuaariini. Mutta alkuperäiselle kysyjälle: onhan tarkistettu että POSTista saatu muuttuja todella sisältää edes jotain senhenkistä kuin pitäisi? Eli jos tulostaa sen POSTista saatavan arvon suoraan, niin näyttääkö suunnilleen siltä miltä pitäisi?

[Tomi Männistö 0]

Olen koittanut ottaa omaan muuttujaan -> ei apua.

Data tulee lomakkeelta ja exploden jälkeen se on vielä kuten pitää eli kahtena eri stringinä. Kun sen jälkeen tekee tyyppimuunnoksen tavalla millä tahansa, niin  muuttuja arvoksi tulee nolla.

 

Jos siis alustan muuttujan käsin enkä ota dataa lomakkeelta, niin aiemmin kirjoittamani skripti toimii. Tuleekohan siinä lomakedatassa jotain ylimääräistä näkymätöntä ja sen takia tyyppimuunnos ei sitten onnistu?

[Kari Kangasluoma 0]

Kokeilepa syöttää arvo funktiolle tähän tapaa:

 

<?php

search($_POST['amount']);

function search($limits)
{
    $finalLimit = explode("-", $limits);
    //blaa, blaa, blaa jne...
}
?>

[Lauri Liuhto 0]

Olen koittanut ottaa omaan muuttujaan -> ei apua.

Data tulee lomakkeelta ja exploden jälkeen se on vielä kuten pitää eli kahtena eri stringinä. Kun sen jälkeen tekee tyyppimuunnoksen tavalla millä tahansa, niin  muuttuja arvoksi tulee nolla.

 

Jos siis alustan muuttujan käsin enkä ota dataa lomakkeelta, niin aiemmin kirjoittamani skripti toimii. Tuleekohan siinä lomakedatassa jotain ylimääräistä näkymätöntä ja sen takia tyyppimuunnos ei sitten onnistu?

 

Minulta tulee varmaan Hyviä Neuvoja koska en tosiaan kieltä juurikaan osaa, mutta jos katsot vaikka ensin mikä stringin pituus on käsittääkseni funktiolla 'strlen()' saa sen irti. Jos stringin pituus on jotain muuta kuin luulisi, niin sitten mukana varmaan ON jotain muutakin - tai vaihtoehtoisesti jotain puuttuu

 

Lisäksi kannattaa toki muistaa, että webbilomakkeista sisäänotettavaa dataa pitää aina käsitellä varoen - ellei nyt ole kyseessä joku täysin suljetussa härvelissä pyörivä henkilökohtainen palvelu johon kukaan koskaan ikinä ei pääse internetistä käsiksi.

[Tatu Koiranen 1 676]

Lisäksi kannattaa toki muistaa, että webbilomakkeista sisäänotettavaa dataa pitää aina käsitellä varoen - ellei nyt ole kyseessä joku täysin suljetussa härvelissä pyörivä henkilökohtainen palvelu johon kukaan koskaan ikinä ei pääse internetistä käsiksi.

 

Niin. Mutta sitten kun kuitenkin käy kämmi, voi aina lohduttautua sillä, että ns. "ammattilaisetkin" tekevät virheitä...

 

[Hannu Niemi 1]

Ihan ensiksi, tarkista, että sieltä lomakkeesta, mistä kutsut tuota peehoopeetä, löytyy myös method-attribuutti

<form Action="xxx.php" method="post">

...

</form>

 

Seuraavaksi (jos tämä ei ratkaissut), voit laittaa skriptin alkuun debuggausta varten

 

echo "<pre>";

print_r($_POST);

echo "</pre>";

 

(tai monesti debuggaus-vaiheessa korvaan tuossa kohtaa tuon vikan rivin die("</pre>");

 

Varmuuden vuoksi voisit skriptin alkuun laittaa myös

  ini_set('display_errors','On');

 

jos php.ini:ssä virheilmot on disabloitu, näin saat ne näkyviin, säästää aikaa

 

hannu (joka on jokusen rivin php:tä räpeltänyt)

[Hannu Niemi 1]

Onko lomakedatassa kuitenkin joku piilomerkki, jota trim() ei putsaa?

 

Ei pitäisi olla

 

h

[Sami Puro 599]

<?php
function search() {

// Tästä voi tsekata että onko koko 'amount' tieto edes tuossa POST:ssa mukana. Jos ei ole, niin sitten formi ei lähetä ko. dataa (method ei ole post tai sitten kentän nimi formissa väärin)
// Kommentoidaan tietysti pois kun todettu toimivaksi tähän asti, eli että data saapuu oikein.....
echo '<pre>'; die(print_r($_POST));

// Tsekattava että arvo on olemassa, muuten heittää erroria logiin
if (!isset($_POST['amount']) || strpos($_POST['amount'], '-')===false)
  return false;     // return-arvoksi jotain järkevämpää jos virhe?

$amounts = explode("-", $_POST['amount']); 

// Joku tarkistus oltava tässä välissä, että data on olemassa ja järkevä jollain tavalla, esim:
if (count($amounts)!=2)     // oletus siis että input on vain 75-300 tyyliin eikä muuta, mutta tiedä tuosta tarkemmin ...
  return false;


$amountMin=trim($amounts[0]);
$amountMin=trim($amounts[1]);
.....jne
}
?>

 

[Tomi Männistö 0]

<?php
function search() {
...
}
?>

 

 

Data tulee lomakkeelta ja pilkkomisen jälkeen se asettuu taulukkoon stringeinä kuten pitääkin. Mutta ongelma on siinä, että kun muutan ne integereiksi, muuttujien $amountMin ja $amountMax arvoiksi tulee nolla. Kuten aiemmin kirjoitin, jos alustan muuttuja käsin vastaavalla merkkijonolla "75-300" niin silloin homma toimii.

 

Jotain ongelmaa on lomakkeelta tulevassa datassa. Täytyy huomenna paneutua asiaan, laskea stringien merkkien määrät yms. En oikein keksi mitään muuta, kuin että stringeihin jää jotain sälää eteen, mitä trim() ei poista. Silloin on luonnollista, että arvo muuttuu nollaksi. Tuon trim():n tosin pitäisi poistaa kaikenlaiset tyhjät merkit.

 

En haluaisi mitään purkkaviritystä, mutta jos tätä ei saa toimimaan, niin en tähän hätään keksi muuta kuin että luen lomakkeelta tulevaa dataa taulukkoon merkki kerrallaan, sen jälkeen käyn taulukon läpi jollain isnumeric()-funktiolla tai vastaavalla ja luon niistä uudet merkkijonot, jotka sitten muutan integereiksi. Ymmärtääkseni isnumeric() palauttaa truen, jos merkkijono on numero vaikka se olisikin string-tyyppiä. Olisiko parempaa purkkaratkaisuajatusta? Lomakkeella on siis jQueryUI-kirjastosta slider, joka määrittää hinnan ala- ja ylärajan, ja jonka perusteella sql-kannasta haetaan sopivat tuotteet.

 

SQL ei palauta mitään, jos yrittää hakea hintoja niin, että hakukriteerit on lomakkeelta on stringejä ja tietokannassa on integereitä. En myöskään välittäisi tallentaa hintoja stringeinä, koska eikös silloin luvut järjesty esim seuraavasti: 1, 10, 19, 103, 1044, 2, 26, 200000, 3....?

 

Voisin myös koittaa käyttää floatia, joka tietysti on parempi tietotyyppi hinnalle, kun siinä voi periaatteessa olla desimaaleja, mutta desimaalit eivät ole relevantteja tässä hommassa.

 

[Sami Puro 599]

Tuotapa tuota, jos siis ainoa tarkoitus on tuon post-datan vieminen sql-kyselyyn niin ei sitä integeriksi tarvitse erikseen php:ssä muuntaa. Tietysti kunhan nyt tarkistaa että se on oikeasti on numero, järkevää dataa jne.

 

eli mielestäni tämä toimii:

$arvo='5';   // tahallaan lainausmerkeissä, string

$query="SELECT har FROM moo WHERE buu>=$arvo";   // jolloin tuosta tulee queryksi suoraan vain "buu>=5 " .. 

 

joka olisi sama kuin:

$arvo=5;   // integer

$query="SELECT har FROM moo WHERE buu>=$arvo";

 

 

 

edit; yhdet lainausmerkit pois ..

[Tomi Männistö 0]

Tuotapa tuota, jos siis ainoa tarkoitus on tuon post-datan vieminen sql-kyselyyn niin ei sitä integeriksi tarvitse erikseen php:ssä muuntaa. Tietysti kunhan nyt tarkistaa että se on oikeasti on numero, järkevää dataa jne.

 

eli mielestäni tämä toimii:

...

 

 

 

edit; yhdet lainausmerkit pois ..

 

Sitten siinä lomakkeelta tulevassa datassa täytyy olla jotain skeidaa, koska tietokannasta ei palautunut yhtään riviä (ilman hintaa palautuu eli yhteys kantaan on kunnossa), vaikka yritin hakea muuttujien ollessa stringejä. Täytyy testaa isnumericia stringeihin, koska sen tosiaan pitäisi palauttaa true, vaikka data olisi string, jos se vaan on luku.

[Juha Huvilinna 0]

Joo, PHP:n kanssa ei yleensä tarvitse välitää muuttujien tyypeistä. Eli jos sulla on stringejä, jotka sisältävät lukuja, niin niitä voi silti laskea yhteen. Jos tarkkoja ollaan, niin esim Apache ei välitä vaikka stringin lopussa olisi kirjaimiakin, se parsii sieltä luvun automaattisesti.

 

Eli seuraava tulostaa: 3

<?php
$luku1 = '1 ';
$luku2 = ' 2 a';
$luku3 = $luku1+$luku2;
print"$luku3";
?>

 

Jos SQL-kysely ei mene läpi, niin tulosta PHP:llä sen palauttama virhe. Tai tulosta kasattu kysely ja aja se kantaan käsin ja katso meneekö läpi.

[Pietu Pohjalainen 0]

Voisin myös koittaa käyttää floatia, joka tietysti on parempi tietotyyppi hinnalle, kun siinä voi periaatteessa olla desimaaleja

 

Float, vaihtuvantarkkuuksinen liukuluku on surkea valinta hintaa kuvaavaksi tietotyypiksi. Floatin käyttäminen hintatietoihin pitäisi säätää rikosoikeudellisesti rangaistavaksi teoksi. Jos kirjanpitäjiltä kysytään, niin rangaistuksen tulisi olla fyysinen.

[Tomi Männistö 0]

Float, vaihtuvantarkkuuksinen liukuluku on surkea valinta hintaa kuvaavaksi tietotyypiksi. Floatin käyttäminen hintatietoihin pitäisi säätää rikosoikeudellisesti rangaistavaksi teoksi. Jos kirjanpitäjiltä kysytään, niin rangaistuksen tulisi olla fyysinen.

 

Mikä olisi hyvä tietotyyppi hinnalle?

 

Tuohon Juhan vastaukseen: Tiedän, että PHP ei ole kovin ronkeli tietotyypeistä ja joidenkin testien mukaan on $x="string"*1 on tehokkaampi tapa kuin intval("string"). SQL:stä ei palauta virhettä, koska virhettä ei ole. Rivejä vain ei löydy, koska mikään rivi ei täytä hakukriiteereitä.

[Hannu Niemi 1]

Sitten siinä lomakkeelta tulevassa datassa täytyy olla jotain skeidaa, koska tietokannasta ei palautunut yhtään riviä (ilman hintaa palautuu eli yhteys kantaan on kunnossa), vaikka yritin hakea muuttujien ollessa stringejä. Täytyy testaa isnumericia stringeihin, koska sen tosiaan pitäisi palauttaa true, vaikka data olisi string, jos se vaan on luku.

 

Oletko ottanut aputulostuksia, esim print_r($_POST), print_r($amounts), echo $sql?

 

Nuo print_r:t kannattaa ympäröidä echo "<pre>"; ja echo "</pre>"-määreillä (jollei ajeta komentoriviltä).

 

Noista yleensä pystyy päättelemään missä kohdassa mennään metsään.

 

Sen tiedän faktana, ettei PHP lisää mitään salaisia merkkejä $_POST-dataan, jollei niitä jotenkin ulkoa/lomakkeelta siihen väkisin syötetä.

 

Niin ja tosiaan error messaget päälle (niin saa vaikka sql:n virheellisen sarakenimen kiinni hetkessä)

 

hannu

[John Firth 2]

Mikä olisi hyvä tietotyyppi hinnalle?

 

Int (sentteinä tms)

[Tomi Männistö 0]

Ongelma ratkesi. Lomakkeelta tuli näkymätön €-merkki. Homma paljastui, kun vaihdoin merkistöksi UTF-8:n, jolloin tuli mustia vinoneliöitä näkyviin.