Hei kaikille!
Teen parhaillaan Työvuoron varausohjelman versiota numero 2. Versio 1.0 oli siinä mielessä menestys, että sain sillä rahat uuteen iPadiin. Niin ja kokemusta sekä näkemystä.
--------------------------------------------------------------------------
Jos putkan ylläpidolle ok niin perustan tähän tämän topicin, koska sitten voin suunnata ongelmani yhden ketjun alle, kiitos.
--------------------------------------------------------------------------
Noniin.. eli aikaisempi taulujen järjestys oli hieman yksinkertaisempi nyt tauluja on useita:
- tapahtuma
- tyontekija
- varaus
- tarve
- status
Eli tarkoitus on hakea kaikki tapahtumat etusivulle. Tapahtumaan voi sitten varata työvuoron. Alla olevassa vanhassa tavassa "tapahtuma" taulussa oli sarake 'tarve' jossa luku.
// haetaan kaikki tapahtumat joiden status on 'Tapahtumat' päivämäärän mukaan
// lasketaan varattaujen työvuorojen määrä per tapahtuma
$query = "SELECT tapahtuma.*,
COUNT(varaus.Tapahtuma_Id) AS maara
FROM tapahtuma
LEFT JOIN varaus On Tapahtuma_Id = T_Id
WHERE tStatus = 'Tapahtumat'
GROUP BY T_Id
ORDER BY tPvm";Erona aikaisempaan on se että nyt tarveluku (työvuorojen määrä/ tapahtuma) on piilotettu tauluun nimeltä "tarve". Eli minun pitäisi osata yhdistää yllä olevassa SQL-lausekkeessa mukaan taulu "tarve". En oikein tajua.
tapahtuma
-T_Id (PK)
tarve
T_Id (FK)
tTarve
- jos joku jaksaisi hieman auttaa että pääsisi edes alkuun. Eli haluan selvittää "tarve" taulussa kuinka monta kyseisen tapahtuman id-numeroa (T_Id) siellä on ja laskea ne yhteen, hmm.. tai pikemminkin laskea tarve luvut yhteen:
id
1
T_Id
1
S_Id
1
tTarve
2
Tässä tapauksessa T_Id viittaisi tapahtumaan 1. S_Id sen sijaan status tauluun jossa kerrotaan mitä numerot tarkoittavat. tTarve sen sijaan on luku kuinka monta tietyn tyyppistä työntekijää tarvitaan tapahtumaan.
----------------------------------------------
esim. 1 = poliisi, 2 = palomies, 3 = ensiapu
----------------------------------------------
Toivon että esimerkkini ei vaikeuttanut kysymystä. Kiitos niille jotka jaksavat auttaa projektin kanssa. Tarkoitus on tehdä mahd. paljon itse mutta nyt noin 1 kk työn jälkeen ajattelin perustaa tämän topiicin ja kysyä neuvoa.
Suosittelisin lämpimästi nimeämään status-taulun järkevämmin. Sana "Status" kuvaa äärimmäisen huonosti "tarpeen lajia".
Tämä kuitenkin hakisi tapahtuman 1 tarpeen määrät
SELECT S.Nimi, SUM(T.tTarve) Kpl FROM tarve T JOIN status S ON T.S_Id=S.Id WHERE T.T_Id=1 GROUP BY S.Id, S.Nimi
Okei, tutkin tuon. Eli status voisi olla esim. ryhmä. Työntekijä kuuluu johonkin ryhmään.
Lisäys:
Tuota, tuota.. tiesin että tämä on vaikea. En ihan tajua tuota FROM kohtaa. Eli tarve ja mikä tuo T on se jälkeen? Sama sitten alemmalla rivillä JOIN status ja mikä tuo S on sen jälkeen.
nyt taulut näin:
--tapahtuma--
T_Id (PK)
--tarve--
T_Id (FK)
R_Id (FK)
tTarve
--ryhma--
R_Id (PK)
rNimi
SELECT ryhma.rNimi, SUM(tarve.tTarve) Kpl FROM tarve T JOIN ryhma S ON tarve.R_Id=ryhma.R_Id WHERE tapahtuma.T_Id=1 GROUP BY ryhma.R_Id, ryhma.rNimi
T ja S on aliakset tauluille. Eli toki sen voi kirjoittaa yhtä hyvin
SELECT status.Nimi, SUM(tarve.tTarve) Kpl FROM tarve JOIN status ON tarve.S_Id=status.Id WHERE tarve.T_Id=1 GROUP BY status.Id, status.Nimi
Aliaksien käyttäminen on joinissa välttämätöntä ainoastaan jos samaa taulua käytetään useammin kuin kerran.
Grez, mitä pidät tästä ideasta:
SELECT SUM(tarve.tTarve) maara
FROM tarve
JOIN ryhma ON tarve.R_Id = ryhma.R_Id
GROUP BY T_Id
Ainakin phpmyadmin -hakutuloksessa osaa jaotella määrät oikein
3
2
4
7
jne.
- Seuraava jännitysnäytelmä onkin miten saan järkevimmin näkymään etusivulla tapahtumien määrän ja varaukset. 2 erillistä sql-lauseketta lienee järkevin. Thänks G. taas oppii uutta!!
Lisäys: UNION ei toimi koska taulun kolumnien määrä ei täsmää.
Lisäys:
Nyt koodi tämä. Eli ongelma. Minulla on 2 SQL-lausetta, mutta mikä olisi mahdollinen tapa saada $query2 osaksi sisältöä. Jotenkinhan nuo pitää saada yhdistettyä nuo SQL-lauseet. Vai onko täysin mahdoton. Miten tuonne sekaan edes voi echottaa??
ja huom! vältän tällaisia <?php echo="WTF!?" ?> html-koodin sekaan.
// haetaan kaikki tapahtumat joiden status on 'Tapahtumat' päivämäärän mukaan
// lasketaan varattaujen työvuorojen määrä per tapahtuma
$query = "SELECT tapahtuma.*,
COUNT(varaus.Tapahtuma_Id) AS varattu
FROM tapahtuma
LEFT JOIN varaus On Tapahtuma_Id = T_Id
WHERE tStatus = 'Tapahtumat'
GROUP BY T_Id
ORDER BY tPvm";
// haetaan tarveluku tarve taulusta pienen laskutoimituksen avulla
$query2 = "SELECT SUM(tarve.tTarve) AS tarve
FROM tarve
JOIN ryhma ON tarve.R_Id = ryhma.R_Id
GROUP BY T_Id";
$result = $mysqli->query($query) or die ($mysqli->error.__LINE__);
// käsitellään haettu tieto
if($result->num_rows > 0) {
// taulukon otsikot
echo "<table id='taulukko'>
<tr>
<th>tapahtuma</th>
<th>pvm</th>
<th>klo</th>
<th>sijainti</th>
<th>tarve</th>
<th>varat.</th>
</tr>";
// tietosisältö
while($row = $result->fetch_assoc()) {
echo "<tr>
<td><a href='index.php?sivu=varaa&T_Id=" . stripslashes($row['T_Id']) . "'>" . stripslashes($row['tNimi']) . "</a></td>
<td>" . stripslashes($row['tViikonpaiva']) . " " . stripslashes($row['tPvm']) . "</td>
<td>" . stripslashes($row['tAlkaa']) . "-" . stripslashes($row['tLoppuu']) . "</td>
<td>" . stripslashes($row['tSijainti']) . "</td>
<td>" . stripslashes($row['tarve']) . "</a></td>
<td>" . stripslashes($row['varattu']) . "</a></td>
</tr>";
}
echo "</table>";
}Toki voit joinia useampiakin tauluja samaan kyselyyn. Myös alikyselyiden teko on mahdollista. Tosin joskus (usein) on järkevämpää yhdistellä useamman kysymyksen tuloksia ohjelman päässä kuin yrittää saada kaikki mahdollinen haettua yhdellä kyselyllä.
Noniin.. jos nyt tilanne on se että jätän nuo 2 eri SQL-kyselyä ennalleen, niin miten saisin ne tulostettua oikein? Koodi on ylläolevassa postauksessa.
Jos tilanne on se että ei pysty tulostamaan samaan tauluun, niin voiko esim. joku kokenut: Metabolix, alkemisti, grez jne. kertoa onko tämä ylipäätään mahdollista? Turhaan koluan tietoa netistä, kiitos!
Hei, nopea kysymys. Olen yrittänyt etsiä Googlen kautta tietoa miten hallita istuntoja (session control). Haluaisin oppia tutkimaan mille tasolle käyttäjä kuuluu ja mitä tässä tasossa olevalle henkilölle näytetään.
Onko kellään tietoa tutoriaalista tällaiseen, kiitän?
Käyttäjän taso pitää tietenkin tallentaa tietokantaan. Se myös haetaan tarvittaessa sieltä.
Käyttäjän tunnistautumiseen käy jokin satunnainen merkkijono, joka tallennetaan kirjautumisen yhteydessä sekä tietokantaan että istuntoon.
Tietokannassa on taulu työntekijät, jossa jokaisella työntekijällä on oma ryhmä id-numero. Eli käyttäjä: Testaaja, 1
Tasoja, tai noita ryhmiä on yhteensä 4 kpl. Tuota alempaa riviä en valitettavasti ymmärrä. Eli kun tallennan käyttäjän "tiedot" nimellä -> $_SESSION['id'] niin tuossa istunnossa on jokin merkkijono, eli käyttäjän tiedot. Esim. dvhisv434763jhrj ..jotenkin noin.
No tämä siis pitää käyttäjän sisällä suljetussa osiossa. Mutta miten erotella käyttäjä 1 ja 2 toisistaan, jotta eivät voi varata työvuoroja muuta kuin oman ryhmän tapahtumiin?
Tapahtuma 1
- vain ryhmä 1 työntekijät
Tapahtuma 2
- vain ryhmä 2 työntekijät
Miten teen tuon tarkistuksen ja missä vaiheessa. Eli kirjoitanko index.php tiedostoon tutki mihin ryhmään käyttäjä kuuluu sen jälkeen kun hän on kirjautunut sisään. Niin ja miten tämä tehdään. Tavallaan haluaisin tietää onko SESSION_SET_SAVE_HANDLER se funktio jota alan soveltamaan.
SESSION_SET_SAVE_HANDLER (sets user-level session storage function)
Lisäys:
Okei sen verran vielä että... minulla on $_SESSION['usr']
Haen siihen työntekijät taulusta seuraavat tiedot: id-numero, käyttäjänimi, ryhmä-id.
Eli nyt sitten tuossa istunto-muuttujassa on tallennettuna esimerkiksi:
id-numero = 1
käyttäjänimi = testaaja
ryhmä = 3
Noniin eli kaiketi työvuoron varaamisen yhteydessä tarkastelen tuota sessiota ja jos siinä ei ole ryhmän kohdalla sitä lukua jota löytyy tapahtumasta niin erroria peliin.
Tapahtuma A:
ryhmät: 1,2,4
Näin ollen tämän testaaja-käyttäjän kohdalla näytettäisiin että hän ei voi varata työvuoroa koska tämä tapahtuma on ryhmille 1,2,4. ?? Olenko lainkaan jäljillä..
Lisäys:
Tässä sessiot, jotka rakensin:
$_SESSION['id'] = $row['id'];
$_SESSION['usr'] = $row['usr'];
$_SESSION['ryhma'] = $row['ryhma'];
..eli tietokannasta haetaan työntekijät taulusta id-numero, käyttäjänimi, ryhmä-id. Varaa työvuoro sivun yläosassa teen näin:
if($_SESSION['id']) {
Eli tähänkö kohtaan pitäisi rakentaa ehto? Jos $_SESSION['ryhma'] = on eri kuin jokin tapahtuman ryhmä-id numeroista, älä avaa varaa työvuoro lomaketta? Hmm.. no tähän ei tarvitse vastata, mutta näin omalla logiikallani päättelen asiaa. Kiitos tuesta Macro.
Kuten Macro jo aikaisemmin mainitsi niin tallenna istuntoon vain käyttäjän tunnistukseen tarvittava merkkijono kirjautumisen yhteydessä esimerkiksi
<?php
// kirjautuminen.php
$sql = mysqli->prepare("SELECT uniikkiTunnus FROM kayttajat WHERE kayttaja = ? AND salasana = ?");
// Kyselyn suorittamiset jne.
$_SESSION['kayttaja'] = $row['uniikkiTunnus'];Kyseisen tunnuksen perusteella haet sitten joka kerta tarvitsemasi tiedot.
<?php
// varaatyovuoro.php
$sql = mysqli->prepare("SELECT id, kayttaja, ryhma FROM kayttajat WHERE uniikkiTunnus = ?");
// Kyselyn suorittamiset jne.
// Parametrina syötetään kyseinen $_SESSION['kayttaja']
$kayttaja['id'] = $row['id'];
$kayttaja['kayttaja'] = row['kayttaja'];
$kayttaja['ryhma'] = $row['ryhma'];
if (!in_array($kayttaja['ryhma'], $tapahtuma['ryhmat'])) {
// Voidaan ohjata esimerkiksi virhesivulle tai tulostaa teksti ettei käyttäjä kuulu kyseiseen ryhmään, eikä näin ollen voi varata tapahtumaa
header('location: virhesivu.php');
}
// Tulostetaan varauslomakeNoniin, Othnos sun muut. Tein omalla tyylilläni. Eli työvuoroa varatessa tarkistetaan mihin ryhmään kuuluu (session). Sitten kun menee ylläpitoon niin työntekijän oman numeron mukaan tsekataan onko ylläpitäjä (session).
kiitän.
-------------------------------------------------------------------
Mutta aikaa kuluu.. eli olen nyt vaiheessa jossa rakennan ylläpito-osiota. Työntekijän tallentaminen tietokantaan toimii hyvin. Mutta nyt kun teen lomaketta, jossa idea on tehdä uusi tapahtuma, niin nostin hieman rimaa.
VAATIMUKSET:
Kaikissa lomakkeen kentissä joissa voi käyttää jQuerya niin myös tehdään. Eli tällainen Datepicker toimii, mutta Timepicker ei. Siksi olisinkin yleisesti kysynyt voisiko joku hieman selventää minulle miten tämä upea jQuery UI toimii!?
- eli Datepicker asennus onnistui
- Timepicker Add on tuottaa päänvaivaa eli asentaminen, mitkä tiedostot ja mihin kansioihin.
http://trentrichardson.com/examples/timepicker/
Hei haen tällaisen rivin tietoa tietokannasta: 2012-09-21
Nyt tapahtumat-sivulla näytetään tämä muodossa: 21.9.2012
Kun lisään merkin "D" niin saan esim. "Fri" <-Miten muuttaa nuo tietokannasta tulevat päivämäärät niin että saan muokattu englanninkieliset lyhenteet suomenkielisiin lyhenteisiin?
<td>" . date("D j.n.Y", strtotime($row['tPvm'])) . "</td>Voisit käyttää date asemesta strftime
Kiitän Grez, mutta ehkä selitin huonosti. Eli haluaisin muuttaa lyhenteet jotenkin näin:
$viikonpaivaLyhenne = array ( "Mon" => "Ma", "Tue" => "Ti", "Wed" => "Ke", "Thu" => "To", "Fri" => "Pe", "Sat" => "La", "Sun" => "Su" );
// tietosisältö while($row = $result->fetch_assoc()) { // tulostetaan... echo "<tr><td>" . date("D j.n.Y", strtotime($row['tPvm'])) . "</td></tr>";
Eli tuo iso "D" tuo tietokannasta nyt tällaisia tietoja: Fri, Mon, Tue jne. ne suomalaisiin muotoihin Pe, Ma, Ti jne.
No otat jokaista date('D'):n tuottamaa arvoa vastaavan suomenkielisen käännöksen tuosta $viikonpaivaLyhenne-taulukostasi, y?
Miten niin otan.. while-silmukan jälkeen pitäisi saada käsittääkseni kaikki $row['tPvm'] -rivit käymään läpi jokin muutos? ja sitten vielä tulostaa ne.
Sinäänsä harmi että tuota "D" arvoa ei voi jotenkin lokalisoida, jolloin lyhenne Fri muuttuisi muotoon Pe
latenleffahylly kirjoitti:
Sinäänsä harmi että tuota "D" arvoa ei voi jotenkin lokalisoida, jolloin lyhenne Fri muuttuisi muotoon Pe
Ei kai tuo nyt niin kovin paljon asioita mutkistaisi, jos vaihtaisit "D" -> "N", laittaisit suomenkieliset viikonpäivät taulukkoon ja hakisit sitten taulukosta viikonpäivänumeroa vastaavan viikonpäivän?
No edelleen tuo Grezin antama esimerkki on parempi kuin käsin hakata viikonpäiviä taulukkoon. Yritin vain saada Laten käyttämään vähän omia aivojaan mutta hukkaan meni. Paria juttua pitänee kuitenkin tarkentaa:
1) Lyhyen viikonpäivän nimen symboli on %a eikä %A.
2) Pelkkä "fi_FI" ei välttämättä toimi, riippunee käyttöjärjestelmästä.
Minulla toimi seuraavanlainen variantti:
Miten tuossa Grezin esimerkissä laitetaan muuttuja: $row['tPvm'] mukaan koodiin? Ja alkemistille terveisiä, että kyllä yritän näitä itse tajuta myös. Varmaan tuo koodin yhdistäminen vielä suurimpia heikkouksiani.
-----
1.) tietokannassa on sarake tPvm
2.) sieltä tulee merkkejä kuten: 2012-09-23
3.) nämä merkit sisältävät myös viikonpäivän englanniksi vaikka se ei näy tietokannan taulussa
4.) nyt tämä päivämäärä pitäisi muokata jotenkin suomenkieliseen muotoon jolloin "D" ei olisikaan "Sun" vaan "su"
5.) hmm.. tässä vaiheessa putosin, eli miten saada muuttuja tämän sisään-> echo strftime("%A %e.%B.%Y");
6.) Entä voiko set_locale funktiota käyttää jotenkin ennen tulostamista, vai jokaisen tulostus kohdan yhteydessä..
Veikkaisinpa, että seuraavalla onnistuu:
latenleffahylly kirjoitti:
Miten tuossa Grezin esimerkissä laitetaan muuttuja: $row['tPvm'] mukaan koodiin? Ja alkemistille terveisiä, että kyllä yritän näitä itse tajuta myös. Varmaan tuo koodin yhdistäminen vielä suurimpia heikkouksiani.
No lue sitten edes vähän sitä manuaalia? Sieltä näkee välittömästi, että strftimelle voi antaa toisena parametrina kellonajan unix timestamppina. Tai olisihan sen hokaissut varmasti ilmankin.
Hei, yritän tallentaa tietoa Checkboxseista tietokantaan. Lomakkeelta hakeminen onnistuu, mutta miten SQL-lause muodostetaan?
$valittuTapahtuma = $_POST['T_Id']; $_POST['chk']; // 6.) tallennetaan for($x=0; $x<count($_POST['chk']); $x++) { mysql_query("INSERT INTO varaus ( Tapahtuma_Id, tyontekijanumero, varno, date ) VALUES ( '" . $valittuTapahtuma . "', '" . $_POST['chk'][$x] . "', '" . $_POST[varno] . "', '" . $_POST[date] . "' )"); }
Ehtiikö kukaan hieman katsoa tai kertoa miten-> $_POST['chk']; -muuttujasta otetaan tietoa ulos tietokantaan? (esim. for, foreach)
<?php foreach ($_POST['chk'] as $chk) { "VALUES ( '" . $chk . "' )"
PHP.netistä olisit löytänyt tuon foreachin syntaksin, mutta heitin sinulle nyt valmiin esimerkinkin kyseiseen tapaukseen sen käytöstä.
Aikaisemmin käytit mysqli:tä, niin miksi nyt käytät mysql_-funktioita suoraan vaikka aikaisempi tapasi oli huomattavasti parempi?
Myöskin sinulta puuttuu nuiden $_POST[] sisältä '' -merkit.
Kiitän Othnos, for-silmukka myös mahdollinen. Yritän jatkossa siirtyä pdo:n käyttöön. Hulluinta on nyt se että tässä tapahtumapalvelu projektissa käytän 3 eri tietokanta mallia:
-pdo
-mysqli
-mysql
latenleffahylly kirjoitti:
Kiitän Othnos, for-silmukka myös mahdollinen. Yritän jatkossa siirtyä pdo:n käyttöön. Hulluinta on nyt se että tässä tapahtumapalvelu projektissa käytän 3 eri tietokanta mallia:
-pdo
-mysqli
-mysql
Ei kannata yrittää, siitä ei paljoa ole iloa. Tee se, eläkä yritä. Ja tee se jo nyt heti, muuta kakki pdo:ksi, ei niitä kannata käyttää sekaisin, turhaa vain sekottaa. Ja jos siirrät sitä tuonnemmaksi, et sitä tule tehneeksi.
mysqli?
dartvaneri kirjoitti:
muuta kakki pdo:ksi
En tiedä oliko tämä tarkoituksella vai kirjoitusvirhe, mutta hymähdin.
Noniin.. eli toki muuttaisin itsenikin siinä samalla koodariksi jos pystyisin. Eli PDO on hieno mutta vaikea koodaus tapa. Minulla on vanhaa koodia eli vanha tapa tehdä, joten.. sen korvaaminen uudella tavalla ei ole aivan 1 -> yhteen.
Mutta toisaalta se on juuri näin, muutos on tehtävä heti ja lopettaa vanhan koodin suoltaminen. (PDO)
latenleffahylly kirjoitti:
Eli PDO on hieno mutta vaikea koodaus tapa.
Wait wat?
Kyllä mä voin sanoa, että PDO on ihan samanlaisien kyselyiden kirjoittamista kuin "wanhalla tavallakin". Ainoa, että mysql_real_fckin_escapen tille tuleekin usein pelkkä kysymysmerkki.
latenleffahylly kirjoitti:
hieno mutta vaikea koodaus tapa
En kyllä ymmärrä miten se on "vaikea". Paljonko sulla nyt sitten niitä kyselyitä on? Jos yhden muuttamisen menee minuutti niin 60 kyselyä saa vaihdettua PDO:ta käyttäväksi tunnissa. Jos sulla on tollaisessa systeemissä paljon enemmän kuin 60 kyselyä, niin sattaa olla paikallaan tehdä muutakin refaktorointia.
dartvaneri: PHP.net mysqli tai google mysqli. Kuitenkin hyvin samantyyppinen kirjasto, kuin PDO, mutta tarjoaa mahdollisuuden myös proseduraaliseen ohjelmointiin. Lisää voit lukea vaikka täältä.
latenleffahylly kirjoitti:
Noniin.. eli toki muuttaisin itsenikin siinä samalla koodariksi jos pystyisin.
Tarvitseeko muuttaa? Minun käsitykseni mukaan olet jo koodari. Koodarihan on vain ihminen, joka kirjoittaa koodia, eikä mielestäni tarvitse edes tehdä sitä päivittäin.
latenleffahylly kirjoitti:
Eli PDO on hieno mutta vaikea koodaus tapa. Minulla on vanhaa koodia eli vanha tapa tehdä, joten.. sen korvaaminen uudella tavalla ei ole aivan 1 -> yhteen.
Mutta toisaalta se on juuri näin, muutos on tehtävä heti ja lopettaa vanhan koodin suoltaminen. (PDO)
Joo, ei se ihan yks yhteen ole, vaikka ei se kauaksi heitäkkään.
Grez kirjoitti:
dartvaneri kirjoitti:
muuta kakki pdo:ksi
En tiedä oliko tämä tarkoituksella vai kirjoitusvirhe, mutta hymähdin.
:) Pieni viba tullu siinä.
Othnos kirjoitti:
dartvaneri: PHP.net mysqli tai google mysqli. Kuitenkin hyvin samantyyppinen kirjasto, kuin PDO, mutta tarjoaa mahdollisuuden myös proseduraaliseen ohjelmointiin. Lisää voit lukea vaikka täältä.
Juu no toi 'mysqli?' jäi ihan vahingossa. Olin kirjottamassa jotain kysymystä ja sitten päätinkin jäättää kysymättä, kiireessä jäi sitten toi tohon loppuun.
Grez kirjoitti:
latenleffahylly kirjoitti:
hieno mutta vaikea koodaus tapa
En kyllä ymmärrä miten se on "vaikea". Paljonko sulla nyt sitten niitä kyselyitä on? Jos yhden muuttamisen menee minuutti niin 60 kyselyä saa vaihdettua PDO:ta käyttäväksi tunnissa. Jos sulla on tollaisessa systeemissä paljon enemmän kuin 60 kyselyä, niin sattaa olla paikallaan tehdä muutakin refaktorointia.
Noh pikainen tarkistus palvelimelta jonne on pääsy. 400+ tiedostoa. Ok kaikki ei oo php tiedostoja mutta aikamoinen osa noista on. Ja php tiedostoissa melkein kaikissa useampi kysely. Ei olisi pienin urakka vaihtaa sivuston alkuperäisen tekijän omaa sql wrapperia pdo:n. Ja kriittisempääkin urakkaa piisaa kuin vaihdella vanhaa toimivaa koodia.
Tosin varmaan jossainvaiheessa siirrytään kun on lisää aikaa mutta ny saa olla.
tneva82 kirjoitti:
Noh pikainen tarkistus palvelimelta
Jaa siis kyseessä on nimenomaan työvuoron varausohjelma, jossa on käytetty sekaisin mysql-, mysqli- ja pdo-kirjastoja? Jos ei, niin ei hirveesti liity mun viestiin.
Grez kirjoitti:
tneva82 kirjoitti:
Noh pikainen tarkistus palvelimelta
Jaa siis kyseessä on nimenomaan työvuoron varausohjelma, jossa on käytetty sekaisin mysql-, mysqli- ja pdo-kirjastoja? Jos ei, niin ei hirveesti liity mun viestiin.
Pointtina oli että ei se ole välttämättä niin nopeata vaihtaa PDO:n kuin annoit ymmärtää. Joo yhdestä tiedostosta sen tekee nopeasti mutta harvemminpa mikään systeemi on vain 1-2 php tiedostoa. Paitsi toki koulun harjoittelutyöt.
Viestissäni kirjoitin aika selkeästi että koska tuollaisessa työnvarausjärjestlemässä josa käytetään sekaisin eri tietokantakirjastoja tuskin on hirveästi yli 60 muutettavaa kyselyä, niin niiden muuttamisessa ei pitäisi kestää kovin kauaa. Kirjoitin että jos kyselyitä on sellaisessa hirveästi enemmän, niin sille luultavasti tekisi refaktorointi muutenkin hyvää.
En edelleenkään löydä mitään pointtia viestistäsi, jos siinä käsiteltiin jotain muuta järjestelmää.
Jos sulla on satoja skriptitiedostoja ja JOKAISESSA käpistellään tietokantaa, niin sovelluksen arkkitehtuurissa on kyllä menty ihan metsään.
The Alchemist kirjoitti:
Jos sulla on satoja skriptitiedostoja ja JOKAISESSA käpistellään tietokantaa, niin sovelluksen arkkitehtuurissa on kyllä menty ihan metsään.
Että kun olis tykkää nappula.. Tuo on ihan perseestä ja kauheeta korjata jos tommoseen projektiin jostain jumalan ihmeestä joutuu.
Noniin.. arvausputkalaiset.. elikkä ongelma on että kun yhdistää pdo:lla tai hakee tietoa ja tulostaa sitä niin se on erilainen tapa kuin esim. mysqli ja mysql, mutta ei selityksiä, kaikki muutetaan aikanaan.
Ei siinä ole mitään erilaista mihinkään muuhun verrattuna. Suoritat SQL-kyselyn ja sitten iteroit tulosjoukkoa. Jos näet tässä jonkin ongelman, niin sitten sinun täytyy opetella käyttämään PDO:ta kunnes hallitset sen. Lopetat vaikka kaiken muun koodaamisen ja keskityt erilaisiin PDO-esimerkkeihin, kunnes ymmärrät täysin, mistä asiassa on kyse ja miten homma toimii. Ja saman saisit toistaa kaikkien muidenkin asiakokonaisuuksien kohdalla.
Et yksinkertaisesti voi sulkea silmiäsi ongelmilta ja yrittää pyristellä pelkän copy-pasten varassa. Se on sekä säälittävää että vaarallista, kun et ymmärrä "tekemistäsi" järjestelmistä yhtään mitään.
Hmm.. mielestäni en vain copy-paste -taa. Olen rakentanut järjestelmän itse materiaalista jota olen netistä kerännyt. Myönnän että en osaa oikeastaa php:tä koodata ihan tyhjästä tiedostosta, se harmittaa.
Nyt muutin Tapahtumat -sivun joka oli tehty Mysqli tyylillä PDO- tyyliseksi. Mutta kun siirryn seuraavaan tiedostoon varaa.php, niin alkuun tulee heti eteen if else rakenteet..
Ohjelmointiputkan oppaissa PDO:ta käsitellään lyhyesti ja siitä on ollut apua, mutta missä suurempi pdo opas?
latenleffahylly kirjoitti:
Hmm.. mielestäni en vain copy-paste -taa. Olen rakentanut järjestelmän itse materiaalista jota olen netistä kerännyt. Myönnän että en osaa oikeastaa php:tä koodata ihan tyhjästä tiedostosta, se harmittaa.
Nyt muutin Tapahtumat -sivun joka oli tehty Mysqli tyylillä PDO- tyyliseksi. Mutta kun siirryn seuraavaan tiedostoon varaa.php, niin alkuun tulee heti eteen if else rakenteet..
Ohjelmointiputkan oppaissa PDO:ta käsitellään lyhyesti ja siitä on ollut apua, mutta missä suurempi pdo opas?
Heitä koodia, missä kohtaa tule ongelma, ja kerro mikä ongelma, niin kyllä me kerrotaan miten se kannataa tehdä.
Lisäys: Tuolla oppaalla, mikä putkassa on, saa kyllä varmasti kaiken perusjutun tehtyä, eli pärjäät sillä kyllä.
Tässä on netistä PDO:ta
$sql = "SELECT COUNT(*) FROM folks"; if ($STH = $DBH->query($sql)) { # check the row count if ($STH->fetchColumn() > 0) { # issue a real select here, because there's data! } else { echo "No rows matched the query."; } }
Nyt tässä on MYSQL tapa, joka on karmeaa katsottavaa
// otetaan talteen tapahtuman numero
$T_Id = $_REQUEST['T_Id'];
// haetaan tapahtuman tarveluku
$sql_haetietoja = "SELECT SUM(tarve.tTarve) AS tarve
FROM tapahtuma
JOIN tarve ON tapahtuma.T_Id = tarve.T_Id
WHERE tapahtuma.T_Id = " . $T_Id;
if (!$hae = mysql_query($sql_haetietoja)) {
die('Error: ' . mysql_error());
}
// $tulos muuttujaan tallennetaan tarveluku
else {
$tulos = mysql_fetch_row($hae);
jne.Mikä siis on ongelma? Saada tuo koodi muutettua PDO:ksi?
Lisäys:
Jos se siis oli onglema niin:
$T_Id = $_REQUEST['T_Id'];
$sql = "SELECT SUM(tarve.tTarve) AS tarve
FROM tapahtuma
JOIN tarve ON tapahtuma.T_Id = tarve.T_Id
WHERE tapahtuma.T_Id = ?";
$kysely = $yhteys->prepare($sql);
$kysely->execute(array($T_Id));
$tulos = $kysely->fetch();
$hakutulos = $tulos[$hae];latenleffahylly kirjoitti:
Hmm.. mielestäni en vain copy-paste -taa. Olen rakentanut järjestelmän itse materiaalista jota olen netistä kerännyt. Myönnän että en osaa oikeastaa php:tä koodata ihan tyhjästä tiedostosta, se harmittaa.
Tämä on aidon copy-paste-koodarin täydellinen määritelmä.
latenleffahylly kirjoitti:
Ohjelmointiputkan oppaissa PDO:ta käsitellään lyhyesti ja siitä on ollut apua, mutta missä suurempi pdo opas?
PDO:n manuaalin löydät luonnollisesti PHP.netistä.
okei kiitos, eli yritän tulostaa koodia ja tarvitsen noita if- else- rakenteita. Eli siis miten tulostaa kokonainen SQL-lause, jossa mukana useita sarakkeita ja useita rivejä...
Minulla on nyt tällaista tyyliä käytössä, onko ihan hyvä tapa?
$haeTapahtumat = $yhteys->query("SELECT T_Id FROM tapahtuma");
// alempana
while ($row = $haeTapahtumat->fetch(PDO::FETCH_ASSOC)) {
echo '<tr>
<td><a href="index.php?sivu=muokkaa_tapahtuma&T_Id=' . $row['T_Id'] . '">' . $row['tNimi'] . '</a></td>
</tr>';
}Pitäisikö esim. while käskyn alla olla: $T_Id = $row['T_Id'];
latenleffahylly kirjoitti:
okei kiitos, eli yritän tulostaa koodia ja tarvitsen noita if- else- rakenteita. Eli siis miten tulostaa kokonainen SQL-lause, jossa mukana useita sarakkeita ja useita rivejä...
Kerrohan nyt ihan kunnolla, selkeästi ja ajateltuna, että mitä sinä nyt haluat?
Voit tulostaa SQL-kyselyitä aivan kuin mitä tahansa muutakin tekstiä: käyttämällä esim. printiä, echoa tai printf:ää.
SQL-kyselyitä voit generoida ajonaikaisesti ihan kuten generoisit mitä tahansa muitakin merkkijonoja. Ne ovat vain tavallista tekstiä. Merkkijonoja voit katenoida toisiinsa käyttämällä esim. pisteoperaattoria ('.') tai funktiota sprintf.
Mikäli haluat tulostaa SQL-kyselyn tuottaman tulosjoukon, niin sen voi tehdä yksinkertaisimmillaan funktiolla print_r:
Mikäli tarvitset paremmin muotoillun tulosteen, niin fetch() ja fetchAll() palauttavat ihan tavallisen taulukon (array), joita voit käpistellä kuten käpistelisit mitä tahansa muitakin taulukoita.
latenleffahylly kirjoitti:
Minulla on nyt tällaista tyyliä käytössä, onko ihan hyvä tapa?
Miksi ei vain suoraan $query->fetch()?
$getEvent = $connect->prepare("SELECT T_Id, tNimi FROM events");
$getEvent->execute();
while($result = $getEvent->fetch()){
echo '
<tr>
<td>
<a href="index.php?sivu=muokkaa_tapahtuma&T_Id='.$result['T_Id'].'">'.$result['tNimi'].'</a>
</td>
</tr>
';
}latenleffahylly kirjoitti:
Pitäisikö esim. while käskyn alla olla: $T_Id = $row['T_Id'];
Ei taida olla tässä tapauksessa mitään hyötyä.
Edit. Koodia korjattu.
Noniin nyt PDO:ta harjoiteltu. PHP-kirja + putkan opas. Ihan helppoja nämä perus haut ja viennit (update,insert,delete).
Tuota htmlspecialchar merkintää jokaisen tietopaketin edessä ihmettelen. Itse muuten käytän PDO-yhteyden luonnissa utf8-merkistöä, hyvin toimii.
The Alchemist kirjoitti:
Jos sulla on satoja skriptitiedostoja ja JOKAISESSA käpistellään tietokantaa, niin sovelluksen arkkitehtuurissa on kyllä menty ihan metsään.
Hei, kerrotko lisää tästä, tai annatko vinkin mistä löytyy lisää tietoa? Mikä on oikea tapa / miten PHPssä toteutetaan tietokantakerros, vaatiiko olion?
latenleffahylly kirjoitti:
Tuota htmlspecialchar merkintää jokaisen tietopaketin edessä ihmettelen.
Minun on vaikea käsittää, miten voit ihmetellä jatkuvasti kaikkia sellaisiakin asioita, jotka selitetään oppaissa oikein esimerkkien kanssa.
Kokeilepa tallentaa vaikka tapahtuman nimeksi "<script>alert(location)</script>" tai edes "a<b ja b>a" ja katso, mitä sivulla näkyy htmlspecialchars-funktion kanssa ja ilman sitä.
Turso kirjoitti:
The Alchemist kirjoitti:
Jos sulla on satoja skriptitiedostoja ja JOKAISESSA käpistellään tietokantaa, niin sovelluksen arkkitehtuurissa on kyllä menty ihan metsään.
Hei, kerrotko lisää tästä, tai annatko vinkin mistä löytyy lisää tietoa? Mikä on oikea tapa / miten PHPssä toteutetaan tietokantakerros, vaatiiko olion?
En koe itseäni minkäänlaiseksi auktoriteetiksi tämän suhteen. Oma politiikkani on kuitenkin se, että noudatan mahdollisimman pitkälle MVC-paradigmaa: tietokantaan yhteydessä ovat ainoastaan malleiksi (models) miellettävät luokat. Ne muodostavat kaikki SQL-kyselyt ja antavat ne suoritettavaksi erilliselle tietokantaoliolle. Mikään muu järjestelmän osa ei näe SQL:ää lainkaan.
Lisäksi yritän järjestellä koodin siten, että yhtä tietokantataulua käpistellään mahdollisimman harvassa tiedostossa. Näin tietokantamuutokset on helppo päivittää koodiinkiin, kun ei tarvitse arpoa, että mikä kaikki hajoaa, jos lisää tai poistaa jonkin sarakkeen taulusta X.
Itse olen viime aikoina käyttänyt paljon Doctrinea, joka soveltuu hyvin oliojärjestelmiin. Siinä abstraktiot on viety niin pitkälle, ettei ko. kirjastoa käyttävän koodarin tarvitse oikeastaan itse kirjoittaa riviäkään SQL:ää, koska se on piilotettu muiden mekanismien sisään.
Doctrinen kanssa perustapaukset (olioiden lukeminen ja tallentaminen tietokantaan) menee täysin automaattisesti, monimutkaisempia keissejä varten on SQL:stä jalostettu "olioversio" DQL (Doctrine Query Language), joka on mielestäni helppoa oppia kenen tahansa, joka taitaa SQL:n perusteet.
Olioitahan ei ole mikään pakko käyttää, mutta mielestäni ne tekevät PHP-koodaamisesta mukavampaa ja kätevämpää varsinkin yhdistettynä autoloadiin.
Hei, nopea kysymys.. minulla on lomake johon syötetään:
- Etunimi
- Sukunimi
//tuossa ovat sallitut merkit mitä tekstikenttiin voi lomakkeella syöttää
[^A-Za-z\-\Ä\ä\Ö\ö\Ü\ü\Å\å\ ]
Nyt sitten yritän muodostaa käyttäjänimen Etunimi + Sukunimi = käyttäjänimi
- Eli millä funktiolla kannattaa käsitellä merkkijonoa.
Ä -> A å -> a " "
-> ""
jne.
Käyttäjänimi pitäisi olla pienellä, yhteen, ja nk. erikoismerkit tavallisina merkkeinä.
str_replace (" ", "", $sukunimi);
strtolower($sukunimi);Lisäys:
..noniin
Luulen että teenkin niin että käyttäjän sähköpostiosoitteesta tulee hänen käyttäjänimensä. Ne käyttäjät joilla ei ole sähköpostia, muuttuvat ulkopuolisiksi työntekijöiksi joiden työvuorot varaa ylläpitäjä.
kiitän!
latenleffahylly kirjoitti:
Eli millä funktiolla kannattaa käsitellä merkkijonoa.
Ä -> A
å -> a
" " -> ""
jne.
En tiedä tuolle mitään valmista funktiota, mutta itse olen käyttänyt esim. tällaista:
$korvattavat = array("ä", "ö", "å", "Ä", "Ö", "Å"); $korvaavat = array("a", "o", "a", "a", "o", "a"); $käyttäjänimi = str_replace($korvattavat, $korvaavat, $käyttäjänimi);
Tuosta osannet soveltaa tarvittaessa.
jaketsu kirjoitti:
En tiedä tuolle mitään valmista funktiota, mutta itse olen käyttänyt esim. tällaista:
....
Miksei Ä, Ö ja Å saisi olla korvauksen jälkeen isoja? "Åbo" -> "abo"
No vaikka siksi, että käyttäjänimet oli speksattu olevan pelkästään pieniä kirjaimia.
Eikö noista epäkelvollisista merkeistä voisi mieluummin huomauttaa käyttäjää virheilmoituksella, kuin mennä käpistelemään merkkejä automaattisesti hissun kissun?
Siis ymmärrän, että nykyaikana on hyvä että järjestelmät tekevät asioita automaattisesti antaen sujuvamman kuvan järjestelmän toiminnasta, mutta ymmärsin että tässä tapauksessa puhutaan kuitenkin käyttäjätunnuksesta, jonka käyttäjä itse haluaa asettaa.
Edit:
viesti ei ole suunnattu Alkemistille. Näemmä kirjoitettiin viestit samaan aikaan
Mjoo, enpä ole jaksanut tämän kaverin tekemisiä enää pitkilleen vakavasti ottaa, niin en itsekään tuota älynnyt ajatella. Käyttäjätunnuksia tai salasanoja ei tietenkään saa mankeloida sen jälkeen, kun käyttäjä on tiedot antanut ja järjestelmä ne hyväksynyt. Eikä kyllä mitään muitakaan tietoja saa "korruptoida" niiden hyväksymisen jälkeen.
Alkemistille sen verran tiedoksi että alunperin idea oli että ylläpitäjä luo työntekijän koska kyseessä extranet.
Etunimi
Sukunimi
muuttuvat käyttäjänimeksi-> (etunimisukunimi).
..Mutta sitten pohdinnan jälkeen sain neuvon että sähköpostiosoite voisi toimia uniikkina käyttäjänimenä. Käyttäjän sähköposti näkyy vain hänelle itselleen.
The Alchemist kirjoitti:
Mjoo, enpä ole jaksanut tämän kaverin tekemisiä enää pitkilleen vakavasti ottaa
Miksi?
Esimerkiksi sen takia, että olet muutaman kerran sanonut, että aiot ensin opetella ohjelmoimaan php:llä ennen uusien projektien ottamista. Sitten kuitenkin lähdet räpeltämään, etkä ole tainnut vaivautua perehtymään kieleen yhtään. Edelleen vain kopioit muiden koodia.
Hmm.. taidat olla oikeassa siinä että en ole perehtynyt tarpeeksi kovalla motivaatiolla PHP:hen. Hankin iPadiin kirjan: "Beginning PHP and MySQL From Novice to Professional" joka on ollut hyvä. Mutta oikeiden esimerkkien löytäminen on minulle vaikeinta.
Olen miettinyt sellaista että jos käytän usein esim. tiedon hakemista tietokannasta PDO:lla. Esim. näin:
$kysely = $yhteys->prepare("SELECT * FROM tuotteet");
$kysely->execute();Niin sen sijaan että (Copy Paste) minun tulisi osata kirjoittaa nuo 2 riviä koodia tyhjästä? Entä kun koodia on paljon, oppiiko ihminen muistamaan lukuisia eri rivejä?
Tavallaan vaikeinta on hahmottaa se miten aloitatte koodaamaan tyhjälle tiedostolle. Teettekö ensin HTML5 tyylisen rakenteen. Body osaan PHP tagit ja erilliseen tiedostoon esim. tietokantaan yhdistämisen, jota ei tarvitse kutsua koska tiedosto includataan header.php tiedostossa... Olen miettinyt että minulla ei välttämättä ole kykyä oppia koodaamaan PHP:tä korkeammalla tasolla.
Olen aloittanut liian vaikeista projekteista tai jotain.
Nyt muutan vanhaa koodia PDO tyyliseksi. Kaikki sivut käyn läpi ja yritän samassa miettiä mitä teen. Ja alkemisti, en pelkästää kopioi muiden koodia. Usein teen niin että testi.php tiedostoon alan lähes tyhjästä rakentamaan jotain toimintoa ja jokaisen rivin jälkeen tutkin mitä koodi tulostaa.
Kylläkin projektissani useat asiat toistuvat ja tavallaan pysyn lähes koko ajan mukavuusalueellani. Jokatapauksessa haluan sanoa, että panostaminen kalliiseen PHP kirjaan on hyvä. Minulta löytyy aitoina kirjoina: "Web-ohjelmointi, Ari Rantala" ja "HTML 5 uudet ominaisuudet, Jukka K. Korpela" - Sähköisinä kirjoina iPadissa on mm. "Steve Jobs", "Redesigning the Web + lisäosa", "User Experience", "CSS3", "Responsive Design" ...
Näitä yritän lukea aktiivisesti ja samalla koodata omia projektejani "Tapahtumapalvelu versio 2" ja "omat kotisivut versio 5".
- Jokatapauksessa ymmärrän alkemistin turhautumisen ja minun on opeteltava koodaamaan aivan eri tasolla eli alkaa muistamaan noita rivejä ja ymmärtämään niitä paremmin. Suhtaudun intohimoisesti webbiin ja toivon oppivani jonkin tekniikan todella hyvin. PHP:n korkea ymmärtäminen on minulle liikaa. Siihen tarvitaan ihminen joka on rauhallinen, kärsivällinen ja ymmärtää matematiikkaa ja laskemista, sellaista että ymmärtää suuria kokonaisuuksia ja osaa pilkkoa ne osiin. Ymmärtää oman kehitysympäristönsä merkityksen ja tajuaa asiota palvelimesta ja miten selaimet toimivat. Ennen kaikkea tällainen ihminen osaa yhdistää netistä löytämänsä koodin pätkän oman koodinsa sekaan, tai tajuaa ainakin mallista miten joku kohta koodataan??
Noniin.. toivon myös tähän kirjoittamaani teidän mielipiteitä. Olenko unohtanut jonkun tärkeän asian. Jos kirjoittamiseni (projekti) ärsyttää niin olen valmis lähtemään pois täältä. Mutta silloin menettäisin parhaan tietämäni suomalaisen foorumin. Sen ansiosta olen pystynyt, siis kaikkien teidän ansiosta, ..olen pystynyt ratkomaan ongelmia siis ihan keskustelun tasolla. Eli tavallaan kun kirjoitan koodausongelmani tänne, niin se saa minut ymmärtämään ongelman.
Tai joku kertoo taikasanan -> ota selvää tuosta.. jne. kiitos huomiostanne.
Minä en puhu nyt mistään syvällisestä PHP:n osaamisesta vaan ihan perusteista. Kuten tuossa edellä vähän aikaa sitten kyselit, että mikä olisi paras tapa korvata merkkijonoista merkkejä toisilla merkeillä. Tai kun takeltelet yksinkertaisten silmukoiden kanssa. Tai kun sanot PDO:n olevan jotenkin vaikea käyttää.
Jos sinulla on ongelmia ymmärtää, miten PDO toimii, niin sitten koodailet itseksesi ihan yksinkertaisia PDO-skriptejä. Aloitat esimerkiksi siitä, että avaat ensin yhteyden PDO:lla, sitten suoritat yksinkertaisen SELECT-kyselyn ja tulostat löydetyt rivit esim. simppeliin listaan (<ul>) tai taulukkoon (<table>).
Tuollaisia yksinkertaisia harjoitteita toistat tasan niin kauan, et yhtään vähempää, kunnes ymmärrät täydellisesti, mitä missäkin kohtaa tapahtuu ja kunnes osaat PDO:n rajapinnan riittävän hyvin.
Ja täsmälleen samalla tavalla toimit kaikkien muidenkin asioiden kanssa, kun kohtaat jotain vaikeaa.
Kirjojen kahlaaminen tässä tilanteessa on mielestäni aivan turha juttu ja kenties jopa haitallista. Ainakaan itse en kirjoja lue oppiakseni perusasioita vaan laajentaakseni teorian tuntemusta. Teoriaa ei voi oppia, jossei osaa ensin ohjelmoida niillä työkaluilla, mitä kirjassa käsitellään.
Kyse ei ole eikä saa olla koodin ulkoa opettelemisesta. Olet edelleen vain copy-paste-koodari, josset osaa tuottaa omaa koodia. On aivan yksi hailee, kopioitko esimerkit suoraan jostain nettisivulta vai opetteletko ne päähäsi ja kopioit muistikuviasi, et edelleenkään osaa ohjelmoida yhtään mitään.
Sinun täytyy ainoastaan oppia rajapinnat. Sinun täytyy tietää lunttaamatta, mitä funktioita esim. PDOStatement-luokka sisältää, mitä parametreja mikäkin funktio ottaa ja minkä tyypin arvoja funktio voi palauttaa. Ja ennen kaikkea sinun täytyy ymmärtää, mitä mikäkin funktio tekee. Copy-pasteamalla koodia et koskaan tule ymmärtämään yksittäisten rivien arvoa koodin toiminnan kannalta, joten et voi ikinä oppia tuottamaan omaakaan koodiasi.
The Alchemist kirjoitti:
Sinun täytyy tietää lunttaamatta, mitä funktioita esim. PDOStatement-luokka sisältää, mitä parametreja mikäkin funktio ottaa ja minkä tyypin arvoja funktio voi palauttaa.
Mitä nyt sitten tarkoittaa että osaa "lunttaamatta". Omasta mielestäni on jokseenkin turhaa opetella kaikkea ulkoa ja käyttämäni kehitysympäristöt kyllä täydentää esim. funktioiden nimet kun vähän sinne päin alkaa näpytellä ja kertoo mitkä parametrit sille pitäisi antaa (onko se lunttaamista). Olen kyllä siitä samaa mieltä, että pitäisi muodostua käsitys mitä milläkin voi tehdä, niin ei tarvitse tehdä ihan hölmöllä tavalla.
Mielestäni ei ole järkevää opetella esimerkiksi parametreja ulkoa, koska tietokoneetkin on jo keksitty. Tietenkin yleisellä tasolla tiedän että replace funktio tyypillisesti ottaa ainakin lähdetekstin, etsittävän arvon ja korvattavan arvon, mutta ei todellakaan kiinnosta opetella ulkoa missä järjestyksessä ne missäkin kielessä annetaan tai ottaako esim. joku kieli niitä useita kerralla taulukkoina vai vain yhden tai voiko funktiolle antaa jotain parametreja. Mielestäni tuollaisten asioiden opettelu olisi turhaa ajan haaskausta. Toki ne käytännössä alkaa tulla "selkäytimestä" kun on jonkin aikaa koodaillut.
No en tiedä, ehkä se sitten on modernia olla riippuvainen siitä, että ide osaa näyttää tooltipissä funktion parametrilistauksen. Minua se jatkuva odottelu kyllä alkaisi tympiä. Enkä nyt jaksa alkaa purkautua tähän siitä, miten on täysin itsestäänselvää, ettei kaikkea tarvitse osata 100,0000-prosenttisesti eikä varsinkaan muistaa kaikkea aukottomasti. Tämä on itsestäänselvyys eikä siten kaipaa selittelyitä.
Ehkä minä sitten vain olen niin hemmetin täydellinen, että voin koodata tuhansia rivejä monimuotoista koodia turvautumatta siinä välissä php:n "standardikirjaston" manuaaliin kertaakaan vaikkei kukaan muu tällä planeetalla kykene samaan, mutten oikeasti halua uskoa sitä.
Ja kun sanoin "täytyy opetella", tarkoitin lähinnä, että aluksi painopiste on juurikin opettelussa eikä käyttämisessä. Ensin opetellaan asioita jossain määrin selkäytimeen, myöhemmin voi alkaa shiftata hauki on kala -iteraatiosta ihan siihen, että vähän vilaisee ensin manuskaa ja sitten koodaa taas villinä. Jos kirjojen lukeminen on turhaa, niin on myös pelkästään php.netissä surffailu pidättäytyen kokonaan koodin kirjoittamisesta.
The Alchemist kirjoitti:
Minua se jatkuva odottelu kyllä alkaisi tympiä.
Olen sit ehkä vaan tottunut liian hyviin työkaluihin, mutta ei siinä nyt yli 1/100 sekuntia joudu odottamaan. Ja kuten sanoin, niin ne kyllä oppii tehdessä käytännössä ulkoa, eli pidemmän päälle ei joudu odottelemaan. Kommentoin lähinnä sitä, että mielestäni olisi turhaa käyttää erikseen aikaa noiden ulkoa opetteluun, kun se hoituu itsestään koodaamisen ohessakin.
Mun pointti nyt ehkä oli, että kun ihmisen kyky oppia on rajallinen tiedon ja opetteluun käytetyn ajan suhteen, niin olisi hedelmällisempää opetella esim. mitä kannattaa tehdä milläkin funktiolla, kuin mitkä ne parametrit nyt tarkalleen ottaen olikaan. Ensimmäiseen kun ei voi käyttää IDEä tehokkaasti apuna ja jälkimmäiseen voi.
The Alchemist kirjoitti:
Ehkä minä sitten vain olen niin hemmetin täydellinen, että voin koodata tuhansia rivejä monimuotoista koodia turvautumatta siinä välissä php:n "standardikirjaston" manuaaliin kertaakaan
No tuskin olet ainoa, mutta olitko muka tuollainen jo ennen kuin teit ensimmäisen vakavamman projektisi?
Hyviä pointteja, kiitos. Alkemisti on varmasti oikeassa monessa kohtaa ja noudatan hänen neuvoja, mutta Grez kiitos että otit tuon esille eli Netbeans auttaa minua koodaamisessa.
"..käyttämäni kehitysympäristöt kyllä täydentää esim. funktioiden nimet kun vähän sinne päin alkaa näpytellä ja kertoo mitkä parametrit sille pitäisi antaa.."
Jokatapauksessa yritän jatkossa olla esittämättä typeriä kysymyksiä, jotka voisin itse jotenkin selvittää. Ja luin juuri PDO:sta tämän joka auttoi valtavasti:
Mod. huom: Älä kopioi toisten tekstejä (varsinkaan noin pitkiä) vaan anna linkkejä.
Patrik Bexar: NextCall Pro Livescreen -näyttösovellus, kappale 2.6, PDO.
latenleffahylly kirjoitti:
Mutta oikeiden esimerkkien löytäminen on minulle vaikeinta. – – Usein teen niin että testi.php tiedostoon alan lähes tyhjästä rakentamaan jotain toimintoa ja jokaisen rivin jälkeen tutkin mitä koodi tulostaa.
Tämä johtuu varmasti siitä, että et ymmärrä koodia. Jos ymmärtäisit paremmin, saisit lähes kaikki vastauksesi suoraan Putkan oppaista ja voisit kirjoittaa kokonaisen sivun järkevästi kokeilematta joka välissä.
latenleffahylly kirjoitti:
Entä kun koodia on paljon, oppiiko ihminen muistamaan lukuisia eri rivejä?
Ei tarvitse muistaa "lukuisia eri rivejä", vaan tarvitsee muistaa alkeet ja osata soveltaa niitä. Miten esimerkiksi pystyt laskemaan lausekkeen 1+(2*3*4*5)/15-123/3+9? Et varmasti muista tätäkään riviä, mutta osaat laskea sen, koska ymmärrät numerot ja viisi merkintää: +, -, *, / ja sulut.
Ei tarvitse osata kuin parikymmentä tällaista yksinkertaista asiaa PHP:stä, niin pystyy jo ratkaisemaan koko PHP-haasteen – jos järki riittää. Järki onkin ohjelmoinnissa tärkeämpää kuin tieto. Mikään tietomäärä ei auta, jos sitä ei osaa käyttää. Tieto vain nopeuttaa ohjelmointia sitten, kun järki on päätellyt, mitä ylipäänsä pitäisi tehdä.
Ohjelmoinnissa – kuten myös matematiikassa – tarvitaan melko pieni määrä erilaisia merkintöjä ja sanoja verrattuna luonnolliseen kieleen, eli jos pystyy oppimaan kohtuullisesti vaikka ruotsia tai ranskaa, PHP:n ei pitäisi olla muistikapasiteetista kiinni. Uskon, että useimmilla oppimisen esteenä on nimenomaan puutteellinen ymmärrys.
latenleffahylly kirjoitti:
Tavallaan vaikeinta on hahmottaa se miten aloitatte koodaamaan tyhjälle tiedostolle.
Itse ainakin aloitan siitä, mitä on tarkoitus tehdä. Jos sivun pitää näyttää käyttäjän X kaikki tapahtumat, tarvitaan loogisesti ensin tietokantayhteys, sitten se käyttäjä X ja sitten tapahtumat, ja vasta sen jälkeen voi miettiä, miten ne tulostetaan HTML-muotoon. Yleensä on järkevää myös koodissa ensin hakea kaikki tiedot ja vasta sitten aloittaa HTML:n tulostaminen. Silmukoista tulee silloin lyhyempiä ja helpompia lukea.
Pahoittelut aikaisemman postaukseni aiheuttamasta vaivasta. (Jatkossa linkitän). Metabolix suurkiitokset rohkaisusta ja järkevästä lähestymistavasta koodaamiseen, tosi hienoa tekstiä ja hyvin pystyy ymmärtämään punaisen langan.
Tämä alla oleva koodi on omistettu alkemistille, grezille ja metabolixille, koska:
- teidän innoittamana koodasin tyhjästä tiedostosta alla olevan koodin
- käytin apuna putkan opasta (pdo)
- nyt tämän päivän aikana opin muistamaan rivejä koodia mm. "prepare", "execute", "fetch" jne.
- se miksi SQL-lauseissa käytän-> "AS" merkintää, on tulevaisuutta varten eli jos seuraavassa versiossa halutaankin jokin noista tiedoista nopeasti näkyville (tarve, varaus, jvTarve)
- kommentointi tyyli on erikoinen mutta omalle tasolleni täydellinen
VARAA TYÖVUORO LOMAKE:
<?php if ($_SESSION['id']) { // 1.) tarve // haetaan tapahtuman tarve $kysely = $yhteys->prepare("SELECT SUM(tarve.tTarve) AS tarve FROM tapahtuma JOIN tarve ON tapahtuma.T_Id = tarve.T_Id WHERE tapahtuma.T_Id = ?"); // suoritetaan kysely $kysely->execute(array($_GET["T_Id"])); // tarve $tarve = $kysely->fetch(); // 2.) varaus // haetaan tapahtuman varausten määrä $kysely = $yhteys->prepare("SELECT COUNT(Tapahtuma_Id) AS varaus FROM varaus WHERE Tapahtuma_Id = ?"); // suoritetaan kysely $kysely->execute(array($_GET["T_Id"])); // varaus $varaus = $kysely->fetch(); // jos tarve ja varaus ovat identtiset-> linkkiä ei avata tapahtumat-sivulla if ($tarve[0] == $varaus[0]) { header('Location: index.php?sivu=tapahtumat'); } // 3.) T_Id, tNimi // haetaan tapahtuman numero ja nimi $kysely = $yhteys->prepare("SELECT T_Id, tNimi FROM tapahtuma WHERE T_Id = ?"); // suoritetaan kysely $kysely->execute(array($_GET["T_Id"])); // T_Id, tNimi $tieto = $kysely->fetch(); // 4.) varausaika // date $date = mktime(0,0,0,date("m"),date("d"),date("Y")); // 5.) työvuoronvarauslomake // tyontekijanumero, chk[], T_Id, tNimi, date echo '<div class="container"> <h2>← <a href="index.php?sivu=tapahtumat">Takaisin</a><span class="vali">|</span>' . htmlspecialchars($tieto["tNimi"]) . '</h2> </div>'; echo '<div class="container"> <form method="post" action="index.php?sivu=varaa_chk" class="varaaLomake" id="varaa"> <dl> <dd> <input type="text" name="tyontekijanumero" id="tarkistus" maxlength="4" class="tekstikentta" /> <input type="submit" name="submit" value="varaa työvuoro »" class="painike" /> </dd> <dd> <input type="checkbox" name="chk[]" checked="checked" /> Hyväksyn yrityksen <a href="#">käyttäjäehdot</a> ja <a href="#">työohjeet</a> </dd> <input type="hidden" name="T_Id" value="' . $tieto["T_Id"] . '" /> <input type="hidden" name="tNimi" value="' . htmlspecialchars($tieto["tNimi"]) . '" /> <input type="hidden" name="date" value="' . date("Y-m-d", $date) . '" /> </dl> </form> </div>'; // 6.) lisäinfo // järjestyksenvalvojien tarveluku $kysely = $yhteys->prepare("SELECT tTarve AS jvTarve FROM tarve WHERE T_Id=? AND R_Id=1"); // suoritetaan kysely $kysely->execute(array($_GET["T_Id"])); // jvTarve $jvTarve = $kysely->fetch(); // jos haettu luku on nolla näytetään lisäinfo if ($jvTarve[0] == 0) { echo "<div class='container'><h2><span class='red'>Huom! Vain toimintaryhmä</span></h2></div>"; } // extra tyylit2 include("assets/html/extrastyle2.html"); } else { echo '<h1>Please, <a href="index.php?sivu=etusivu">login</a> kirjaudu sisään nähdäksesi sisältö!</h1>'; } ?>
- toivottavasti koodista on hyötyä aloittelijoille, toivon ettei ylläpito poista tätä malliesimerkkiä. 1. puhtaalta pöydältä koodattu tiedostoni.
Lisäys:
Itseasiassa ainoa joka ei vielä toimi aina oikein on HEADER LOCATION. Sanoo että header on jo lähetetty.. tutkin asiaa, miten kannattaisi parhaiten ohjata käyttäjä takaisin sille sivulle missä hän on.
En avaa linkkiä jos tapahtuma jo buugattu täyteen!
\o/ Hurraa!
Yksi helppo ratkaisu header-ongelmaan on, että lisäät ennen HTML-koodin alkua (eli ennen riviä <!DOCTYPE html>) PHP-koodin ob_start(). Pidemmän päälle parempi ratkaisu on, että muutat koodin rakennetta niin, että kaikki HTML-koodi ihan <!DOCTYPE html> -rivistä alkaen tulostetaan vasta myöhemmin, kun header-funktiota ei enää tarvita.
Kiitos, tutkin asiaa. Eli tuo pidemmän päälle ratkaisu.. Valitettavasti en ihan tajunnut. Minulla nyt index.php sivu jossa yhdistän header.php sivun ja luettelen php sisältö sivut.
Lisäys: Välillä minulla on useita header funktioita koodin joukossa jotka ohjaavat erilaisille virhesivuille.
Tämä lienee mahdoton omalla kohdallani koska käytän komentotulkkia-> "svn" ja "Apache" kehitysympäristöä.
<?php ob_start() ?>
Some web servers (e.g. Apache) change the working directory of a script when calling the callback function. You can change it back by e.g. chdir(dirname($_SERVER['SCRIPT_FILENAME'])) in the callback function.
- Eli käsitän että koska käytän SVN varmuuskopiointi menetelmään jatkuvasti koodatessa, niin tuo funktio saattaisi sekoittaa hakemistoja jotenkin. Muutenkin olisi kiva tietää että jos koodin joukossa on useita HEADER LOCATION merkintöjä niin onko se ylipäätään hyvä tapa. Pitäisikö minun enemmän yrittää tehdä JavaScript validatiota:
eli lomakkeella, tee näin, tee noin, muista se, muista tuo jne. JA Ennen kaikkea "pakottaa" käyttäjä käyttämään JavaScriptiä. Minusta sellaiset web-sivut olisivat mukavat että kaikkien pitää käyttää JS koska silloin käyttömukavuus hyvä-> mm. virheilmoitukset.
Mainitsemasi kohta ob_start-funktino dokumentaatiosta ei vaikuta sinuun millään tavalla, ja varsinkaan se ei missään tilanteessa sekoita mitään fyysisiä tiedostoja vaan enintään vaihtaa työhakemistoa, siis aivan kuin vaikka itse tuplaklikkaisit kansiokuvaketta Windowissa.
Älä koskaan tee tarkistuksia pelkästään JavaScriptilla, koska hakkeri voi silloin ohittaa ne. Voit tehdä tarkistukset sekä JS:llä että PHP:llä, jolloin käyttömukavuus on JS-käyttäjille hyvä mutta myös muilla kaikki toimii oikein.
latenleffahylly kirjoitti:
Minulla nyt index.php sivu jossa yhdistän header.php sivun ja luettelen php sisältö sivut.
Se on huono ratkaisu monestakin syystä (ellei käytetä paljon hienompaa tekniikkaa kuin sinulla nyt). Usein on fiksumpaa käyttää erillisiä sivuja, joiden osoitteet ovat järkeviä (esim. ei index.php?sivu=abc vaan suoraan abc.php). Sivut voi silloin koota vaikka näin:
<?php // Includella haetaan kaikki funktiot, tietokantayhteys ym. require_once "funktiot.php"; // Haetaan sivun tiedot tietokannasta, kuten äsken puhuttiin. // Tähän väliin kuuluvat myös tarkistukset, header-jutut jne. $tieto = KYSELYITÄ_TIETOKANNASTA; // Kun tiedot on haettu, tulostetaan sivun alku, sisältö ja loppu. sivun_alku($otsikko); echo "<p>Sivun sisältö</p>"; sivun_loppu();
Tässä ei tule mitään ongelmia header-funktion kanssa, koska sitä kutsutaan pelkästään ennen HTML-koodin tulostamista.
Nuo tulostusfunktiot voisivat olla idealtaan tällaiset:
<?php
function sivun_alku($otsikko) {
echo "<!DOCTYPE html>";
$otsikko = htmlspecialchars($otsikko);
echo "<html><head><title>{$otsikko}</title></head>";
echo "<body>";
}
function sivun_loppu() {
echo "</body></html>";
}Huh huh.. olen opetellut hyvin erilaisen tavan koska minulle vakuuteltiin että se on hyvä tapa. Onko lainkaan mahdollista että Ohjelmointiputka tekisi mainitsemasi mallin mukaisen "Näin koodaat järkevän web-sivu rakenteen" -oppaan?
Mielestäni kaikki mainitsemasi pitäisi kuulua ohjelmoinnin perusteisiin. Toisaalta jos tuo kaikki on korkeammantason koodausta niin silloin on itse tajuttava.
Tarkoitan sitä, että opettelen PDO:n käyttöä näistä syistä:
- Ohjelmointiputka suosittelee
- PHP kirjassa törmäsin PDO:hon
- Haluan oppia nykyaikaisimman tavan
Nyt jos täällä opetettaisiin moderni ja hieno tapa rakentaa PHP-sivu, niin se olisi hyvä. Tavallaan ADVANCED opas. Tarkoitan myös sitä että minua turhauttaa kaikista eniten se että haluan luottaa 100% neuvoosi. Minusta tuo tapa on hyvä ja varmasti toimiva. Mutta kohta joku kertoo ei noin jne.
Jos Ohjelmointiputkan oppaassa olisi tuollainen jakso sen voisi ottaa käyttöön luotettvasti, kuten PDO. Miksi ikänä tuhlasin koulussa aikaa opetellakseni MySQL-tavan, työssä MySQLi-tavan ja vasta nyt PDO-tavan.
MIELIPITEITÄ:
Webmaailman tulisi olla yhtenäinen. Meillä pitäisi olla yhteiset standardit jota kaikki haluaisivat noudattaa. Meillä olisi näihin "perus" asioihin valmiit mallit, mutta kaiken sen jälkeen pitäisi itse syventyä oppimaan.
Jos opettelen mainitsemasi tavan niin olisi vielä hienompaa jos se olisi standardi tapa PHP:ssä. Siis kunnon perustelujen kanssa. Tuntuu että taas opettelen jotain välitapaa matkalla oikeaan tapaan tehdä asioita. No.. kommenttini varmaan kertoo että olen noviisi. Mutta näin ajattelen reilu 3 vuotta vanhana koodarina, joka osaa HTML,CSS.. ymmärtää PHP,MySQL.. soveltaa omiin projekteihin JavaScript,(jQuery),(Ajax),(Photoshop CS 6).. huoh..
latenleffahylly kirjoitti:
Huh huh.. olen opetellut hyvin erilaisen tavan koska minulle vakuuteltiin että se on hyvä tapa.
Missä niin on vakuutettu?
lainaus:
Onko lainkaan mahdollista että Ohjelmointiputka tekisi mainitsemasi mallin mukaisen "Näin koodaat järkevän web-sivu rakenteen" -oppaan?
PHP-oppaassa käytetään hieman vastaavaa tapaa, mutta oppaan kirjoittajan mieltymysten takia siinä käytetään rumasti include-komentoa eikä funktioita. (Alla lisää tämän ongelmista.)
latenleffahylly kirjoitti:
Jos opettelen mainitsemasi tavan niin olisi vielä hienompaa jos se olisi standardi tapa PHP:ssä. Siis kunnon perustelujen kanssa.
Ei ole mitään yhtä oikeaa tapaa tehdä asioita. Eri tavoissa on erilaisia hyviä puolia ja erilaisia ongelmia, tosin aivan huonoimpien tapojen jälkeen "hyvät puolet" ovat uusia ominaisuuksia ja "huonot puolet" ovat koodin mutkikkuus verrattuna edelliseen portaaseen ja puuttuvat ominaisuudet verrattuna vielä hienompaan tapaan.
Esimerkiksi tuon aiemman tapasi eräs ongelma on, että header-funktiota ei pysty helposti käyttämään. Lisäksi koodi on turhan mutkikas ja siinä on usein vakavia tietoturva-aukkoja. En keksi tästä tavasta oikeastaan yhtään hyvää puolta.
PHP-oppaan include-tavan eräs ongelma on, että yla.php voi vahingossa muokata kaikkia sivun muuttujia, jolloin voi tulla ongelmia, joita on vaikea löytää. Toisaalta tämä tapa on erittäin yksinkertainen toteuttaa, kuten PHP-oppaasta nähdään.
Ehdottamiini funktioihin ei liity näitä ongelmia, ja ne on myös helppo toteuttaa. Itse asiassa nyt ollaan minun mielestäni siinä vaiheessa, jossa ainoa "ongelma" on, että joskus tarvitaan paljon enemmän ominaisuuksia.
Toki funktiolle voi lisätä paljon parametreja, mutta se on vaikeaa. Toinen ratkaisu on käyttää globaaleja muuttujia tai muuta mystistä, mutta se on taas askel taaskepäin: tulee samoja ongelmia kuin äsken include-komennon kanssa. Helpoin ratkaisu onkin vaihtaa funktiot luokkaan ja viestiä jäsenmuuttujien avulla (tai luomalla uusia alaluokkia):
$sivupohja = new Sivupohja();
$sivupohja->jokin_asetus = "jokin arvo";
$sivupohja->aloita("Otsikko"); // sivun_alku("Otsikko");
echo "Sisältö";
$sivupohja->lopeta(); // sivun_loppu();Tässä tavassa on taas entistä vähemmän puutteita. Toisaalta koodikin on jälleen vähän pidempi. On olemassa vielä monia hienompia tapoja, joissa kussakin on entistä enemmän ominaisuuksia mutta myös omat kiemuransa.
Suunnittelussa pitää tehdä valintoja sen mukaan, mitä ominaisuuksia tarvitaan. Jos tarkoitus on tehdä vain yksi ainoa sivu, on ihan turha hienostella, vaan voi kirjoittaa sivun yhteen tiedostoon ihan mielensä mukaan. Toisaalta esimerkiksi monikielisyys dynaamisesssa sovelluksessa on ominaisuus, joka vaatii aivan erilaisen lähestymistavan; silloin nämä yksinkertaiset yläosa-alaosa-viritelmät voi saman tien heittää roskakoriin.
Metabolix kirjoitti:
Toisaalta esimerkiksi monikielisyys dynaamisesssa sovelluksessa on ominaisuus, joka vaatii aivan erilaisen lähestymistavan; silloin nämä yksinkertaiset yläosa-alaosa-viritelmät voi saman tien heittää roskakoriin.
Käsitykseni mukaan ammattilainen välttää kirjoittamasta eri koodi kieliä samaan. Mutta yhdistää kuitenkin koodia Includen avulla.. vai kutsutaanko sittenkin jotain funktiota. Entä luokat (olio-ohjelmointi).
Nämä eivät olleet kysymyksiä, olen noviisi, mutta aion opetella PHP:tä paljon korkeammalle tasolle. Kiitos ideoistasi Mb. Kysyn vielä nopeasti yhden jutun, onko standardi tapaa dokumentoida php-tiedoston alussa? Nyt minulla esim:
/** DOKUMENTAATIO:
*
* YLEISTÄ:
* Työntekijä varaa työvuoron, Tapahtumat-sivulla valitsemaansa tapahtumaan.
*
* TIEDOSTOT:
* tapahtumat.php---> varaa.php---> varaa_chk---> varaa_ok.php---> (tapahtumat.php)
*
* TÄRKEÄÄ:
* Käydään läpi työvuoronvarauslomakkeelta lähetetty tieto. Huomioitavia asioita ovat
* mm. työntekijän ryhmä ja työntekijänumero joka syötetään lomakkeella. Työvuoroa
* varatessa käytetään apuna lisäksi tapahtuman id-numeroa sekä istuntomuuttujiin
* tallennettua tietoa.
*
* RYHMÄT:
* ...
*
* SISÄLTÖ:
* A.) Työntekijän tunnistaminen
* B.) Verrataan tarve <---> varaus
* C.) Tarkistetaan onko työntekijä jo varannut työvuoron
* ...
*
* MUUTA:latenleffahylly kirjoitti:
Käsitykseni mukaan ammattilainen välttää kirjoittamasta eri koodi kieliä samaan.
Olet aivan oikeassa, ja juuri siksi "monikielisyys" tarkoittaakin luonnollisia kieliä kuten suomi, ruotsi ja englanti. Jos jostain syystä puhuttaisiin monesta eri ohjelmointikielestä, tämä varmasti myös sanottaisiin selvästi.
latenleffahylly kirjoitti:
onko standardi tapaa dokumentoida php-tiedoston alussa?
Yleisesti käytettyjä apuvälineitä ovat phpDocumentor ja Doxygen, jotka vaativat omat vakiintuneet merkintätapansa.
Okei.. hyvä. Tutkin tuon Doxygenin. Tällä hetkellä käyn kaikki tiedostot läpi jaa muutan PDO-muotoon. Sitten tutkin connect.php tiedoston ja laitan sinne vain 1 tavan yhdistää tietokantaan, en 3 eri tapaa.
Lisäys:
NOTICE:
Onko opasta missä kerrotaan miten indeksi määritetään, eli miten pääsen eroon Notice ilmoituksista?
Notice: Undefined variable: id in /tapahtumapalvelu/tapahtumat.php on line 56
latenleffahylly kirjoitti:
Tällä hetkellä käyn kaikki tiedostot läpi jaa muutan PDO-muotoon.
Jep. Tuossa oli aikasemmin puhetta siitä, että ne koodit/koodirivit tulevat jossain vaiheessa selkäytimestä. Lisäisin(ellei filtterini sitä ohittanut) tähän, että selkäytimeen nämä tulevat ainostaan toistojen avulla.
Edit.
Jaa, näytti tuolla olevan kohta, jossa Alchemist sivusi asiaa.
The Alchemist kirjoitti:
Tuollaisia yksinkertaisia harjoitteita toistat tasan niin kauan, et yhtään vähempää, kunnes ymmärrät täydellisesti, mitä missäkin kohtaa tapahtuu ja kunnes osaat PDO:n rajapinnan riittävän hyvin.
latenleffahylly kirjoitti:
Lisäys:
NOTICE:
Onko opasta missä kerrotaan miten indeksi määritetään, eli miten pääsen eroon Notice ilmoituksista?
Notice: Undefined variable: id in /tapahtumapalvelu/tapahtumat.php on line 56
On yksi tapa päästä tuosta eroon; määrittelet muuttujan id.
Edit. Ja jos tarkoitat, että miten saisit virheilmoitukset pois näkyvistä, niin ottamalla sen koodin alusta pois, joka näyttää ne virheilmoitukset.
https://www.ohjelmointiputka.net/oppaat/opas.
latenleffahylly kirjoitti:
Onko opasta missä kerrotaan miten indeksi määritetään, eli miten pääsen eroon Notice ilmoituksista?
Ei ainakaan kannata piilottaa virheilmoituksia vielä kehitysvaiheessa.
$id = isset($id) ? $id : "oletusarvo"; //Lisätään oletusarvo jos ei ole vielä asetettu
latenleffahylly kirjoitti:
Onko opasta missä kerrotaan miten indeksi määritetään, eli miten pääsen eroon Notice ilmoituksista?
Notice: Undefined variable: id in /tapahtumapalvelu/tapahtumat.php on line 56
Ei ole. Asia on hyvin yksinkertainen: et saa yrittää lukea muuttujaa tai taulukon indeksiä, johon et ole ensin kirjoittanut jotain. Tämä olisi selvinnyt yksinkertaisesti googlettamalla tuolla virheilmoituksella.
<?php $data = array( 'a' => 1, 'b' => 2, ); // Väärin, koska indeksiä 'c' ei ole olemassa. $c = $data['c']; // Väärin, koska muuttujaa $foo ei ole vielä esitelty. print $foo; // Oikein: $data['c'] = 'testi'; $c = $data['c']; $foo = 'bar'; print $foo;
Noin yksinkertaista. Tässä vielä hieman hämärämpiä esimerkkejä:
<?php $data = array( 'a' => array(), ); // Väärin, koska indeksiä 'b' ei ole alustettu. $data['b'][] = 'foo'; // Väärin, koska muuttujaa $foo ei ole vielä olemassa. $foo[] = 'bar'; // Oikein: $data['b'] = array(); $data['b'][] = 'foo'; $foo = array(); $foo[] = 'bar'; // Ei heitä noticea vaikkei $data-muuttujaa ole olemassa ensimmäisellä // kierroksella, koska kirjoitettava indeksi on määrätty. // Ei ole silti hyvä tapa olla alustamatta muuttujaa silmukan edessä, // koska koodista ei välttämättä käy ilmi, onko $data-muuttuja määritetty // jo aiemmin vai ei. Lisäksi taulukkoon voi jäädä vanhaa roskaa, jos se // olikin jo olemassa... for ($i = 0; $i < 10; $i++) { $foobar[$i] = 'a'; } print_r($foobar); // Tämäkään ei heitä noticea, vaikkei $doo-muuttujaa saati sen alitaulukoita // ole olemassa vielä. $doo['a']['b']['c'] = 'd';
Edellä mainitut asiat pätevät myös funktioiden kanssa:
<?php // Heittää noticea, jos $_GET-taulukossa ei olekaan indeksiä 'array'. if (is_array($_GET['array'])) { ... } // Isset() ja empty() ovat erikoistapauksia, koska ne eivät ole oikeasti // funktioita vaan sekavia häröpalloja. // Näistä ehtolauseista ei synny noticea, koska PHP ei käsittele ollenkaan // &&-operaattorin oikeaa puolta, mikäli vasen puoli palauttaa FALSE. if (isset($_GET['array']) && is_array($_GET['array'])) { ... } if (!empty($_GET['array']) && is_array($_GET['array'])) { ... } // Tämäkään ei aiheuta noticea vaikkei $foo-muuttujaa edes olisi olemassa: if (isset($foo['a']['b']['c'])) { ... } // Tästäkään ei tule virhettä, vaikka koodi on aivan järjetön: $lol = null; var_dump(isset($lol->boo)); // Tästä tulee noticea: var_dump($lol->boo); // Oikein: $lol = new stdClass(); $lol->boo = 'sadasd'; var_dump($lol->boo);
Poikkeuksia edelliseen ovat ne funktioiden parametrit, jotka välitetään funktiolle VIITTAUKSINA...
<?php // Ei aiheuta noticea, koska kolmas parametri välitetään viittauksena. // (Katso funktion dokumentaatio.) preg_match('/a/', 'aakkonen', $match); print_r($match);
Lisään vielä tuohon Qeijon isset-esimerkkiin sen, että tuollaista ei sitten saa alkaa kirjoittaa esim. GET- tai POST-muuttujista lukiessa. Koodista tulee vain rumaa roskaa. Koodaa ennemmin oma funktiosi:
<?php // VÄÄRIN: $a = isset($_GET['a']) ? $_GET['a'] : null; $b = isset($_GET['b']) ? $_GET['b'] : null; $c = isset($_POST['c']) ? $_POST['c'] : array(); // Oikein: function array_get($array, $key, $default = null) { return array_key_exists($key, $array) ? $array[$key] : $default; } $a = array_get($_GET, 'a'); $b = array_get($_GET, 'b'); $data = array_get($_POST, 'data', array());
Koodi on muutenkin laadultaan erittäin heikkoa, mikäli joudut usein tarkistelemaan muuttujien olemassaoloa isset():llä. Yksittäistapauksissa se käynee laiskan miehen ratkaisuna, mutta pääsääntöisesti koodista vain tulee yhtä sotkua redundanttien if-lausekkeiden takia.
Valtavasti tietoa, kiitos siitä. Käsitykseni mukaan Notice on ihan minimi tason virhe, mutta silti "pieni" tietoturva riski. Tavallaan jos antaa Noticejen olla niin välttyisi siltä että rikkoo koodiin. VArsinkin kun muuttujia useita erilaisia.
Toisaalta toivon aikanani pystyväni pääsemään huomautuksista eroon. Puhtaan ja standardin mukaisen koodin kirjoittaminen on nytkin tavoitteeni. Siksi opettelen PHP:tä ja esim. käyn läpi css-tiedostoja vai lisätäkseni välin sinne tai tänne. Tai kirjoittaamaan parametreja aakkosjärjestyksessä. Html5 uudat elementit ovat myös kiinnostavia.
alkemisti, geijo ja dartvaneri kiitos avusta. Virheilmotuksien osalta homma hanskassa. Nyt ne ovat tilassa: "on", välillä otan pois: "off" ...tällä hetkellä (vain) Notice huomautuksia.
Ei koodi voi silloin toimia oikein, jos tulee virheilmoituksia.
Missä tilanteessa koitat käyttää muuttujaa $id, jos et ole edes alustanut sitä? Tai pahemmassa tapauksessa, edes esitellyt sitä?
<?php echo $id; // miksei tää toimi!??!?! ?>
Ethän voi syödä omenaakaan ennen kuin olet sellaisen jostain saanut...
Ei se mikään tietoturvariski ole mutta merkki huonosta koodista ja huonosta koodarista.
No voi se tietoturvariskikin olla jos käyttää vanhempaa kuin 4.2.0 PHP:tä oletusasetuksilla tai vanhempaa kuin 5.4.0 niin että register_globals on päällä.
Macron omenaesimerkin mukainen tyypillinen tilanne on tämä:
if (haluat_omenan()) { $omena = osta_omena(); } syö($omena); // Virhe! Omenaa ei ole, jos sitä ei äsken ostettu.
Oikea ratkaisu on siis miettiä jokaisen if-lauseen kohdalla myös, mitä tapahtuu, jos lause ei toteudu, ja tarvitaanko ehkä else-lohko.
The Alchemist, esimerkkisi ovat ohjeina hyviä ja oletuksiltaan järkeviä, mutta tarkkaan ottaen PHP:ssä on laillista sijoittaa arvoja myös olemattomaan taulukkoon, eli jopa seuraava koodi toimii:
unset($data); $data['b'][] = "teksti";
PHP:llä on taas jokin ihan oma logiikkansa: $data saa olla array, null, false tai "", mutta silti 0, "x" ja true eivät kelpaa.
En tietenkään suosittele alustamattoman taulukon käyttöä, ja register_globals aiheuttaa myös siinä tietoturvariskin, vaikka mitään varoitusta ei näy.
Minä nähtävästi ajattelen asioista eri skopella. Ei ole mikään tietoturvariski yrittää lukea taulukoita tai muuttujia, jotka eivät ole olemassa. Ne keissit ovat kuitenkin osajoukko suurempaa ongelmaa, päätöntä muuttujien hallintaa, josta taas voi seurata ihan mitä tahansa.
Listasin tuohon nyt vaan asioita, jotka tulivat sillä hetkellä mieleen. Ja se on kokonaisuudessaan oikeastaan hyvä esimerkki siitä, mitä tarkoitin asioiden ymmärtämisellä aikaisemmin. Minun ei tarvinnu lukea mitään manuskaa tai kysyä apua foorumilla tai edes googlettaa asioista. Tiesin nuo jo vanhastaan, koska en ole pelkästään häseltänyt vaan opetellut ja oppinut käyttämään php:tä. Suurinta osaa en edes tarkistanut.
Noh, näköjään yksi ensimmäisistä keisseistä olikin heti väärin.
The Alchemist kirjoitti:
Ei ole mikään tietoturvariski yrittää lukea taulukoita tai muuttujia, jotka eivät ole olemassa.
Tietoturvariski tuleekin siitä, kun luetaan muuttujaa olettaen, että sitä ei ole olemassa. Eli "hyödynnetään" PHP:n ominaisuutta, että määrittelemätön muuttuja on tyhjä ja noticet voi kytkeä pois päältä.
Eli kunnollisten alustusten ja tarkistusten puuttuessa ja ympäristön ominaisuuksia hyödyntäen pystytään syöttämään koodiin sellaisia tarkistamattomia lähtöarvoja, joita kehittäjä ei ole tullut ajatelleeksi, ja näin saadaan ohjelma suorittamaan toimintoja, joita kehittäjä ei ole tarkoittanut olevan mahdollista suorittaa. Mielestäni tuo istuu aika hyvin tietoturva-aukon määritelmään.
Tietenkään jokainen alustamaton / tarkistamaton muuttuja ei automaattisesti ole tietoturva-aukko, mutta on huomattavasti työläämpää varmistaa että siitä ei tule aukko, kuin vaan alustaa tai tarkistaa se. Eli sikäli alustamattomuus on turha (tietoturva)riski sen lisäksi että se on mahdollisesti turha muidenkin ongelmien lähde.
Itsehän koodailen pääsääntöisesti kielellä, jossa ohjelma ei edes käänny jos yritetään lukea alustamatonta muuttujaa, ja pidän sitä ihan positiivisena asiana.
En ole mikään muinaisten kielten asiantuntija, mutta minulle ei tule mieleen toista likimain yhtä yleistä kieltä, jossa säännöt muuttujien suhteen olisivat yhtä tyhmät kuin php:ssä.
Välillä se puree niin kovaa...
The Alchemist kirjoitti:
En ole mikään muinaisten kielten asiantuntija, mutta minulle ei tule mieleen toista likimain yhtä yleistä kieltä, jossa säännöt muuttujien suhteen olisivat yhtä tyhmät kuin php:ssä.
Esimerkiksi Perl on aika lähellä, ja sehän oli aiemmin hyvin yleinen nettiohjelmoinnissa.
Perl onkin se kieli, jota tuntemaan opittuani lopetin haukkumasta php:n kehittäjiä tyhmiksi.
Alkemistille terveisiä että Noticet eivät tule omasta kirjoittamasta koodistani vaan jQuery kirjautumispaneelista, jonka halusin liittää ohjelmaani.
Mutta toisaalta se ei ole mikään selitys ja siksi pyysin apua siihen. En muutenkaan jaksaisi enää kuulla miksi haukut minua koko ajan. Yritän oppia uutta ja tiedän että yritän minulle liian vaikeita asioita. Asenteesi on kuitenkin negatiivinen kaiken suhteen mitä kirjoitan.
Negatiivinen alkemisti kirjoitti:
Ei se mikään tietoturvariski ole mutta merkki huonosta koodista ja huonosta koodarista.
latenleffahylly kirjoitti:
En muutenkaan jaksaisi enää kuulla miksi haukut minua koko ajan. Yritän oppia uutta ja tiedän että yritän minulle liian vaikeita asioita. Asenteesi on kuitenkin negatiivinen kaiken suhteen mitä kirjoitan.
Negatiivinen alkemisti kirjoitti:
Ei se mikään tietoturvariski ole mutta merkki huonosta koodista ja huonosta koodarista.
Luulen että The Alchemist tarkoitti tuossa yleisellä tasolla ei niinkään juuri sinua.
Voi olla mutta hän minua haukkuu, vaikka yritän paremmaksi koodariksi oikeastaan developeriksi, päivittäin. Sanotaan nyt esim. tuo PDO..
pelkkien Ohjelmointiputkan oppaiden avulla olen saanut paljon aikaan. En vain copy pastaa vaan osaan ulkoa rivejä, useita rivejä - ja ennen kaikkea ymmärrän mitä kussakin kohtaa tapahtuu. Esim. käytän välillä bindParam -menetelmää mutta jos ongelmia siirryn käyttämään arrayta, riippuen tilanteesta. Tämän oivalsin kun luin teoriaa (iPad, php-kirja). Eli ihan vajaassa viikossa olen tässä asiassa päässyt eteenpäin.
Siinä negatiivinen alkemisti on oikeassa, että minun pitää mennä tasolle-> noviisi ja opetella ihan perusteet ja vähitelleen tehdä vaikeampia tapoja. Toisaalta toinen tapa on tehdä itselle niin vaikeita projekteja että on pakko oppia uusia menetelmiä ja opetella HC koodausta.. no juu..
Itse opin vain toistojen kautta ja sillä että tekemäni projekti on kiinnostava eli olen sen kanssa tekemisissä joka päivä. Kiitos kuitenkin kaikesta avusta, sitä on ollut todella paljon. Nyt aina ennen kuin kysyn - yritän ratkaista tehtävän itse eli kysyn ihan vasta lopussa tai pikemminkin periaatteita miten jotain asiaa kannattaisi lähteä ratkaisemaan. kiitän..
latenleffahylly kirjoitti:
En vain copy pastaa vaan osaan ulkoa rivejä, useita rivejä - ja ennen kaikkea ymmärrän mitä kussakin kohtaa tapahtuu.
No tuo nyt ei ole mikään meriitti että osaa rivejä ulkoa, mutta toisaalta se on jos ymmärtää mitä kussakin kohtaa tapahtuu. Se että muistaa rivejä ulkoa viittaisi juuri copy&pastaamiseen.
Eihän kirjailijakaan kehu että hän osaa useita rivejä ulkoa omasta tai toisen kirjasta ja pidä sitä jonain kirjailijan laadun mittarina.
"Arthur perääntyi hermostuneena. Hän nyki partaansa ja kauhistui"
Kyllä musta nyt tulee uusi Douglas Adams kun muistan tuon ulkoa...
Sori nyt että tartuin tällaiseen. Hämää vaan niin vietävästi kun puhutaan koodaamisesta ja ulkoa opettelusta samassa kappaleessa. Ehkä et tarkoittanut että "osaat ulkoa" vaan että "osaat ilman muualta katsomista itse" kirjoittaa useita rivejä koodia.
Mielestäni metabolixin esimerkki lausekkeesta "1+(2*3*4*5)/15-123/3+9" oli erittäin osuva. Olisi hirveän raskasta opetella ulkoa että tuo tarkoittaa -23 ja jokainen muu mahdollinen lasku erikseen ulkoa, kun järkevämpää olisi opetella ne laskusäännöt ja logiikka niiden takana.
Minä olen kylmä ja kyyninen mutten mielestäni kovin usein täällä ketään suoranaisesti hauku. Copy-paste-koodariksi kutsuminen ei vielä pilkkaamisen kriteereitä täytä.
latenleffahylly kirjoitti:
pelkkien Ohjelmointiputkan oppaiden avulla olen saanut paljon aikaan. En vain copy pastaa vaan osaan ulkoa rivejä, useita rivejä - ja ennen kaikkea ymmärrän mitä kussakin kohtaa tapahtuu. Esim. käytän välillä bindParam -menetelmää mutta jos ongelmia siirryn käyttämään arrayta, riippuen tilanteesta. Tämän oivalsin kun luin teoriaa (iPad, php-kirja). Eli ihan vajaassa viikossa olen tässä asiassa päässyt eteenpäin.
Tämä on juuri se ongelma, mikä sinun pitäisi taklata. Et keskity opettelemaan mitään kunnolla vaan häsellät omiasi koko ajan. PDO:n oppimiseen ei mene viikkoja vaan muutama tunti, kun siihen keskittyy sen muutaman tunnin ajan.
Jos häsellät kaikkea muuta siinä ohessa, niin et opi PDO:ta - kuten myönnät käyneen - etkä opi mitään muutakaan. Josset ymmärrä perusteita, niin minkään näihin perusteisiin nojaavan monimutkaisemman asian oppiminen on lähes mahdotonta.
Mitä tarkoitat näillä perusteilla? Tulee sellainen olo että lähestyn koodausta, php koodausta, jotenkin ihan väärällä tavalla.. Itse ajattelen että on esim. Web-sivut, jossa on lomake, siihen syötetään tietoa, tieto tallennetaan tietokantaan ja tulostetaan vaikkapa ylläpitäjän nähtäväksi.
Nämä kaikki vaiheet mielestäni muodostavat koodaamisen idean. Eli tehdä jotain, jokin prosessi.
Onko kyse siitä että minun pitää ajatella/ toimia näin?
1.) jaa prosessi pieniin osiin (tehtäviin)
2.) mieti järkevä tapa toteuttaa prosessi, työvaiheet
3.) huomioi ympäristö
4.) käyttäjät
5.) tietoturva
6.) suunnittele tietokanta, taulut jne.
Pitääkö tämä kaikki osata koodata päässä alusta loppuun..? Tavallaan voisin kokeilla, mutta luulen että jotain osia en .. Siis tietäisi miten koodata tai mitä atribuutteja mihinkin kohtaan tulee.
Kun rakennan tietokannan tauluja ja niiden yhteyksiä katson usein mallia varmuuden vuoksi. Html lomakkeen rungon otan usein mallina vaikka osaisinkin 90% siitä itse koodata.
Pdo tyylillä osaan hakea ja tallentaa lähes kaiken tiedon, mutta toisaalta olisiko parempi rakentaa jokin funktio jota vain kutsutaan.. Eli tarkoitan vain että haluan oppia koodaamaan. Laitoin esimerkki koodini, mutta kukaan ei ole sanonut että siinä olisi mitään hyvää tai että näin juuri kannattaa koodata?
Pyytäisin että kertoisitte mitä teen väärin. Noin 3 vuotta sitten en osannut koodata mitään, en yhtäkään tagia. Nyt osaan tehdä jotain: php, javascript, jquery, ajax, sql, mysql, html, css... Harmittaa se että miksen voisi oppia vuodessa aivan uudelle tasolle.. Minulla on jokin perusvika jota toistan ja siksi en opi..?
Pitäisikö koodata jokin ohjelma joka arpoo lottorivin ja kolme lisänumeroa esim? (Tämä ei ole vitsi)
Voi mamma och pappa tätä keskustelua. "Haluan sitä ja uskon tätä..",
ei kukaan voi opettaa porsaalle hevosten estehyppelyä.
Geijolle huomautus, käyn juuri läpi mitä on ohjelmointi aluetta ja sitten oppaisiin. Aloitan ihan perusteista ja käyn jakso kerrallaan. Olen tehnyt tämän ennenkin, mutta nyt muutan asennettani.
Jaa'a, enpähän itse tiedä, mitä tässä sanoisi.
Olet itse sanonut lukuisia kertoja, ettet osaa aloittaa koodaamaan täysin tyhjältä pöydältä. Ehkä sitten olisi järkevintä koodata jokin yksinkertainen pieni proggis, sellainen missä on esimerkiksi yksi lomake, jolla syötetään tietoja järjestelmään, ja yksi näkymä, joka tulostaa nämä tiedot. Vaikka vieraskirja tai yksinkertainen blogi tai vaikka joku muistilappusysteemi.
Tuollaisia teet pari erilaista, niin luulisi sillä pääsevän alkuun.
Tulipas taas deja vu -tunne, kun tämän sanoin...
Noniin.. uskoo ken haluaa. Eli toteutin alkemistin neuvon.
TEHTÄVÄ: Koodaa Blogi tyhjästä:
index.html->tarkista.php->blogi.php->(index.html)
tyylit.css
yhdista.php
Lomake:
- otsikko
- pvm
- teksti
Tietokanta:
CREATE TABLE blogi
(
id int NOT NULL AUTO_INCREMENT,
otsikko varchar(20),
pvm varchar(10),
teksti varchar(140),
PRIMARY KEY (id)
)
Blogi:
tulosta (utf-8)
-----------------------------------
Miinukset:
- Päivämäärä tallennettiin teksti muodossa eli heti suuri miinus. Mutta ei tässä vaiheessa oleellinen. (harjoitus 1)
- tyylitiedostoa yhdistäessä en ihan kaikkea muistanut (rel = relationship) jne.
- header location, eli se ei ihan tullut muistista
- tietokannan rakentaminen, siis ihan basic, katsoin nopeasti mallia
- sitten tulostaessa merkit oli päin seiniä vaikka htmlspecialchars, ja utf-8 tietokanta, joten lisäsin->
<?php header("Content-Type: text/html; charset=utf8"); ?>
-----------------------------------
Toki aika paljon pieniä perusasioita. PDO toimi hyvin. Toki kuten alkemisti ja te muut olette sanoneet. Tästä se tavallaan pitää aloittaa. Eli pilkoin tuon alkemistin ehdottaman tavan osiin ja niitä tulikin lukuisia. Noh.. pdo yhteys.php tiedosto ei tullut muistista. Aika nopeasti sain kuitenkin koodattu raakaversion html5 doctype tyyli, tietokanta toimivuus ja tulostus. Mutta mutta. Pienet virheet pois ja lisää haastetta lomakkeen tarkistus, tyylittely, tulostus, hienous.
Kello viereen, esim. aikaa 3 tuntia saa pitää lyhyitä taukoja ja saa etsiä tietoa jos jää pahasti jumiin.
Plussat:
+ localhost, Apache testiympäristö on turvallinen ja nopea
+ mysql, phpmyadmin
+ pdo
+ järkeviä muuttijien nimiä ja css-tyylien nimiä
+ tajusin koko ajan mitä teen seuraavaksi ja missäkin järjestyksessä
+ löysin tietoa nopeasti, (miinukset) google-> ohjelmointiputka ja w3schools auttoivat
Suurkiitokset idean kehittäjälle ja kovimmalle kriitikolleni, tästä on hyvä jatkaa. Kyllä tämä avasi homman aivan täysin kun joutuu tyhjälle tiedostolle kaiken koodaamaan. Ja joka kerta kun joutuu muualta katsoa niin tulee inhottava tunne lunttaamisesta. Tänks!!
Voitko heittää sen koodin jonnekkin näkösälle, niin voi antaa enemmälti rakentavaa palautetta, sikäli haluat oppia uutta.
Voin toki. Koodi tosin on hyvin perustasoa, joten iltanne menisivät varmaan pilalle. Kirjoitan tätä iPadista, joten nyt en pysty sitä tekemään. Noin tunnin koodasin, ihan perustasoa.
Tietty ehkä funktioiden harjoittelu voisi olla hyvä. Kuulemma käsinkirjoitetut sql lauseet eivät ole hyvä tapa. Lomakkeissa voisi käyttää label, dl, dt, dd tageja jne. Tarkistuksiin js, olen hakenut valmiita funktiokirjastoja jotka tekevät erilaisia tarkistuksia, mielestäni ihan kiva.
Toisaalta taas sellainen tunne että opettelen koodaamaan jotenkin väärin. Eli liian yksinkertaisesti. Pitäisi käyttää funktioita, luokkia ja olioita. Metabolix kertoi omasta tavasta muodostaa sivut, siinäpä jo valtava haaste. Ongelmani on että en pysy pienien asioiden ääressä. Alan suunnittelemaan suuria kokonaisuuksia ja miettimään tulevia ongelmia.
Haluaisin tai siis aion vielä joskus koodata järjestelmän jolla hallitaan työntekijöiden arkea työpaikalla. Siinä käytetään apuna, tapahtumapalvelun ideaa. Näytetään ajankohtaisia asioita ja näytetään henkilökohtaisia asioita. Ylläpitäjä voi halutessa muokata ja tarkastella kaikkea tietomäärää.
Hieno ominaisuus olisi että näkisi ketkä kaikki ovat sisään kirjautuneina. Tavallaan joko ylläpitäjälle vakoiluohjelma tai kaikille näkyvä.
Lyhyesti.. onko PDO:ssa nopeaa tapaa saada päivämäärä + kellonaika?
1.) käyttäjä syöttää nimensä lomakkeelle ja painaa lähetä
2.) tämä tieto tallentuu tietokantaan ja.. tästä hetkestä pitäisi saada aika
2012-09-03 14:30:46
Olen aikaisemmin käyttänyt funktiota NOW() mutta miten on PDO:n laita?
NOW() toimii myös pdo:ssa.
Lisäys:
<?php
//Aika = DATETIME
$kysely = $yhteys->prepare("INSERT INTO aika (aika) VALUES(NOW())");
//Tai
$kysely = $yhteys->prepare("INSERT INTO tapahtumat (tapahtuma, aika) VALUES(?, ?)");
$kysely->execute(array($tapahtuma, NOW()));
?>Ei se ole pdo:ta vaan Myskylän sql:ää. Pdo ei ole kieli.
PDO:ssa ei myöskään ole tukea päivämäärälle, joten päivämäärät ja ajat joutuu välittämään kannalle merkkijonoina tai lukuina (esim. unix time stampit)
Itse kun ORMeja käyttävänä olen tottunut hoitamaan asian tyyliin
taulu.Aika = DateTime.Now;
niin kyllähän tuon asian tekeminen PDO:llakin tuntuu aina vähän purkalta.
noniin.. hyvä. Selvitän tuon unix time stamp. Dartvaneri kiitos kuitenkin esimerkeistä, alla virheilmoitus:
"Fatal error: Call to undefined function NOW() in tapahtumapalvelu/uusi_tyontekija_chk.php on line 49"
Syy: NOW() on myslin funkkari, ei PHP:n.
Aikakentän tyyppi timestamp, oletusarvo current timestamp.
$kysely = $yhteys->prepare("INSERT INTO xxxx SET nimi = ?, aika = NOW()");
$kysely->execute(array($nimi));Toimii.
Hetkinen, hetkinen.. osa siis on sitä mieltä että PDO:n kanssa voi käyttää NOW() funktiota, niin ja että tietokannan taulussa tehdään asetuksia?
Mites nämä merkinnät?
Grez kirjoitti:
PDO:ssa ei myöskään ole tukea päivämäärälle, joten päivämäärät ja ajat joutuu välittämään kannalle merkkijonoina tai lukuina (esim. unix time stampit)
Itse kun ORMeja käyttävänä olen tottunut hoitamaan asian tyyliin
taulu.Aika = DateTime.Now;niin kyllähän tuon asian tekeminen PDO:llakin tuntuu aina vähän purkalta.
Pdo on ainoastaan rajapinta sql-tietokantaan yhdistämiseksi php:tä käyttäen. Se on ainoastaan "ajuri", jota ormit ja sensemmoiset voivat loppuviimein käyttää.
Olen itsekin sitä mieltä, ettei käsin pitäisi lähteä sql-kyselyitä kirjoittamaan kuin aivan ehdottoman pakon edessä. Olion tallentaminen tietokantaan ja tietokantarivin lukeminen olioksi ovat niin täydellisen "triviaaleja" tapauksia, että ne kuuluvat ehdottomasti jonkin automaattisen työkalun eikä koodarin harteille.
Omien kokemusteni mukaan tietokannan ja sovelluksen välisen tiedonvaihdon hoitaviin komponentteihin menee webbijärjestelmiä koodatessa tuhottomasti aikaa, jos lähtee omia virityksiään tekemään. Tämä sisältää sen olettaman, että koodin kirjoittamisen jälkeen tarvitsee tehdä muutoksia tietokantaan tai rajapinnan koodiin.
Seuraavaksi funktiot haltuun, kiitos upeasta oppaasta. Äskeiseen chaseen se että nuo aika jutut ovat vaikeita, joten.. En saa tietokantaan aikaa h:i:s.. Mutta Y-m-d onnistuu mktime funktiolla. Pdo:ssa on puolensa. Itse kannatan mutta miten tällaiset asiat ratkaistaan. Funktio voisi olla kiva.. Mutta toisaalta kuinka helppo olikaan vain kirjoittaa NOW()
Toimii toi NOW() edelleenkin.
Ja se pitänee, ainakin testien mukaan, olla tuossa sql kyselyssä, ei tuolla execute(array()) sisällä.
<?php
$query = $connect->prepare("INSERT INTO action (action, time) VALUES(?, NOW())");
$query->execute(array($action));
?>kuules vaneri, osa kertoo että voi osa että ei...??? Miten alla olevaan koodiin muka voi liittää NOW() funktion?
$kysely = $yhteys->prepare("INSERT INTO tyontekija (
email,
regip,
dt,
etunimi,
sukunimi
)
VALUES (
?,
?,
?, NOW(), // ???
?,
?)");
// suoritetaan
$kysely->execute(array($email,
$regip,
$dt,
$etunimi,
$sukunimi));Näin
<?php
$kysely = $yhteys->prepare("INSERT INTO tyontekija (email, regip, dt, etunimi, sukunimi) VALUES (?, ?, NOW(), ?, ?)");
$kysely->execute(Array($email, $regip, $etunimi, $sukunimi));Kiitos Teuro, erittäin reilua. Olin typerästi laittanut NOW() funktiolle oman muuttujan arrayn sisään. Nyt toimii hienosti:
Sarakkeen tyyppi: datetime
Tietosisältö: 2012-10-18 13:12:03
latenleffahylly kirjoitti:
kuules vaneri, osa kertoo että voi osa että ei...???
Ne jotka väittivät, ettei se toimi ovat kai joskus kokeilleet sitä väärin, ja todenneet sen toimimattomaksi, mutta minäpä satuinkin testaamaan sitä asiaa juuri ennen kirjoittamista, niin arvaappa vaan tiedänkö, että toimiiko se funktio.
Kuka muuten väitti, että ei voi? Ei ainakaan tässä keskustelussa tainnut kukaan väittää.
Kukaan ei ole väittänyt, ettei MySQL:n NOW-funktio toimisi. Kaikki vastaajat luultavasti tietävät, että MySQL:n perusfunktioiden toiminta ei riipu siitä, lähetetäänkö ne palvelimelle PDO-rajapinnalla, MySQLi-rajapinnalla vai mysql_query-funktiolla; nämä kaikki ajavat (tässä tapauksessa) MySQL-kyselyitä MySQL-tietokannassa, jolloin samat MySQL:n merkinnät toimivat.
Sen sijaan dartvaneri on antanut ainakin yhden aivan väärän esimerkin, jossa NOW-funktiota yritetään kutsua PHP-koodissa. Se ei tietenkään toimi, ja samalla tulee todistettua, että dartvaneri ei myöskään testannut neuvojaan.
Metabolix, jos satuit lukemaan tuon minun 17.10.2012 22:48:11 lähettämän viestin saattaisit jopa ymmärtää, että korjasin virheeni.
Lisäksin en todellakaan katsonut sen tarkemmin, että ketkä väitti, ettei ko. funktio toimi, kun kerran latenleffahylly sanoi, että joku väitti niin, aattelin vaan kertoa, että mikä siihen voisi olla syy. Myönnän että sana valinta ei nyt ihan nappiin mennyt.
Edit.
Enhän muuten olisi korjannut virhettäni, ellen olisi testannut.
Koodaan aivan liian paljon per päivä 6-10 tuntia, useimmiten yli. Se ei taida olla kovin järkevää. Luultavasti itse sekoitin asioita, pahoittelut!
Osaako joku neuvoa hieman järkevämpää tapaa saada tietokannasta tietoa arrayhin ja siitä omaan funktioon?
function valintalista($name, $value, $ryhmat){} {
echo "<select name=" . $name . ">";
foreach ($value as $key) {
echo "<option value=" . $key . ">" . $ryhmat . "</option>";
}
echo "</select>";
}
// tässä tapauksessa arrayn tiedot tulisivat tietokannasta
$ryhmat = array("jv", "tr", "em");
valintalista("R_Id", range(3, 6), $ryhmat);- Huom! Yritän nyt opetella seuraavat 3 päivää Array, Print_r, Foreach ja nimenomaan niin että sql-lause voitaisiin suorittaa funktion sisällä. Siihen parametrit tulisivat tietokannasta ja jne. Mitään kovin järkeviä ohjeita en löydä, ovatko hakusanat sitten outoja tai jotain.
Anteeksi mutta eihän tuossa ole mitään järkeä.
Sä voit tuoda tuon "range" ja $ryhmat samassa arrayssa, niin virheiden määrä vähenee heti.
Eli tällöin sulla on yksi taulukko, jossa sulla on valintojen "valuet" ja sitten optionissa näytettävät tekstit samassa arrayssa (esim. ihan normaali hash-array).
Taulukko voisi olla tämmöisessä muodossa:
( $taulukko[ key ] = value )
$taulukko["banaani"] = "Foobar"; $taulukko["omena"] = "Lorem"; $taulukko["kiwi"] = "Ipsum dolor"; ...
Vastaavasti tuo taulukon "key" voisi olla vaikkapa tietokannasta tuleva yksilöivä id-numero ja arvo tietokannasta tullut tekstinpätkä/otsikko.
edit:
Itse vierastan suuresti juuri kahta taulukkoa samassa loopissa, koska tällöin on hyvin suuri mahdollisuus, että inhimillisestä erheestä johtuen taulukossa on esim. vahingossa soluja eri määrä.
esim.
$nimet = array("Aapo","Anssi","Antti","Ari","Aarne","Brutus","Bole","Pekka");
$id = array(2321,135,875,32,1000,15,656);Kun taas ajatellaan, että taulukko olisi muotoa
$henkilot[] = [
"id" => 2323,
"nimi" => "Aapo"
];
$henkilot[] = [
"id" => 6,
"nimi" => "Keijo"
];
$henkilot[] = [
"id" => 2,
"nimi" => "Antti"
];
$henkilot[] = [
"id" => 43,
"nimi" => "Jorma"
];Ymmärrän että minun pitää tämä asia ymmärtää mutta..
jos esim näin tietokannassa:
R_Id
1
2
rLyhenne
jv
tr
( $taulukko[ key ] = value ) -> function valintalista($taulukko[$R_Id] = $rLyhenne) {
}..ei kyllä tässäkään ole järkeä kun en syntaksia osaa kirjoittaa. Mutta, mutta.. kun minulle enemmän energiaa tutkin tuon sinun lähettämän postauksen. Kiitos kun jaksoit auttaa[:)]
Mikset sä voi vaikka tehdä sitä taulukkoa siellä php-koodissa?
Sekotan varmaankin taas asioita, nyt näin..
<td>
<label class='styledLabel' for="jvTarve">Järjestyksenvalvoja:</label>
<?php
echo "<div class='styledSelect3'><select name='jvTarve'>";
valinta();
echo "</select></div>";
?>
</td>
// funktiokirjasto.php
function valinta() {
for ($valinta = 0; $valinta <= 50; $valinta++) {
echo "<option value=" . $valinta . ">" . $valinta . "</option>";
}
}Ei mitään tuollaista kurapaskaa kuin mitä viimeisessä viestissä on esitelty. Juuri tuollainen koodi on saanut omat stressitasoni nousemaan sataseen, kun olen muiden tekemää kelvotonta koodia joutunut korjailemaan. Jos html:ää aletaan tulostella funktioilla tai sitä aletaan muilla tavoin siirtää pois view-osasta, niin sitten tulostetaan kokonaisia osia kuten kokonaisia html-elementtejä (<select> ja sen sisältö).
Kun jo kerran aiemmin kysyit "opasta" asioiden tekemiseksi oikein, niin minä tein sinulle yksinkertaisen esimerkin siitä, miten olen itse alkanut tehdä koodia viime aikoina. Esimerkkini on kyllä suhteettoman huono oppaaksi, koska se on raaka yksinkertaistus asioista ja sisältää muutenkin tarkoituksellisia / liiasta yksinkertaistuksesta johtuvia virheitä.
http://sj87.hopto.org/lefa.tar.gz
Kyse on yksinkertaisesta kirjojen hallintaan tarkoitetusta työkalusta, jolla voi nyt lukea kannasta kirjailijoiden ja kirjojen tietoja ja lisäksi syöttää kantaan uusia kirjoja ja poistaa niitä.
Tutustun juuri tuohon lähettämääsi materiaaliin. Haluaisin nimen omaan heti oppia järkevän tavan tehdä esim SELECT elementti.
..................Kuules nyt alkemisti, jotain rajaa. Olet aivan eri tasolla tämän PHP kielen hallinnan suhteen? En voi mitenkään päästä tasollesi edes näiden esimerkkejen avulla. Minun on yksinkertaisesti mentävä askel kerralla.
Stadikan torniin verrattaessa, minä olen juuri astunut ensimmäiset kaksi askelta kun sinä olet kiitänyt jo tornin huipulle. Jos nyt tulen tornin huipulle hissillä ja yritän ymmärtää läpi käymääsi oppimisvaihetta.. niin.. Koodisi on huikeaa ja hienosti jaoteltu omiin kokonaisuuksiin, luulen että vielä joskus voin sen tajuta, mutta nyt. Ei.
juu.. yritän tehdä SELECT elementin ja siihen aion koodiasi käyttää apuna, mutta toisaalta.. ihmettelen miksei tällaista opasta ole?
<select name="author_id"> <?php foreach ($_authors as $author): ?> <option value="<?= h($author['id']) ?>"> <?= h($author['name']) ?> </option> <?php endforeach ?> </select>
..aikamoista, tätä yritän ymmärtää. Kiitän!
Onko järkevää rakentaa funktio ja sen sisään PDO-kysely. Kyselyyn voisi syöttää erilaisia parametrejä.
// valitse
function valitse() {
global $yksi;
global $kaksi;
$kysely = $yhteys->prepare("SELECT * FROM ryhma");
$kysely->execute();
while ($sarake = $kysely->fetch()) {
echo "<option value=" . $sarake[$yksi] . ">" . htmlspecialchars($sarake[$kaksi]) . "";
}
}En sitten tiedä tuon järkevyydestä, koska harvoin kyselyt ovat niinkin yksinkertaisia kuin SELECT * FROM X.
Parametrit muuten määritellään funktion määrityksen yhteydessä:
function funktio($parametri1, $parametri2)
Noniin.. ensimmäinen järkevä oma funktioni on nyt vihdoin valmis. Ideana on valinta lista, jota kutsutaan SELECT tagien sisällä:
// muodostetaan valintalista
<select name='R_Id'>
<?php valintalista("R_Id", "rNimi", "ryhma"); ?>
</select>
// funktio valintalista
function valintalista($sarake0, $sarake1, $taulunnimi) {
global $yhteys;
$kysely = $yhteys->prepare("SELECT * FROM " . $taulunnimi . "");
$kysely->execute();
while ($rivi = $kysely->fetch()) {
echo "<option value='" . $rivi[$sarake0] . "'>" . htmlspecialchars($rivi[$sarake1]);
}
}Valintalistoissa on usein "value" ja sama nimi uudestaan tai vastine. Mukavaa on että taulun voi itse valita sekä taulun sarakkeet. Homma toimii myös :) ..Tästä on hyvä mielestäni jatkaa.
Huomaa että tuossa on suuri tietoturva-aukko, kun $taulunnimi liitetään SQL-kyselyn jatkeeksi ilman tarkistuksia. Vaikka arvo ei tulisikaan (nyt) suoraan järjestelmän ulkopuolelta, se tulee silti käsitellä. Tee haku sanalla "SQL-injektio" ja katso kuinka se korjataan.
mietinvaan kirjoitti:
Huomaa että tuossa on suuri tietoturva-aukko, kun $taulunnimi liitetään SQL-kyselyn jatkeeksi ilman tarkistuksia.
Suuri? Miten sä injektoisit tuohon taulun nimeen?
Puolipiste vaan väliin ja uusi kysely sekaan.
Ohjelmointiputkassakin on sql-injektio opas, siellä puhutaan pdo:sta. Luin tietoturvasta myös muualta netistä, mutta onko tuo sql-lauseeni jotenkin väärin muotoiltu.
Minulle on usein kerrottu että en saisi koodata noin, eli jotenkin pitäisi määritellä muuttuja ensin vai? Php kirjassani puhutaan että jotenkin nuo pdo prepare ja sitten execute eivät päästäisi läpi mitään pahaa merkkiä. Vaan pdo olisi myös turvallisempi, no joo en sano enempää koska ei ole ammattitaitoa tähän, vielä.
mietinvaan kirjoitti:
Puolipiste vaan väliin ja uusi kysely sekaan.
Anteeksi, mutta miten asetat "puolipisteen vaan väliin", jos taulun nimi on kovakoodattuna funktion parametrinä?
lainaus:
<?php valintalista("R_Id", "rNimi", "ryhma"); ?>
edit:
Käyttäjä ei mitenkään voi aiheuttaa injektiota syötteellään tuohon, joten injektion vaaraa ei ole. Pelkät muuttujat tietokantakyselyissä eivät aiheuta automaattisesti injektion vaaraa, vaan se, että muuttujien arvoiksi otetaan käyttäjien syötteet niitä mitenkään tarkistamatta.
Tuollainen koodi on roskaa kuten jo sanoin. Tämä uusi esimerkkisi on vieläkin huonompi kuin se edellinen lyttäämäni koodinpätkä. Tietokantaa ei saa ikinä käpistellä siellä, missä tulostetaan tekstiä. Varsinkaan noin triviaaleissa funktioissa.
Koodiesimerkkini oli niin yksinkertainen, että sen perusidean ymmärtää kyllä koodia lukemalla. Et vain halua nähdä sitä vaivaa, että käsittelisit uusia asioita sen verran.
Jos haluat väen väkisin ulkoistaa html-elementtien tulostamisen funktiolle tai luokalle, niin sitten teet sen järkevästi ja teet sen niin, että koko elementti tulostetaan samassa paikassa, ei niin että osia jossain ja loput jossain toisaalla. Lisäksi teet toiminnosta niin geneerisen, että sitä voi käyttää muuallakin jottet joudu kirjoittamaan koko roskaa uusiksi heti, kun päätätkin haluavasi sinisen laatikon punaisen sijaan.
<?php
function h($str) {
return htmlspecialchars($str);
}
function html_select($name, $options, $current = '', $attrs = array()) {
$attrs['name'] = $name;
$html = '<select';
foreach ($attrs as $name => $value) {
$name = h($name);
$value = h($value);
$html .= " {$name}=\"{$value}\"";
}
$html .= '>';
foreach ($options as $value => $label) {
$value = h($value);
$label = h($label);
$selected = ($current == $value ? 'selected' : '');
$html .= "<option value=\"{$value}\" {$selected}>{$label}</option>";
}
$html .= '</select>';
return $html;
}
print html_select('foobar', array('a', 'b', 'c', 'd'), 2, array('class' => 'super'));Alkemisti, toivottavasti en suututa sinua enempää. Opettelen ylläolevan koodin myös, mutta miten itse opit koodaamaan noin ja ymmärtämään php:tä syvemmin? Minulle on sanottu että vasta työelämässä voi oppia neuvojen ja toistojen kautta. Koulussa ei kuulemma opi mitään.
Lisähuomautuksena, olen valmis tekemään työtä ja näkemään vaivaa php: n kanssa. Minulta puuttuu ymmärrys miten esim. Select boksi kannattaa tietoturvallisesti tehdä. Funktio erillisssä kirjastossa, html koodi erillissssä tiedostossa ja php erillisessä, sitten tietoturva ja näiden asioiden yhdistäminen toisiinsa. Muistaakseni lebe käski minua lukemaan sql-injektioneista, ja tein sen. Mielellään luen php:stä enemmän.
Esim w3schools on paljon selkeämpi ja iloisempi paikka oppia php:tä kuin esim karmean näköinen ja huonosti suunniteltu php.net
Ps. Kiitos jaksamisesta, en tahallani tehnyt huonoa funktiota, jopa hetken pidin sitä hyvänä. Nyt tajuan osittain miksi se on huono.. Kiitän.
Koulussa ei opi mitään. Työelämässä oppiminen on mahdollista vain, jos pääsee firmaan, jossa muut työntekijät osaavat jotain pelkän räpeltämisen sijaan. Viime kädessä kukaan ei opi yhtään mitään, ellei itse opettele asioita.
Minä en ole oppinut juurikaan asioita työn kautta. Tärkeimmät prinsiipit olen oppinut itse perehtymällä asioihin. En ole koskaan kysynyt ohjelmointiin apua foorumilla enkä oikeastaan missään muuallakaan.
Tärkein nyrkkisääntö on se, että itse tekemällä saa aikaan vain huonoa jälkeä. Php on erittäin huonosti varusteltu kieli. Jos sillä haluaa saada aikaan lainkaan siistiä jälkeä, joutuu kaiken tekemään alusta asti uusiksi. Hyvän kehysympäristön kasaaminen taas vaatii paljon, paljon työtä ennen kuin sillä pääsee tekemään mitään näkyvää jälkeä.
Olen aiemminkin sanonut, että nollasta aloittamisen sijaan pitäisi ennemmin lähteä opiskelemaan jotain valmista ratkaisua. Teknisen alustan valinta riippuu siitäkin, millä abstraktiotasolla haluaa itse työskennellä.
Olet jossain kertonut käyttäneesi WordPressiä. Jos se on sopiva alusta sinun tarkoituksiisi, niin unohtaisin tuommoiset turhat select-boksien tulostamiset käsin, koska WP:ssä on aivan varmasti rajapinnat niitä ja kaikkia muitakin lomakekomponentteja varten. Itse asiassa WP:ssä on aivan varmasti kokonainen lomakekirjasto, jonka avulla lomakkeiden luominen ja lomakkeiden tietojen hallinta on nopeaa ja helppoa.
WP:lle koodatessa opit myös tuntemaan siinä käytetyt paradigmat ja mahdollisesti myös sitä, miten WP toimii "pellin alla". Tästä saat paremmat eväät jatkossa täysin oman arkkitehtuurin toteuttamiseen kuin arpomalla vuosikausia tai -kymmeniä sen kanssa, miten olisi tyhmintä tulostaa yksinkertainen pudotusvalikko nettisivulle.
Alan jo olla sitä mieltä, ettei opiskelunkaan aloittaminen nollasta sovi sinulle. Jos opit WP:lle koodaamaan mitään, niin ehkä on tulevaisuutta alan parissa.
Php.netissä ei opeteta käyttämään php:tä. Siellä kerrotaan miten eri funktiot toimivat. Jos haluat oppia käyttämänä niitä oikein ja oikeassa paikassa, niin joudut etsimään apua jostain muualta.
Okei, alan ymmärtämään pointtisi. Omat kotisivuni on tehty käyttäen WP:tä ja omaa php koodia. Mielestäni muutenkin olisi järkevämpi käyttää valmiita elementtejä, joidenka toimintalogiikan ymmärtää. Sanon kuitenkin sen että Suomessa on lukuisia pk-yrityksiä, joilla ei ole halua maksaa omista web-sivuista tai jostakin työvuoronvarausohjelmasta useita tuhansia euroja.
On mahdollista että hyvän tason harrastekoodari voi toteuttaa tällaisille yrityksille (esim. parturi-kampaamo) oman web-sivu/sovellus kokonaisuuden. Josta hyötyvät kaikki, työntekijät, asiakkaat ja koodari itse ylläpidon/ teknisen tuen puitteissa. Myös koko ala, parturit, saavat näkemyksen että näinkin voi ihmisille varata aikoja ja kertoa uutuustuotteista.
Sitten toinen asia on WEB, jonka parissa olen viettänyt nyt lähes 4 vuotta ja aion jatkossakin viettää. Minulla on mahdollisuus päästä tietylle hyväksyttävälle tasolle php:ssä ja muissa web-tekniikoissa. On toki selvää että vahvuuteni ovat kuitenkin esim. visuaalisuus, värit, käyttöliittymät, valokuvaus, suunnittelu. Yritän hallita koko pakettia, tavallaan designer, developer, yksityisyrittäjä pohjalta.
Kokonaisuus ei kuitenkaan ole ihan parasta A-luokkaa, johon kuitenkin pyrin. Toinen suuri haaste on "Responsive Design" eli haluan kehittää web-sivut-> (desktop, laptop, tablet, smartphone) -ympäristöön. Alkemisti, suurkiitos että uskallat puhua suoraan ja tuoda näkemyksiäsi esille. Ne ovat lopulta todella tärkeitä meille kaikille.
Oma filosofiani:
- WEB-ammattilaisten pitäisi tehdä paljon enemmän yhteistyötä
- Standardit
- Yhdessä järkevän koodaustavan opettelu (esim. yllä alkemistin koodi)
- Pyörää ei saa keksiä uudelleen, Wordpress kouluaineeksi jo yläasteella
- Yksi hyvä foorumi, jossa kirjoitetaan oman kuvan ja nimen kera
- Joku perusrakenne web-sivuihin? Esimerkkiä kirjoista:
--etukansi
--takakansi
--sisällysluettelo
--tekijän tiedot
--vuosiluvut
--jaksot, kappaleet, otsikot, alaotsikot
-> Kun ihminen tulee ensi kertaa web-sivulle hän tajuaa heti miten kaikki toimii. Sama efekti kun ottaa kirjan käteen. Luetaan takakannesta hieman kirjan ideasta ja tekijästä. Ihaillaan etukantta. Selataan sisällysluettelo läpi. Plärätään kappaleet läpi ihaillen fonttia ja otsikko tyylejä. On sivunumerot jne.
WEB on vasta nyt ottamassa niitä isoja askeleita. Miksemme kaikki voisi vaikuttaa siihen suuntaan mihin kuljemme yhdessä? Voisimme olla paljon avoimempia, jolloin tekisimme oikeita asioita. Itse haluan kirjoittaa hyvää koodia joka on validoitu. Uskon että pystyn nousemaan seuraavalle tasolle kunhan ensin saan paremman perusymmärryksen.
:)
latenleffahylly kirjoitti:
Okei, alan ymmärtämään pointtisi. Omat kotisivuni on tehty käyttäen WP:tä ja omaa php koodia. Mielestäni muutenkin olisi järkevämpi käyttää valmiita elementtejä, joidenka toimintalogiikan ymmärtää. Sanon kuitenkin sen että Suomessa on lukuisia pk-yrityksiä, joilla ei ole halua maksaa omista web-sivuista tai jostakin työvuoronvarausohjelmasta useita tuhansia euroja.
Liittyvätkö nämä virkkeet jotenkin toisiinsa, kun kerta ovat samassa kappaleessa? Valmiin alustan käyttämisessä on juuri se etu, että kehitystyö on paljon nopeampaa ja luotettavampaa, koska kaikkea ei tarvitse tehdä itse ja koska käytetään testattuja komponentteja. Jos lähdet tekemään järjestelmiä alusta asti itse, niin hinta tulee olemaan moninkertainen, minkä lisäksi mikä tahansa saattaa räjähtää koska tahansa, ja sitten taas nostetaan lisää palkkaa bugeja ratkoessa.
The Alchemist kirjoitti:
Liittyvätkö nämä virkkeet jotenkin toisiinsa, kun kerta ovat samassa kappaleessa?
Tapahtumapalvelun versio 1 oli tehty WP:tä apuna käyttäen. Nyt versiossa 2 yritän rakentaa kaiken alusta asti itse jotta oppisin paremmin ymmärtämään koodausta ja web-maailmaa. Asioita kuten:
- istunnot, evästeet, tietoturva
- rekisteröinti, käyttäjän luominen, lomaketiedon tallentaminen, muokkaaminen, poistaminen ja tulostaminen oikein
- web-sivujen jakaminen eri osiin: julkinen, suljettu, ylläpito (ja käyttöoikeudet näihin)
- käyttäjän tunnistaminen
- javascript & php tarkistukset
- jquery kirjaston käyttö
..olen nyt huomannut että työtä on paljon, mutta toisaalta olen oppinut valtvavasti. Sen sijaan se että osaisin käyttää oikein funktioita tai että ymmärtäisiän olioita ja luokkia niin on tulevaisuudessa. Tähän projektiin liittyvät myös:
- phpmyadmin
- webhotelli
- testiympäristö, apache, mysql, php
- valokuvaaminen, grafiikan teko, photoshop cs6 jne.
Lisäksi:
- kommunikointi asiakkaan kanssa
- asiakkaan asiakkaiden kartoittaminen ja kommunikointi
- ylipäätää dokumentaatio, testaus, suunnittelu, markkinointi, budjetti, (sponsorit)
huoh.. hommaa riittää. Sen vaan sanon teille kaikille että versio 1 on myyty ja palaute otettu vastaan. Nyt versio 2 pitäisi olla ihan eri tasolla. Miksi en voisi tehdä versiota 3 - käyttäen apuna WP:tä ja muutenkin tehdä parempaa koodia? Miksi minua sorretaan täällä jatkuvasti, toivon että joku edes sanoisi että voin oppia koodaamaan paremmin. Tällä hetkellä raskas olo tästä asiasta johtuen...
latenleffahylly kirjoitti:
- Pyörää ei saa keksiä uudelleen, Wordpress kouluaineeksi jo yläasteella
Mielestäni koulujen on hyvä opettaa yleisiä ongelmanratkaisumenetelmiä ja tapoja pärjätä elämässä eikä rajoittua tiettyihin ohjelmistoihin, jotka saattavat vanheta ennemmin tai myöhemmin.
Ohjelmoinnin opiskelu vaatii kärsivällisyyttä. Monesti sivut kuten muutkin ohjelmat kannattaa ensiksi suunnitella kunnolla, sitten jakaa sopivankokoisiin loogisiin paloihin ja miettiä kullekin palalle järkevin toteutus. Mulla ei ole valitettavasti WP:stä kokemusta, joten en osaa auttaa sen opiskelussa.
The Alchemist kirjoitti:
Koulussa ei opi mitään.
Koulussa voi kuitenkin saada perusteista (if-lauseista, silmukoista, funktioista jne.) vastaavat tiedot kuin oppaistakin, jotta voi opetella näitä asioita itse. Lisäksi koulussa voi olla tehtäviä ja tenttejä, jotka varmistavat, että oppiminen etenee.
latenleffahylly kirjoitti:
Miksi minua sorretaan täällä jatkuvasti,
Koska olet räpeltänyt tälläkin foorumilla kohta jo vuoden samanlaista purkkaa ilman minkäänlaista kehitystä, vaikka parempia tapoja on neuvottu lukemattomia kertoja ja olet myös monesti luvannut opetella lisää.
latenleffahylly kirjoitti:
Toivon että joku edes sanoisi että voin oppia koodaamaan paremmin.
Kun kirjoitit tuon yhden lyhyen koodin, johon vastasin "Hurraa!", näytti hetken, että vihdoin olisit oppinut jotain. Kuitenkin heti seuraavat koodit olivat taas yhtä huonoja kuin ennenkin, joten selvästikään mitään aitoa oppimista ei vielä tapahtunut – kuten ei ennenkään. Ehkä sitten todellakaan et voi oppia, vaikka se luultavasti johtuukin vain asenteesta ja toimintatavoista.
Sinun pitää soveltaa kaikkia hyviä tapoja samalla kertaa eikä vain yhtä niistä. Esimerkiksi minkä tahansa funktion tekeminen ei ole hyvä asia, vaan myös sen sisällön pitää olla järkevä, ja aikaisemman periaatteen mukaan sielläkään ei pitäisi sekoittaa tiedon hakemista ja tulostamista.
Äsken mainitsemassani Hurraa-varauslomakkeessa voisit soveltaa funktioita yksinkertaisimmillaan vaikka niin, että jokainen kysely prepare-rivistä fetch-riviin olisi omana funktionaan, joita kutsuttaisiin näin:
$tieto = hae_tapahtuman_tiedot($_GET["T_Id"]); $tarve = hae_tapahtuman_tarve($_GET["T_Id"]); $jvTarve = hae_tapahtuman_jarjestyksenvalvojatarve($_GET["T_Id"]); $varaus = hae_tapahtuman_varausmaara($_GET["T_Id"]);
Tämä on tietenkin hyvin alkeellinen esimerkki eikä suinkaan paras mahdollinen tapa, mutta tämän onkin tarkoitus olla helposti ymmärrettävä ja suoraan sinun nykyiseen koodiisi sopiva.
Juu.. Olen nyt viimeaikoina miettinyt paljon. Ehkä on niin että kaikilla ei ole kykyä oppia php:tä. Toisaalta pitäisi osata pitää taukoa, antaa itselle aikaa sisäistää joku kokonaisuus ja vasta sitten opetella uusi asia. Muutenkin menen perusteista liian nopeasti vaikeampaan materiaaliin.
Mutta alkemisti on siinä oikeassa että ehkä minulle sopii paremmin opetella esim WP inside out. Ymmärtää php koodia mielummin kuin yrittää itse tuottaa täydellistä sellaista.
Minulta puuttuu jokin perusymmärrys php:stä, sillä en ihan juuri nyt osaa yhdistää metabolixin mallia omaan koodiini. Mielestäni se kertoo jostain karua kieltä. Toisaalta haluan muistuttaa että olen nähtävästi opetellut koodaamista jotenkin ihan väärällä tavalla. Jatkossa alan miettimään hyvinkin tarkkaan uskallanko kysyä täältä apua, tai onko se edes järkevää. Netti on täynnä esim. Hyviä WP vinkkejä joten.. No tämä on hankalaa, sillä olen ollut siinä uskossa että voin oppia php:n hyvälle tasolle vuodessa. Siis jokin hyvä perustaso, jossa mm. Luokat ja olio-ohjelmointi.
Eikä pidä ajatella niin, että joka kerta, kun huomaa tarvitsevansa jotain dataa tietokannasta, kirjoittaa sille uuden funktion. Jossain välissä tulee käymään niin, että rajapinnasta on tullut niin bloatti ja monimutkainen, ettei itsekään enää muista, onko jollekin toiminnolle jo funktio tai että mikä sen nimi oli ja millä parametreilla sitä piti kutsua. Lisäksi muistutan siitä, että mitä enemmän sql:ää on koodiinsa kirjoittanut, sitä vaikeampaa on tietokantaan tehdä muutoksia jälkikäteen.
Toisaalta taas, jos funktioista yrittää tehdä liian yleiskäyttöisiä, rajapinta monimutkaistuu esim. sen takia, että funktiot ottavat liian paljon parametreja. Tai sitten suoritettava sql-kysely on niin monimutkainen, ettei sitä kannata käyttää kaikissa yksinkertaisimmissa tapauksissa, joihin funktio muuten soveltuisi.
Ongelmiin löytyy aina useita ratkaisuita eikä mikään tunnetuista ratkaisuista ole välttämättä yksiselitteisesti muita parempi. Siksi ei voi mitenkään riittää, että osaa ohjelmointikielen syntaksin, vaan pitää ymmärtää ohjelmoinnin teoriastakin jotain.
latenleffahylly kirjoitti:
No tämä on hankalaa, sillä olen ollut siinä uskossa että voin oppia php:n hyvälle tasolle vuodessa. Siis jokin hyvä perustaso, jossa mm. Luokat ja olio-ohjelmointi.
Löysin aihetta sivuavan keskustelun, jossa on listattu tarvittavia taitoja.
latenleffahylly kirjoitti:
Minulta puuttuu jokin perusymmärrys php:stä, sillä en ihan juuri nyt osaa yhdistää metabolixin mallia omaan koodiini. Mielestäni se kertoo jostain karua kieltä.
No aivan selvästi kertoo. Et ymmärrä, mikä funktio on ja miten se toimii. Mikäli ei ymmärrä funktioita, ei ole mitään toivoa luokkien ymmärtämisestä, koska luokat laajentavat funktion käsitettä uusilla asioilla.
Käyn funktiot läpi huolellisesti. Tämä on siksi tärkeää että tutkin Wordpress kirjasta WP:n sisällä olevaa funktiota. Eli vaikka sitä ei osaisi itse koodata niin sen ymmärtäminen 100% olisi kova juttu. Eli seuraavaksi op:n funktio oppaan pariin ja kuppi kahvia.
Funktioissa ei itsessään ole mitään ymmärrettävää: ne vain ottavat joukon lähtötietoja (parametrit) ja tuottavat niiden pohjalta uutta dataa (paluuarvo). Vaikeus piilee siinä, että pitää osata nähdä, mitkä kokonaisuudet kannattaa eristää omaan funktioonsa. Lisäksi siinä ei ole mitään järkeä, että funktion sisäinen toteutus on satoja koodirivejä pitkä, vaan on järkevää pilkkoa kokonaisuuksia pienempiin funktioihin, joita muut funktiot sitten kutsuvat.
Merkittävin ongelma on varmaan se, että toiminnallisuuden pilkkominen useisiin funktioihin rajoittaa pääsyä dataan: funktiolla on saatavilla vain se tieto, mitä sille annetaan parametreina. Parametrien määrän taas pitäisi olla "järkevä". Jostain kirjasta olin lukevinani, että kolme parametria on yleisesti järkevä enimmäismäärä, koska sen jälkeen alkaa olla vaikeaa muistaa annettavien parametrien järjestys ja merkitys.
Toinen tärkeä pointti on se, missä järjestyksessä parametrit annetaan. Esimerkiksi monet php:n natiiveista funktioista kärsivät siitä, että niiden kirjoittajat ovat olleet suoraan sanoen idiootteja.
Luokat monimutkaistavat asioita esimerkiksi siten, että nyt luokan funktiot (tai "metodit") voivat käyttää myös muutakin dataa kuin niille suoraan annetut parametrit, ja että ne voivat paluuarvojen sijaan muokata olion sisäistä tilaa.
Voitteko kertoa onko tällainen tapa järkevä? Ja miten pystyn tulostamaan oikealla tavalla funktion palauttaman tiedon? Kiitos jos viitsitte sillä tavalla auttaa etten opettele taas jotenkin väärin.
-----------------------------------
<?php
// funktiot.php
function haeKaikki($taulunnimi) {
global $yhteys;
global $kysely;
$kysely = $yhteys->prepare("SELECT * FROM " . $taulunnimi . "");
$kysely->execute();
}
?><?php
// tulostaminen tapahtuu toisessa paikkaa
haeKaikki("ryhma");
while ($tulos = $kysely->fetch()) {
echo "" . $tulos["R_Id"] . $tulos["rNimi"] . "";
}
?>Huom! Koodi toimii ja tapa on mielestäni ok. Se että haetaan kaikki tieto niin ei pidemmän päälle ole ok.
Aika hirveetä että funktiolle viedään vain taulun nimi ja funktiossa oletetaan että $yhteys on asetettu ja sijoitetaan kysely globaaliin muuttujaan. ;(
Eihän kukaan tiedä mistä muuttujat saavat arvonsa ja missä vaiheessa.
Jos on pakko tehdä se tuolla tavalla, vie myös PDO yhteys funktiolle ja palauta kyselyn tulos.
$yhteys = Db::getPdoInstance(); // tjn. function haeKaikkiTaulunRivit(PDO $yhteys, $taulu) { $kysely = $yhteys->prepare("SELECT * FROM " . $taulu); $kysely->execute(); return $kysely->fetchAll(); // tai $kysely } try { $vastaus = haeKaikkiTaulunRivit($yhteys, 'ryhma'); foreach ($vastaus as $rivi) echo htmlspecialchars($rivi["rNimi"]); //jne.. } catch (PDOException $e) { print("Ongelma.." . $e->getMessage()); }
Miten luot PDO yhteyden, ja miten hallinnoit sitä?
Eipä se Laten funktio näyttänyt myöskään palauttavan mitään. Itse voisin kuvitella, että se palauttaisi edes tuon $tulos -taulukon.
Lebe80 kirjoitti:
Eipä se Laten funktio näyttänyt myöskään palauttavan mitään. Itse voisin kuvitella, että se palauttaisi edes tuon $tulos -taulukon.
Mutta sehän asetti kyselyn globaaliin muuttujaan...
qeijo kirjoitti:
Lebe80 kirjoitti:
Eipä se Laten funktio näyttänyt myöskään palauttavan mitään. Itse voisin kuvitella, että se palauttaisi edes tuon $tulos -taulukon.
Mutta sehän asetti kyselyn globaaliin muuttujaan...
Aivan, mutta luulisi että tuollainen funktio mieluummin palauttaisi esim. tuloksen, kuin asettaisi sen globaaliin muuttujaan.
Tällöin siitä näkisi suoraan, että mitä se funktio edes tekee.
Okei, eli nähtävästi tapani ei ole hyväksyttävä. Tuo koodi toimii. Jotenkin ajattelin että funktiolle lähetetään tieto-> haeKaikki("tapahtuma");
- taulun nimen voi itse valita
- funktio hakee tiedot tietokannasta ja.. no joo ehkä tuossa sitten se suurin virhe. Olette varmaankin jo sanoneet miten kannattaa tehdä. Tuota, tuota.. ehkä yritän vielä kerran uudestaan, mutta tosiaan tuota ohjelmointiputkan opasta olen käynyt läpi ja sen kautta yrittänyt rakentaa omaa funktiota, pahoittelut osaamattomuudestani, jälleen kerran.
Yleisesti ottaen global-sanaa ei pitäisi koskaan tarvita.
Jaa.. no miten sitten nuo putkan oppaat? Jos haluat käyttää muuttujaa funktion ulkopuolella jne. ?
Mun mielestä tuollaisessa tietokantahaussa pitäisi kyllä kaiken järjen mukaan olla myös jokin sääntö missä järjestyksessä tieto tulee tulokseen.
Eli kun ei selkeästikään haeta tiettyä riviä, niin tulokset olisi hyvä olla jossain järkevässä järjestyksessä, esim. uusimmasta vanhimpaan (tai juoksevan id:n mukaan).
No.. kysyn nyt näin voitteko ranskalaisin viivoin kertoa miten oma funktio rakennetaan.
index.php
- kutsu funktiota ja lähetä 1-3 parametriä
funktiot.php
- tee parametreille jotain ja palauta tulos
index.php
- tulosta tulos-muuttuja sisältö
Mitä tässä tapauksessa funktion pitäisi tehdä?
No... otetaan esimerkki. Ohjelmointiputka:
<?php
function valintalista($nimi, $sisalto) {
echo "<select name=\"{$nimi}\">";
foreach ($sisalto as $kohta) {
echo "<option value=\"{$kohta}\">{$kohta}";
}
echo "</select>";
}
echo "<p>Valitse syntymäpäiväsi:</p>";
valintalista("paiva", range(1, 31));
valintalista("kuukausi", range(1, 12));
valintalista("vuosi", range(1900, 2010));
?>Nyt itse yritän tehdä tämän tietokanta mukaan luettuna:
ryhma-taulu
R_Id
1
2
3
rNimi
jv
tr
em
- Eli tarvitsen mielestäni funktion joka hakee tiedot
- ja funktion joka rakentaa select boksin
- toisaalta en enää uskalla sanoa mitään koska aina mokaan ja sekoitan asiat, ei pahalla :/
Siis sä voit tehdä omat funktiot, mitkä hakee tietokannasta tiedot, ja oman funktion sille, mikä vaikka parsii tietokannan tiedot taulukkoon, sulle oikeaan muotoon. Ja lisäks funktio mikä rakentaa taulukosta alasvetovalikon. Ei noiden kaikkien tarvitse olla yhdessä funktiossa.
Kiitos Lebe80, juuri tämä tieto on oleellinen. Eli jutut voi jakaa noinkin pieniin osiin. Funktio idea, haetaan tietoa tietokannasta:
function hae($taulunnimi) {
$kysely = $yhteys->prepare("SELECT * FROM " . $taulunnimi . "");
// return mitä?
}Tässä ongelmana on se että kysely-muuttuja ei toimi. Eli sille pitäisi kertoa että se on globaali muuttuja.. huoh.. yritän tutkia putkan oppaita, mutta eikö tavallaan ensin pitäisi aloittaa pdo-avaa tietokantayhteys, ja kertoa että se vaikuttaa kaikkiin alla oleviin funktioihin. Tavallaan nämä funktiot kuuluvat luokkaan pdo..?
latenleffahylly kirjoitti:
..mutta eikö tavallaan ensin pitäisi aloittaa pdo-avaa tietokantayhteys, ja kertoa että se vaikuttaa kaikkiin alla oleviin funktioihin..
Tee yksi stattinen PDO yhteys.
yhteys.php:
<?php
// muodostetaan yhteys tietokantaan
try {
$yhteys = new PDO("mysql:host=localhost;dbname=testi", "user", "123");
} catch (PDOException $error) {
die("VIRHE: " . $error->getMessage());
}
// virheenkäsittely: virheet aiheuttavat poikkeuksen
$yhteys->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// merkistö: käytetään utf8-merkistöä
$yhteys->exec("SET NAMES utf8");
?>funktiot.php:
function hae2saraketta($sarake0, $sarake1, $taulunnimi) {
global $yhteys;
$kysely = $yhteys->prepare("SELECT " . $sarake0 . "," . $sarake1 . " FROM " . $taulunnimi . "");
}Ilman global -sanaa homma ei toimi.
En tarkoita tätä nyt pahala mutta.
Ei kamalasti inspiroi vastaamaan sinun kysymyksiin, kun et selvästikkään ole vaivautunut lukemaan edes perusasioista itse.
Mitä tarkoitat? Funktioni toimii, mutta haluan tehdä asiat oikein. Olen käynyt ohjelmointiputkan funktio opasta läpi. Eli pyrin tekemään mahdollisimman pieniä funktioita. No harmittaa.. koska mielestäni teen tavallaan ihan oikein:
function hae2saraketta($yhteys, $sarake0, $sarake1, $taulunnimi) {
return $kysely = $yhteys->prepare("SELECT " . $sarake0 . "," . $sarake1 . " FROM " . $taulunnimi . "");
}- kun halutaan tulostaa Select-boksi, niin kerrotaan sarakkeiden otsikot ja taulu josta tieto haetaan. Ongelmana tässä on tuo palauttaminen. Ja se että haluan tehdä oikein asiat.. mutta saan vain haukkuja? vai..
latenleffahylly kirjoitti:
Okei, eli nähtävästi tapani ei ole hyväksyttävä. Tuo koodi toimii. Jotenkin ajattelin että funktiolle lähetetään tieto-> haeKaikki("tapahtuma");
- taulun nimen voi itse valita
- funktio hakee tiedot tietokannasta ja.. no joo ehkä tuossa sitten se suurin virhe. Olette varmaankin jo sanoneet miten kannattaa tehdä. Tuota, tuota.. ehkä yritän vielä kerran uudestaan, mutta tosiaan tuota ohjelmointiputkan opasta olen käynyt läpi ja sen kautta yrittänyt rakentaa omaa funktiota, pahoittelut osaamattomuudestani, jälleen kerran.
Sanoin sinulle juuri omaa viestiäsi edeltäneessä postauksessani, että funktio saa käsitellä vain sille parametreina annettua tietoa. Sitten osoitat täydellisestä "ignorancea" (mikä lie sopiva suomennos) ja teet täysin järjettömän funktion, jolle annetaan parametreja lähinnä muodon vuoksi ja joka nojaa täysin käsittämättömällä tavalla globaaleihin niin syötteiden (funktiolle välitettävä data) kuin tulosteenkin (funktion tuottama valmis data) osalta.
Lisäys:
Metabolix kirjoitti:
Yleisesti ottaen global-sanaa ei pitäisi koskaan tarvita.
Laajennan tätä aksioomaa vielä seuraavasti:
Myöskään muuttujia, joita ei alusteta samassa skriptitiedostossa, ei pitäisi koskaan tarvita.
Toisin sanoen seuraavassa tilanteessa koodi on rikki ja koodari kaipaa lisäoppia:
*** foo.php <?php $foo = 5;
The Alchemist kirjoitti:
Myöskään muuttujia, joita ei alusteta samassa skriptitiedostossa, ei pitäisi koskaan tarvita.
Mielestäni ohjelmassa ei saisi olla 'irrallista' logikkaa juuri ollenkaan.
Toteutuksen täytyisi jo alusta asti noudattaa jotain arkkitehtuurityyliä.
Kun ohjelma kasvaa, se kasvatetaan hallitusti, noudattamalla samaa kaavaa.
Okei yritän olla tarkempi. Putkan oppaassa oli tuon global funktion käyttöä, siitä mallinsin. Nyt opettelen youtuben kautta omaa funktiota. Alkemistille sen verran, onko mahdollista että ohjelmointiputkassa hieman jatkettaisiin funktio esimerkkejä. Eli näin teet funktion järkevästi, juuri nuo pointtisi boldattuna?
Valitettavasti jouduin ekaa kertaa hylkäämään putkan oppaan ja etsimään tutoriaalia youtubesta. Siellä kerrotaan yksityiskohtaisesti mitä tehdä ka oppiminen on sitten se toinen iso asia. Opin paremmin videoiden kautta, esim. Tuo geijon esimerkki menee ohi koska se on tarkoitettu funktiot ymmärtäville.
Tämä taitaa jäädä viimeiseksi esimerkiksini tällä saraa, joten toivottavasti siihen (ja myös tuohon edelliseen esimerkkiini) paneudutaan sen ansaitsemalla tasolla.
http://sj87.hopto.org/lefanavi.tar.gz (Paketissa on muitakin tiedostoja kuin alla esitetyt php-koodit.)
Tuo snippetti havainnollistaa Lebe80:n aiemmin päivällä mainitsemia pointteja käytännön tasolla. Lisäksi se havainnollistaa yleiskäyttöisten funktioiden tuomaa lisäarvoa.
*** functions/common.php
<?php
function db() {
static $db;
if (!$db) {
$db = new PDO('mysql:dbname=test', 'root');
$db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
}
return $db;
}
/**
* Hakee sivut tietokannasta
**/
function get_pages() {
$sql = '
SELECT
a.id,
a.url,
a.parent_id,
a.name,
a.content
FROM pages a
ORDER BY a.name
';
$smt = db()->prepare($sql);
$smt->execute();
$data = $smt->fetchAll();
return $data;
}
/**
* Rakentaa linkkilistasta puurakenteen
*
* @return array
**/
function build_navigation_tree($pages) {
$tree = array();
// Alustetaan puu
foreach ($pages as $item) {
$id = $item['id'];
$item['children'] = array();
$tree[$id] = $item;
}
// Luodaan puurakenne
foreach ($tree as &$item) {
$id = $item['id'];
if ($pid = $item['parent_id']) {
$tree[$pid]['children'][$id] = $item;
}
}
unset($item);
// Poistetaan juuritasolta ne rivit, jotka ovat oikeasti lapsia
foreach ($tree as $id => $item) {
if ($item['parent_id']) {
unset($tree[$id]);
}
}
return $tree;
}
/**
* Geneerinen versio funktiosta build_navigation_tree
*
* Rakentaa puun mistä tahansa listasta
*
* @param $data Lista alkioista
* @param $dst_idx Indeksi, johon alkion lapset laitetaan
* @param $map Mappingit, joiden perusteella päätellään lapsi-vanhempi-suhde (child => parent)
*
* @return array
**/
function build_tree($data, $dst_idx, $map) {
$tree = array();
$a = key($map);
$b = current($map);
// Alustetaan puu
foreach ($data as $item) {
$id = $item[$a];
$item[$dst_idx] = array();
$tree[$id] = $item;
}
// Luodaan puurakenne
// Käytetään viittausta $item-muuttujaan, jotta saadaan luotua puurakenne
// aina n:nteen tasoon asti
foreach ($tree as &$item) {
$id = $item[$a];
if ($pid = $item[$b]) {
$tree[$pid][$dst_idx][$id] = $item;
}
}
// Tuhotaan viittaus, jotten vahingossa ylikirjoiteta viimeistä muuttujan
// viittaamaa indeksiä
unset($item);
// Poistetaan juuritasolta ne rivit, jotka ovat oikeasti lapsia
foreach ($tree as $id => $item) {
if ($item[$b]) {
unset($tree[$id]);
}
}
return $tree;
}
/**
* Palauttaa puumaisen linkkilistan kaksiulotteiseksi listaksi
*
* @return array
**/
function flatten_navigation_tree($pages) {
$list = array();
foreach ($pages as $item) {
$children = $item['children'];
unset($item['children']);
$list[] = $item;
if (count($children) > 0) {
$list = array_merge($list, flatten_navigation_tree($children));
}
}
return $list;
}
/**
* Geneerinen versio funktiosta flatten_navigation_tree.
*
* Palauttaa puumaisen taulukon kaksiulotteiseksi listaksi.
*
* @param $tree Puurakenne
* @param $src_idx Indeksi, josta lapsialkiot luetaan
* @return array
**/
function flatten_tree($tree, $src_idx) {
$list = array();
foreach ($tree as $item) {
$children = $item[$src_idx];
unset($item[$src_idx]);
$list[] = $item;
if (count($children) > 0) {
$list = array_merge($list, flatten_tree($children, $src_idx));
}
}
return $list;
}
/**
* Suhteellisen huonosti toteutettu funktio, jonka tarkoitus on ainoastaan
* demota geneeristä rajapintaa erilaisten navigaatioiden tulostamiseksi.
**/
function print_navigation($pages, $config = array(), $style = 'basic') {
$current_id = array_get($config, 'active');
switch ($style) {
case 'basic':
$recursive = array_get($config, 'tree', false);
print_basic_menu($pages, $current_id, $recursive);
break;
case 'breadcrumb':
print_crumb_menu($pages, $current_id);
break;
}
}
function h($string) {
return htmlspecialchars($string);
}
function array_get($array, $key, $default = null) {
return array_key_exists($key, $array) ? $array[$key] : $default;
}*** functions/navi_basic.php
<?php
/*
* Funktiot tavallisen listanavigaation tulostamiseen.
*/
function print_basic_menu($items, $current_id, $recursive) {
?>
<ul>
<?php
foreach ($items as $item) {
print_basic_node($item, $current_id, $recursive);
}
?>
</ul>
<?php
}
function print_basic_node($item, $current_id, $recursive) {
$classes = array();
if ($recursive) {
$children = $item['children'];
if (count($children) > 0) {
$classes[] = 'has-children';
}
} else {
$children = array();
}
if ($item['id'] == $current_id) {
$classes[] = 'active';
}
if (count($classes) > 0) {
$class = ' class="' . implode(' ', $classes) . '"';
} else {
$class = '';
}
?>
<li<?= $class ?>>
<a href="<?= h($item['url']) ?>"><?= h($item['name']) ?></a>
<?php if (count($children) > 0): ?>
<?php print_basic_menu($children, $current_id, $recursive) ?>
<?php endif ?>
</li>
<?php
}*** functions/navi_breadcrumb.php
<?php
/*
* Funktiot murupolkutyylisen navigaation tulostamiseen.
*/
function find_trace_from_tree($tree, $current_id) {
foreach ($tree as $item) {
$id = $item['id'];
if ($id == $current_id) {
return array($id);
} else {
$trace = find_trace_from_tree($item['children'], $current_id);
if (count($trace) > 0) {
array_unshift($trace, $id);
return $trace;
}
}
}
return array();
}
function print_crumb_node($tree, $trace) {
$current_id = array_shift($trace);
$item = $tree[$current_id];
$children = $item['children'];
$classes = array('trace');
if (count($trace) == 0) {
$classes[] = 'active';
}
?>
<li class="<?= implode(' ', $classes) ?>">
<a href="<?= h($item['url']) ?>"><?= h($item['name']) ?></a>
<?php
print_crumb_submenu($tree, $current_id);
?>
</li>
<?php
}
function print_crumb_submenu($pages, $current_id) {
?>
<ul class="submenu">
<?php foreach ($pages as $item): ?>
<li>
<a href="<?= h($item['url']) ?>"><?= h($item['name']) ?></a>
</li>
<?php endforeach ?>
</ul>
<?php
}
function print_crumb_menu($pages, $current_id) {
$trace = find_trace_from_tree($pages, $current_id);
?>
<ul id="navigation-crumb">
<li class="trace">
<a href="#">Index</a>
</li>
<?php
while (!empty($trace)) {
print_crumb_node($pages, $trace);
$i = array_shift($trace);
$pages = $pages[$i]['children'];
}
?>
</ul>
<?php
}*** demo.php <?php require 'functions/common.php'; require 'functions/navi_basic.php'; require 'functions/navi_breadcrumb.php'; $pages = get_pages(); // Nämä kaksi funktiota tuottavat täsmälleen saman tuloksen $tree = build_navigation_tree($pages); $tree = build_tree($pages, 'children', array('id' => 'parent_id')); // Nämäkin kaksi funktiota tuottavat täsmälleen saman tuloksen $list = flatten_navigation_tree($tree); $list = flatten_tree($tree, 'children'); ?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Navigation Demo</title> <meta charset="UTF-8"/> <link href="style.less" type="text/less" rel="stylesheet"> <script src="less-1.3.1.min.js" type="text/javascript"></script> </head> <body> <div> <div id="demo-1"> <b>Kaikki sivut samassa tasossa, lajiteltuna aakkosittain</b> <?php print_navigation($pages, array('active' => 16)) ?> </div> <div id="demo-2"> <b>Kaikki sivut samassa tasossa, lajiteltuna lapsi-vanhempi-suhteen mukaisesti</b> <?php print_navigation($list) ?> </div> <div id="demo-3"> <b>Vain ylimmän tason sivut</b> <?php print_navigation($tree) ?> </div> <div id="demo-4"> <b>Kaikki sivut puurakenteessa</b> <?php print_navigation($tree, array('active' => 12, 'tree' => true)) ?> </div> </div> <div> <div id="demo-5"> <b>Murupolku alavalikoiden kanssa</b> <?php print_navigation($tree, array('active' => 8), 'breadcrumb') ?> </div> </div> </body> </html>
latenleffahylly kirjoitti:
Mitä tarkoitat? Funktioni toimii, mutta haluan tehdä asiat oikein. Olen käynyt ohjelmointiputkan funktio opasta läpi. Eli pyrin tekemään mahdollisimman pieniä funktioita.
Aivan silkasta uteliaisuudesta kysyn, että mitä tarkoitat "mahdollisimman pienellä"? Siis: milloin funktio on "mahdollisimman pieni", ja millä tavoin koodi on parempaa, kun olet saavuttanut tämän tavoitteen? Enkä tarkoita, että käyt nyt googlettamassa äkkiä jotain, vaan haluan tietää, miksi väännät tietynlaista koodia ja mitä odotat siitä saavasi.
latenleffahylly kirjoitti:
Okei yritän olla tarkempi. Putkan oppaassa oli tuon global funktion käyttöä, siitä mallinsin. Nyt opettelen youtuben kautta omaa funktiota. Alkemistille sen verran, onko mahdollista että ohjelmointiputkassa hieman jatkettaisiin funktio esimerkkejä. Eli näin teet funktion järkevästi, juuri nuo pointtisi boldattuna?
Asia ei ole niin, että oppaissa olisi väärää tietoa. Näissä asioissa ei ole yhtä oikeaa totuutta, vaan mielipiteitä on monenlaisia. Globaalit muuttujat ovat oman ohjelmointityylini kulmakiviä, ja niinpä niitä esiintyy myös oppaissa.
Globaaleilla muuttujilla ei ole mitään tekemistä sen kanssa, tuleeko sivustosta hyvä vai huono. Asiakasta ei voisi vähempää kiinnostaa, onko sivustossa käytetty globaaleja muuttujia vai ei, jos kaikki toimii.
Globaalit muuttujat eivät ole suorassa yhteydessä siihen, tykkääkö asiakas valmiista tuotteesta vai ei, mutta niillä on hyvin paljon vaikutusta siihen, miten vähän koodarit tykkäävät työskennellä kyseisen järjestelmän kanssa.
Mielestäni hieman heikko argumentti, että "asiakasta ei kiinnosta". Vastaavasti asiakasta ei kiinnosta sekään, onko sivustossa SQL Injektio-aukkoja, xss-haavoittuvuuksia tai voiko esimerkiksi verkkokaupassa jätää ostokset maksamatta ennen kuin ko. haavoittuvuuksia hyväksikäytetään.
Näistä voisi tietysti sanoa, että asiakasta pitäisi kiinnostaa nuo asiat, mutta samoin asiakasta pitäisi kiinnostaa myös, kuin hyvin ja kuinka suurilla kustannuksilla sivuja voi jatkokehittää. Tietenkin on aivan selvää että suurella osalla asiakkaista ei ole mitään kompetenssia arvioida mitään tässä mainituista asioista.
Antti Laaksonen kirjoitti:
latenleffahylly kirjoitti:
Putkan oppaassa oli tuon global funktion käyttöä, siitä mallinsin.
Asia ei ole niin, että oppaissa olisi väärää tietoa. – – Globaalit muuttujat ovat oman ohjelmointityylini kulmakiviä, ja niinpä niitä esiintyy myös oppaissa.
Kuitenkin funktion sisällä globaaleja muuttujia käytetään oppaassa ainoastaan siinä esimerkissä, jossa kerrotaan, että global-sana ylipäänsä on olemassa. Myöskään oppaassa ei erityisesti suositella global-sanan holtitonta käyttöä.
Toki tietyillä koodaustavoilla – kuten Antin tavalla – syntyy tilanteita, joissa globaalin muuttujan käyttö funktiossa säästää vähän aikaa ja vaivaa (kunhan ei samalla törttöile ja aiheuta vaikeaselkoisia bugeja). Silti myös Antti on varmaan samaa mieltä siitä, että SQL-kyselyn tuloksen palauttaminen ei ole yksi näistä tilanteista.
Alkemisti, olen ottanut zippisi talteen ja aion tutustua siihen tarkemmin kun osaamiseni/ ymmärrykseni paranee. Nyt nuo mallit ovat asteen verran liian hankalia. Katselin koko eilis illan videoita youtubesta, siellä näytettiin kädestä pitäen erilaisia funktioita.
// nyt lähden tällaisella funktiolla liikkeelle
function haeKaksiSaraketta($yhteys, $sar1, $sar2, $taulu) {
$kysely = $yhteys->prepare("SELECT " . $sar1 . "," . $sar2 . " FROM " . $taulu . "");
$kysely->execute();
return $kysely;
}Eli funktiolle lähetetään parametrit, ja funktio hakee niiden avulla tietoa kannasta. Ja palauttaa tuloksen. Tämä sitten tulostetaan alla.
$tulos = haeKaksiSaraketta($yhteys, "R_Id", "rNimi", "ryhma"); while ($rivi = $tulos->fetch()) { echo "" . htmlspecialchars($rivi["R_Id"]) . " " . htmlspecialchars($rivi["rNimi"]) . "<br>"; }
Huom! Mielestäni tässä on sinäänsä järkeä että näiden select boksejen kanssa tarvitaan useinmiten max. 2 saraketta. Tässä tapauksessa kannasta tulostetaan sarakkeet: "R_Id" ja "rNimi"
1 Ulkopuolinen
2 Järjestyksenvalvoja
3 Toimintaryhmä
4 Esimies
5 Turvapäälikkö
6 Ylläpitäjä
Tuossa funktiossa ei ole yhtään mitään järkeä. En myöskään sekuntiakaan epäile sanoa hevonpaskaksi väitettä, että esimerkissäni dmeottu tietokantayhteyden hakeminen olisi liian monimutkaista ymmärtää vaikkei olisi ikinä php:llä mitään koodannutkaan.
Tosin myönnän sen, että jossain mielessä on parempi antaa käytettävä kantayhteys parametrina kuin luottaa staattisiin funktioihin, mutta tässä tapauksessa sillä vain tekee tarkoituksellisesti omasta elämästään vaikeampaa. Ja tiedät sen itsekin.
HaeKaksiSaraketta on erittäin huono funktio, koska se kovakoodaa haettavien kenttien määrän kahteen, vaikkei tälle ole olemassa mitään järjellistä perustetta. Tuossa tilanteessa ei edes ole mitään järkeä lähteä erikseen määrittämään funktion parametreissa sitä, mitkä sarakkeet luetaan.
Mikset lue niitä kaikkia kerralla ja lopuksi tulosta vain tarvittuja tietoja?
Ja itse tykkäisin vielä enemmän, että tuolla funktiossa rakentaisit tuloksista jo taulukon, etkä palauttaisikaan sitä $kysely -muuttujaa.
Kiitos suorapuheisuudesta.
Sain käsityksen että on hyvä jakaa toistettavia asioita pienemmiksi osiksi-> funktioihin. Tässä tapauksessa tiedon haku ja tulostus olisi erillään? Tulostaminen ei ole aina saman näköistä, mutta tiedon haku olisi koska:
- funktiolle voisi syöttää minkä tahansa sarakkeen/ sarakkeiden nimet
- array ottaisi ne vastaan ja käsittelisi
---------------------
Yritän nyt lähettää testi.php tiedostossa kaksi parametriä funktion mukana-> funktiot.php tiedostoon. Siellä tiedot kaapataan arrayn sisään ja käydään läpi SELECT -lause.
Seuraava ongelma on palauttaako funktio arvot vai tulostetaanko arvot funktion sisällä. Mielestäni arvojen palauttaminen testi.php tiedostolle olisi järkevä ratkaisu. Näin voisin tulostaa selct-boksin, table, tai formin jne.
Lisäys:
Alkemisti, jos jaksat vastata? Onko tässä kohtaa niin että voi kutsua funktiota, joka minun omissa esimerkeissä korvaa muuttujan $yhteys
// tuo db() $smt = db()->prepare($sql);
Yritän nyt käydä läpi sinun esimerkkejäsi ja aloitan funktioista:
function db()
function get_pages()
latenleffahylly kirjoitti:
Seuraava ongelma on palauttaako funktio arvot vai tulostetaanko arvot funktion sisällä. Mielestäni arvojen palauttaminen testi.php tiedostolle olisi järkevä ratkaisu. Näin voisin tulostaa selct-boksin, table, tai formin jne.
Kuten sanoin itse ja kuten joku muukin on jo saattanut sanoa, niin sellaiset "komponentit", joita tarvitaan useissa eri paikoissa ja jotka ovat perusperiaatteiltaan helposti yleistettävissä, kannattaa aina eristää funktioihin. Tämä pätee niin tiedon käsittelyyn kuin myös esimerkiksi lomakkeen elementtien tulostamiseen.
Tätä myös demosin useammassakin kohdassa edellisessä navigaatioesimerkissäni.
Ja edelleenkin: jos koodia pilkotaan funktioihin, niin funktion täytyy olla itsenäinen kokonaisuus. Ei ole mitään järkeä tulostella pelkkiä <option>-elementtejä funktiossa, koska niitä ei voi yksinään käyttää. Ne vaativat aina <select>-elementin.
P.S. En kylläkään itse suosi ollenkaan funktioita, jotka tulostavat esim. html:ää. Käytän itse termiä "renderöidä", ja tarkoitan sillä että funktio voi generoida annetusta syötteestä sen html-vastineen, mutta tulostamisen sijaan se annetaan paluuarvona takaisin koodarille.
latenleffahylly kirjoitti:
Alkemisti, jos jaksat vastata? Onko tässä kohtaa niin että voi kutsua funktiota, joka minun omissa esimerkeissä korvaa muuttujan $yhteys
// tuo db() $smt = db()->prepare($sql);
Vastaan että lue koodia. Josset sen perusteella vielä ymmärrä tapahtumien kulkua, niin sitten tee pieniä esimerkkejä itsellesi, joilla selvität asioiden toiminnan.
Lebe80 kirjoitti:
Ja itse tykkäisin vielä enemmän, että tuolla funktiossa rakentaisit tuloksista jo taulukon, etkä palauttaisikaan sitä $kysely -muuttujaa.
Minulla katkesi ajatus ennen kuin pääsin tähän kohtaan.
The Alchemist kirjoitti:
Ja edelleenkin: jos koodia pilkotaan funktioihin, niin funktion täytyy olla itsenäinen kokonaisuus. Ei ole mitään järkeä tulostella pelkkiä <option>-elementtejä funktiossa, koska niitä ei voi yksinään käyttää. Ne vaativat aina <select>-elementin.
No tämä on kyllä vähän kaksipiippuinen juttu. Eihän <select>-elemnttiäkään voi käyttää yksinään, vaan se tarvii <form> elementin joka tarvii <body> elementin joka tarvii <html> elementin. Eli mikä nyt sitten on itsenäinen kokonaisuus?
Jos funktio vetää aina selectit optioneiden ympärille, niin sitten ei voi käyttää optgroupeja ollenkaan, kuten voisi pelkkiä optioneita puskevalla renderoijalla. Toki ainahan voi tehdä funktion joka osaa laittaa sekä optgroupeja että optioneita selectin sisään.
Kiitos A ja G. Olette molemmat pitkällä Ohjelmoinnissa, ja tästä johtuen teillä on jokin tapa/ tyyli miten toteutatte asioita.. Pointti? Minun pitäisi itse tajuta enemmän ja löytää itselle sopiva tapa.
Alkemisti on mielestäni siinä perus periaatteessa oikeassa että jos jokin koodikokonaisuus toistuu uudestaan ja uudestaan niin on loogista laittaa se funktion sisään ja koodikin lyhenee. Selectin laittaminen funktion sisään säästää jo yhden funktion kohdalla parhaassa tapauksessa 2 riviä koodia?
Grez kirjoitti:
The Alchemist kirjoitti:
Ja edelleenkin: jos koodia pilkotaan funktioihin, niin funktion täytyy olla itsenäinen kokonaisuus. Ei ole mitään järkeä tulostella pelkkiä <option>-elementtejä funktiossa, koska niitä ei voi yksinään käyttää. Ne vaativat aina <select>-elementin.
No tämä on kyllä vähän kaksipiippuinen juttu. Eihän <select>-elemnttiäkään voi käyttää yksinään, vaan se tarvii <form> elementin joka tarvii <body> elementin joka tarvii <html> elementin. Eli mikä nyt sitten on itsenäinen kokonaisuus?
Jos funktio vetää aina selectit optioneiden ympärille, niin sitten ei voi käyttää optgroupeja ollenkaan, kuten voisi pelkkiä optioneita puskevalla renderoijalla. Toki ainahan voi tehdä funktion joka osaa laittaa sekä optgroupeja että optioneita selectin sisään.
Hämärrät tahallasi tarkoitusperiäni.
Select ei missään nimessä vaatimalla vaadi yhtään mitään ympärilleen. Sen sijaan option ei ole itsenäinen elementti: se voi esiintyä ainoastaan select-elementin sisällä mahdollisesti vielä optgroup-ryhmissä. Tietysti, jos minulla olisi luokka, joka renderöi select-pudotusvalikoita, niin saattaisin hyvinkin lisätä siihen (privaatin) funktion, joka renderöi annetun joukon optioneita.
Pointtini oli, että on väärin (kyllä, väärin) tehdä pelkästään optioneita tulostava funktio ja jättää koodarille redundanttia työtä select-elementtien tulostamiseen.
Samalla tavalla on "väärin" jättää koodarille redundanttia työtä label-select-kombojen tulostamiseen, jos huomaa hyvin usein tekevänsä keskenään identtisiä label-select-pareja lomakkeille. Tällöin koodaisin ehdottomasti uuden funktion, joka tulostaa yhdellä kertaa labelin ja selectin. En kuitenkaan koodaisi tätä funktiota ns. tyhjältä pöydältä vaan hyödyntäisin tuota aiemmin tekemääni select-laatikoita tulostavaa funktiota.
Tällöin voin tulostaa yksinkertaisella tavalla kokonaisia kenttiä lomakkeelle, mutta mikäli se ei jossain tilanteessa olekaan riittävä ratkaisu, niin voin myös tulostaa labelin ja selectin erikseen ja muotoilla kenttää vapaammin.
Tällä tavalla saatetaan lopulta päätyä siihen tilanteeseen, että meillä on geneerinen funktio kaikkien yksittäisten kenttien tulostamiseksi lomakkeelle. Nyt herääkin kysymys, että onko mitään järkeä enää tulostella kenttiä yksitellen, vai voidaanko yleisen lomakemallin tulostus siirtää kokonaan funktioon...
function html_select($name, $options) {
// Epätarkka yksinkertaistus
return '<select>...</select>';
}
function html_label($text, $for = '') {
// Epätarkka yksinkertaistus
return '<label>...</label>';
}
function html_select_field($label, $name, $options) {
// Epätarkka yksinkertaistus
$html = '<div class="field">';
$html .= html_label($label);
$html .= html_select($name, $options);
$html .= '</div>';
return $html;
}latenleffahylly kirjoitti:
Kiitos A ja G. Olette molemmat pitkällä Ohjelmoinnissa, ja tästä johtuen teillä on jokin tapa/ tyyli miten toteutatte asioita.. Pointti? Minun pitäisi itse tajuta enemmän ja löytää itselle sopiva tapa.
Alkemisti on mielestäni siinä perus periaatteessa oikeassa että jos jokin koodikokonaisuus toistuu uudestaan ja uudestaan niin on loogista laittaa se funktion sisään ja koodikin lyhenee. Selectin laittaminen funktion sisään säästää jo yhden funktion kohdalla parhaassa tapauksessa 2 riviä koodia?
Hyötyä ei mitata suoranaisesti koodirivien määrässä. Eikä ainakaan yksittäisten rivien tarkkuudella vaan kymmenien tai satojen. On täysin merkityksetöntä, onko skriptisi pituus 20 vai 25 riviä, tai että onko se 250 vai 270 riviä.
Kun funktioita on käytetty oikein ja suurin piirtein kaikki funktioihin järkevästi eristettävissä oleva koodi on pilkottu funktioihin, niin sen osan koodista, jossa näitä funktioita käytetään, lukeminen on paljon mukavampaa ja helpompaa.
Myös virheiden paikantaminen on helpompaa, kun voit suurin piirtein sanoa, mitä mikäkin funktio tekee, joten samalla tiedät, missä funktiossa virhe voi sijaita ja missä se tuskin sijaitsee. Tällöin et joudu keskittymään tuhansien koodirivien tutkimiseen, vaan riittää että käyt huolellisesti läpi ne muutamat funktiot, joissa epäilet vian piilevän.
Toki olen samaa mieltä siitä, että usein toistuvia juttuja kannattaa toteuttaa funktioiksi.
Mutta jos projektissa X on vaikka yhden kerran select-tagi ja kolmet listat optioneja niin en ole sitä mieltä että olisi automaattisesti huonoa että se optionit tulostava ei tee niitä selectejäkin suoraan.
Minulle jäi hämäräksi miten tuota optiot generoivaa koodiasi on tarkoitus käyttää, jos se änkee aina optioiden ympärille select-tagit ja koodaaja tarvitsisikin optioryhmiä.
Toki voi aina tehdä funktion, joka tekee selectin ja osaa tehdä sen sisään sekä optioita että optiogroupeja joiden sisällä optioita. Kuitenkin jos vaikka saadaan kolmesta eri paikasta optioina näytettävää tietoa joista ensimmäinen menee ilman groupia ja kaksi seuraavaa omissa groupeissaan, niin onko näistä järkevää lähteä kasailemaan tietorakennetta jollekin funktiolle vai voisiko olla mahdollista renderoida nuo kolme peräkkäin selectin sisään.
Eikö noissa epätarkoissa yksinkertaistuksissasikin ole hirveästi kammoksumaasi redundanttia työtä, kun jokaisessa tehdään html-tagit "käsin".
Grez kirjoitti:
Mutta jos projektissa X on vaikka yhden kerran select-tagi ja kolmet listat optioneja niin en ole sitä mieltä että olisi automaattisesti huonoa että se optionit tulostava ei tee niitä selectejäkin suoraan.
Täsmensin jo edellisessä viestissäni, että kun tulostetaan täysin geneerisiä select-tageja käsin, niin silloin tehdään niin turhaa työtä, että on väärin olla tekemättä siihen toimintoon uutta funktiota. Jos funktiomme print_select() käyttää sisäisesti print_options-funktiota, niin sittenhän se on ihan siisti.
Grez kirjoitti:
Minulle jäi hämäräksi miten tuota optiot generoivaa koodiasi on tarkoitus käyttää, jos se änkee aina optioiden ympärille select-tagit ja koodaaja tarvitsisikin optioryhmiä.
Toki voi aina tehdä funktion, joka tekee selectin ja osaa tehdä sen sisään sekä optioita että optiogroupeja joiden sisällä optioita. Kuitenkin jos vaikka saadaan kolmesta eri paikasta optioina näytettävää tietoa joista ensimmäinen menee ilman groupia ja kaksi seuraavaa omissa groupeissaan, niin onko näistä järkevää lähteä kasailemaan tietorakennetta jollekin funktiolle vai voisiko olla mahdollista renderoida nuo kolme peräkkäin selectin sisään.
Itse en empisi hetkeäkään valita tuota tietorakenteeseen pohjautuvaa toimintamallia. En välttämättä yrittäisi päivittää html_select()-funktiotani tukemaan rinnakkaisesti kahta erilaista tietorakennetta, vaan tekisin ehkä toisenkin select-lootia tuottavan funktion.
Jos joku toinen haluaa tehdä eri tavalla, niin tehköön. Kunhan sen nyt tekee jossain mielessä järkevästi.
lainaus:
Eikö noissa epätarkoissa yksinkertaistuksissasikin ole hirveästi kammoksumaasi redundanttia työtä, kun jokaisessa tehdään html-tagit "käsin".
Et ilmeisesti huomannut kommentteja, joissa kerroin kyseen olevan epätarkoista yksinkertaistuksista. Siinä vaiheessa, kun laajennetaan lomakekirjastomme speksejä niin, että kaikilla kentillä pitää voida olla mm. id- ja class-attribuutit ja ties mitä kaikkea, niin pakkohan silloin on alkaa miettiä yksittäisten elementtien renderöinnin abstrahoimista.
Lyhyt kysymys? Miten saisin "SQL SELECT kyselyyn" arrayn mukaan?
// $sarake ---> "R_Id", "rNimi"
$kysely = yhteys()->prepare("SELECT" . $sarake . "FROM" . $taulu . "");latenleffahylly kirjoitti:
Lyhyt kysymys? Miten saisin "SQL SELECT kyselyyn" arrayn mukaan?
Miksi?
Noniin.. Antaa sitten olla. Yritän keksiä miten saisin välitettyä funtiolle sarakkeiden nimet viisaimmailla tavalla.
SQL-kyselyyn ei voi laittaa arrayta, mutta arrayn voi muuttaa sopivaksi merkkijonoksi implodella.
$kysely = yhteys()->prepare("SELECT " . implode(", ", $sarakkeet) . " FROM " . $taulu);Mikäli sarakkeiden nimet tulevat käyttäjältä, muista escapoida ne, ettei synny SQL-injektioaukkoa.
Late: usko jo nyt jumalauta. Älä tuhlaa aikaasi täysin hyödyttömään mikro-optimointiin, joka kaiken lisäksi tekee koodistasi bloattia, vaan keskity olennaiseen.
Hae kyselyssä KAIKKI taulun sarakkeet. Näin sinulla on yleiskäyttöinen funktio, jota ei ole rajattu vain yhteen käyttötarkoitukseen. Lisäksi helpotat koodin uudelleenkäytettävyyttä siten, että tulet vähentäneeksi redundantteja sidoksia tiettyyn tietorakenteeseen (taulukon indekseihin, jotka kuvaavat jonkin entiteetin ominaisuuksia).
Turhien sarakkeiden lukeminen on todennäköisesti suorituskyvyn kannalta täysin merkityksetöntä.
P.S. Tietysti jos olet kyhäämässä jotain vieläkin geneerisempää funktiota, jota muut tietoja lukevat funktiot kutsuvat, niin sittenhän se on ihan hyvä. Veikkaan vaan ettei näin ole.
Kiitos molemmille. Hyviä pointteja. Alkemistille sellaisia terveisiä että jossain vaiheessa olin jo tekemässä funktiota jolla haen kaiken tiedon taulusta..
Niin ja miten kävikään?? Kerrottiin että et kai vaan hae kaikkea tietoa kerralla. Fiksumpaa hakea sarakkeiden mukaan tai jotain. Mutta, mutta sovellan nyt sitten tuota alkemistin neuvoa. Tossulle sen verran että jos järjestelmä suuri ja tauluissa valtavasti tietoa niin sillä mennään, kiitän!
Eipä täällä ole kukaan tuollaista sanonut. Ja jos perusteluita ei ole, niin silloin väittämä on merkityksetön. Jos perustelut on annettu, niin voit verrata eri perusteita keskenään ja siltä pohjalta päättää oman ratkaisutapasi.
Ja kuten sanoin edellisessäkin viestissä, niin sarakkeiden ja taulun määrittäminen voi olla (joskus) vieläkin geneerisempi funktio taulukohtaisten funktioiden "alla", jota nämä taulukohtaiset funkkarit kutsuvat. Mutta muussa käytössä näin pitkälle yleistetty funktio on tyhmä, koska se luo liikaa turhia riippuvuuksia koodiin (ja väärin paikkoihin) ja sitä kautta pilaa kaiken.
Huomenta! Eli olen nyt lukenut tätä topiccia usean nukutun yön jälkeen. Ensin haluan esittää pahoitteluni että en ole ymmärtänyt asioita. Nyt luulen että olen ymmärtänyt.
FUNKTIOT:
- kutsutaan funktioita:
<!--valitse tapahtumalle kuva-->
<?php haeKaikki("kuva", "kLyhenne"); ?>
<!--valitse jv tarve-->
<?php valintalista("jvTarve", "Järjestyksenvalvoja", 1, 50); ?>- funktiot.php
function haeKaikki($taulu, $sarake) {
$kysely = yhteys()->prepare("SELECT * FROM " . $taulu . "");
$kysely->execute();
echo "<label class='styledLabel' for='" . $sarake . "'>" . $taulu . ":</label>
<div class='styledSelect2'>
<select name='" . htmlspecialchars($rivi[0]) . "'>";
while ($rivi = $kysely->fetch()) {
echo "<option value='" . htmlspecialchars($rivi[0]) . "'>" . htmlspecialchars($rivi[1]) . "";
}
echo "</select></div>";
}
// HUOM! tuo yhteys() hakee PDO tietoja toisesta funktiosta...
function valintalista($nimi, $otsikko, $num1, $num2) {
echo "<label class='styledLabel' for='" . $nimi . "'>" . $otsikko . ":</label>
<div class='styledSelect3'>
<select name='" . $nimi . "'>";
for ($valinta = $num1; $valinta <= $num2; $valinta++) {
echo "<option value='" . $valinta . "'>" . $valinta;
}
echo "</select></div>";
}Mielestäni nämä 2 funktiota ovat hyviä koska:
+ koodi yksinkertaistuu
+ yksi kokonaisuus on yhdessä funktiossa
+ funktioita on suht helppo kutsua
----------------------------------------------------
Toivon että ette hauku. Vaan jos tämäkin tapa aivan päin seiniä niin huoh.. sitten antaa olla. Mielestäni funktiot ovat ihan ok ja hyvin yksinkertaisia, mutta tästä on hyvä jatkaa seuraavalle tasolle, paljon haastavimpien asioiden joukkoon. Erityiskiitos Alkemistille, jonka kirjoituksia olen pyrkinyt tajuamaan, sekä toki kaikille muille jotka ovat auttaneet. Luulen että alan pikku hiljaa tajuta funktioiden perusideaa.
Mun mielestä silti "haeKaikki" ei kuvaa tota funktion toimintaa, eli sen toiminto (eli funktio) on rakentaa alasvetolistaa tietokannasta. Eli yhtälailla kuin muuttujien nimet pitää olla kuvaavia, niin myös funktioiden. HaeKaikki ei todellakaan hae kaikkea, vaan se tekee vain ja ainoastaan tuon yhden pienen jutun.
Ja mä tekisin oman funktion tuolle alasvetovalikolle, niitä sulla on jo selkeästi kaksi, eli sulla on monistettua koodia sun koodissasi, mikä selkeästi on jo syy tehdä oma funktio.
Alasvetovalikko-funktion parametreinä voisi olla esim. valikon nimi, taulukko arvoista sekä vaikka valittu arvo.
Alasvetovalikko omana funktionaan mahdollistaisi myös sen, että voit käyttää sitä ihan ilman tietokantaakin, jos vaikka alasvetovalikon arvot kasataankin jossain muualla. Itse en muutenkaan tunkisi tuota alasvetovalikon tulostamista tuonne "haeKaikki" -funktioon, vaan tiedot tietokannasta hakisin nekin omassa funktiossa.
Kun sulla on taulukossa hash-arrayna esim. rivin arvo ja näytettävä teksti, niin taulukon sisältö on looginen ihan ulkopuolisellekin.
En käsitä edelleenkään sun $num1 ja $num2 logiikkaasi. Näyttää just niin räjähdysherkältä koodilta, etten viitsi edes katsoa mistä niiden arvojen pitäisi tulla.
UUSI YRITYS, Tässä nyt 3 funtiota:
- yhteys
- haeKaikkiTieto
- tulostaValintalista
<label class='styledLabel' for="tKuva">Kuva:</label>
<?php
// kutsutaan funktiota
$kysely = haeKaikkiTieto("kuva"); // valitse taulu
tulostaValintalista("tKuva", $kysely, "K_Id", "kNimi"); // valitse 2 saraketta
?>funktiot.php
<?php
// 1.)
function yhteys() {
static $yhteys;
if (!$yhteys) {
try {
$yhteys = new PDO("mysql:host=localhost;dbname=testi", "lauri", "123");
} catch (PDOException $error) {
die("VIRHE: " . $error->getMessage());
}
$yhteys->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$yhteys->exec("SET NAMES utf8");
}
return $yhteys;
}
// 2.)
function haeKaikkiTieto($taulu) {
$kysely = yhteys()->prepare("SELECT * FROM " . $taulu . "");
$kysely->setFetchMode(PDO::FETCH_OBJ);
$kysely->execute();
return $kysely;
}
// 3.)
function tulostaValintalista($sar0, $kysely, $sar1, $sar2) {
echo "<div class='styledSelect2'><select name='" . $sar0 . "'>";
foreach($kysely->fetchAll() as $solu) {
echo "<option value='" . $solu->$sar1 . "'>" . $solu->$sar2;
}
echo "</select></div>";
}
?>Kaikki ylläoleva toimii. Jos jaksatte kertoa, olenko nyt hieman lähempänä järkevämpää funktio rakennetta?
1.) yhteys
2.) kysely ja sen palauttaminen
3.) kyselyn hyödyntäminen tiedon tulostamisessa
Edelleenkään mä en palauttaisi tuota $kysely -oliota, vaan tekisin siitä tuloksesta aina taulukon.
Lebe, mielellään tekisin niinkuin sanot, mutta en ymmärrä mitä tarkoitat. Eli pitäisikö nyt tämän jälkeen-> $kysely->execute();
..tulostaa funktion sisällä? Mitä tarkoitat taulukolla?
No tulostuksen sijaan sijoitat ne arvot taulukkoon, esim. ihan riveittäin.
Ja taulukolla tarkoitan ihan taulukkomuuttujaa (array).
edit:
Ja taulukon ideana olisi tietenkin se, ettei listauksissa tarvisi aina olla tietokannasta haettua dataa, vaan voisi käsitellä ihan vaikka kovakoodatuista tauluista ihan vaikka käyttäjien syötteen kautta tulleita taulukoita.
Kutsutaan funktiota ja tulostetaan sisältö:
<?php
$rivit = haeKaikkiTieto("ryhma");
print_r($rivit);
/*
Array ( [0] => stdClass Object ( [R_Id] => 1 [rNimi] => Ulkopuolinen [rKuva] => ulkopuolinen.png [rLyhenne] => up ) [1] => stdClass Object ( [R_Id] => 2 [rNimi] => Järjestyksenvalvoja [rKuva] => jarjestyksenvalvoja.png [rLyhenne] => jv ) [2] => stdClass Object ( [R_Id] => 3 [rNimi] => Toimintaryhmä [rKuva] => toimintaryhma.png [rLyhenne] => tr ) [3] => stdClass Object ( [R_Id] => 4 [rNimi] => Esimies [rKuva] => esimies.png [rLyhenne] => em ) [4] => stdClass Object ( [R_Id] => 5 [rNimi] => Turvapäälikkö [rKuva] => turvapaalikko.png [rLyhenne] => tp ) [5] => stdClass Object ( [R_Id] => 6 [rNimi] => Ylläpitäjä [rKuva] => yllapitaja.png [rLyhenne] => yp ) )
*/
?>Funktio.php
function haeKaikkiTieto($taulu) {
$kysely = yhteys()->prepare("SELECT * FROM " . $taulu . "");
$kysely->setFetchMode(PDO::FETCH_OBJ);
$kysely->execute();
$rivit = $kysely->fetchAll();
return $rivit;
}- Eli mielestäni funktio palauttaa Arrayn ihan jo automaattisesti. Sittenhän arrayn tietoa voidaan käyttää? Mutta eikö valintalistan tulostamisessa tarvita taas uutta funktiota joka luo listan?
Sivuhuomiona voisin sanoa, että sinun kannattaisi tutustua johonkin Model-view-controller (MVC) pohjaiseen ohjelmistokehykseen. Saattaisi olla hyödyllisempää keskittyä ohjelmiston itsensä rakentamiseen eikä pyörän uudelleen keksimiseen: tapoja liikutella dataa tietokannan, ohjelmarakenteiden ja käyttöliittymän välillä on miettinyt moni muukin.
MVC toki on vain yksi malli, mutta sen suosio näyttää lisääntyneen webbikehityksessa. Siihen pohjaavia ohjelmistokehyksiä on monia, esimerkkinä vaikka CodeIgniter tai Zend Framework.
Kiitos vinkistä "M" ...tutkin asian, sanon vain että minua pyydettiin laittamaan tietokannan sisältö arrayhin, nyt kun se on siellä, niin eikö se sitten taas lähetetä uuteen funktioon?
Tämän projektin kohdalla, systeemi toimii, mutta osien muuttaminen funktioihin on hankalaa. Aion kuitenkin oppia funktiot, vaikka myöhemmin siirryn WP:n pariin joka tapauksessa.
Funktioita kuuluu käyttää toistuvien asioiden hoitamiseen, jottei samaa koodia tarvitsisi kirjoittaa moneen kertaan. Koko ohjelman sisällön ei kuulu olla funktioiden sisällä.
Ei ole järkevää tehdä funktiota jakolaskua varten, eikä ole järkevää tehdä funktiota jokaista kyselyä kohti.
Vertaa
function divide($number1, $number2) { return $number1 / $number2; }ja
function connectDB(...) { ... }Tietokantayhteys avataan monessa paikassa, joten se kannattaa toteuttaa funktiona. Vaikka jakolaskuakin tarvittaisiin useasti, niin sen toteuttaminen on paljon yksinkertaisempaa /-operaattorilla.
Okei, tiedän että yritätte auttaa, mutta sain käsityksen että yhden funktion sisällä voisi tehdä näin:
- annetaan taulun nimi, kun kutsutaan funktiota
- haetaan kaikki tieto taulusta
- tallennetaan taulun tiedot muuttujaan ja palautetaan se
Näin ollen tämä $muuttuja voidaan hyödyntää jatkossa, jos se ensin laitetaan osiin. Esim. $sar1 sisältäisi:
1
2
3
4
5
$sar2 sisältäisi
jv
tr
em
up
yp
Lisäys: - Muuten olenko tekemässä funktion jokaista kyselyä kohti? Mielestäni voin päättää mistä taulusta kaikki tiedot haetaan. Tämä tieto pitää saada johonkin talteen jotta voin lähettää sitä funktioihin joka esim. tulostaa SELECT elementin (valintalista)
Lisäys:
Tässä se mitä palautuu funktion jälkeen:
$rivit = haeKaikkiTieto("ryhma");
print_r($rivit);
Array (
[0] => stdClass Object (
[R_Id] => 1
[rNimi] => Ulkopuolinen
[rKuva] => ulkopuolinen.png
[rLyhenne] => up
)
...
)---------------------------------------------
Sen verran vielä, että toiveeni olisi että voisin tehdä edes yhden funktion oikein. Eli en halua oppia väärää tapaa. Nähtävästi tuo esittämäni tapa on väärä.. Voiko joku kertoa onko tuollainen array huono?
---------------------------------
Noniin kiitos harhaanjohtamisesta, pääsimpäs näyttämään osaamiseni =)
Tavallisesti dataa kulkee kahteen suuntaan: tietokannasta käyttöliittymään ja toisinpäin. Tällöin on olioiden käytössä joitakin etuja taulukkoihin verrattuna.
Olkoon tämä esimerkki nyt samalla lyhyt johdatus MVC-mallin model-osalle.
/**
* Oletetaan tietokantataulu "Record", josta löytyvät kentät
* "id" ja "information".
*/
class Model_Record {
// Vastineet tietokantataulun kentille
private $id;
private $information;
public function setId($id) {
// Datan validointi olion set-metodeissa tekee asiat helpoiksi
if (!is_int($id)) {
throw new Exception('Muuttuja id ei ollut luku!');
} else {
$this->id = $id;
}
}
public function getId() {
return $this->id;
}
public function setInformation($information) {
if (strlen($information) > 1000) {
throw new Exception('Liikaa tietoa (max. pituus 1000 merkkiä)');
} else {
$this->information = $information;
}
}
public function getInformation() {
return $this->information;
}
// Kirjoittaa luokan kenttien "id" ja "information" arvot tietokantaan
public function insert() {
$sql = "INSERT INTO Record (Information) VALUES (?)";
$info = $this->getInformation();
if ($info == null) {
$throw new Exception("Ei tallennettavaa tietoa!");
}
// Kuvitteellinen db luokka, jonka exec metodi
// ottaa vastaan sql-kyselyn ja siihen liiskattavat
// parametrit taulukkona
$result = $db->exec($sql, array($info));
// tarkista onnistuiko insert ym.
}
// Hakee tiedon "information" annetun id:n perusteella
public function select() {
// täytä luokan kentät haetulla tiedolla
}
}Tällainen "malli" kun nyt on olemassa, niin aina kun ilmaantuu tarve käyttää kyseistä record-taulua, ohjelmakoodi noudattelee seuraavanlaista kaavaa:
// Tiedon viennin osalta esim:
Model_Record $rm = new Model_Record();
try {
// $blaa tulee nyt vaikka sieltä käyttöliittymästä
$rm->setInformation($blaa);
$rm->insert();
} catch (Exception $e) {
// Ja nyt siellä käyttöliittymässä sitten näkyisi virheviesti,
// jos tänne jouduttiin.
// Kannattaa harkita ainakin muutamaa erilaista exception-luokkaa,
// koska osa virheistä johtuu käyttäjästä (virheellinen syöte) ja
// osa jostain muusta, kuten tietokantaan yhdistysvirheistä tms.
}
// kaikki hyvinKoodi kirjoitettu parissa minuutissa ja sisältää todennäköisesti joitakin virheitä. Perusidea siitä toivottavasti kuitenkin välittyy. MVC-mallin model-osa siis on luokka, joka operoi tietokannan kanssa. Vaikka et suoraan MVC-malliin siirtyisikään, niin pelkästään kuvatun kaltaisten luokkien kirjoittelu tekee asiat kohtuullisen helpoiksi ja erottaa tietokannan käsittelyn selkeäksi omaksi osakseen. MVC-mallikaan ei ole täysin aukoton ja se voidaan toteuttaa useammalla hieman erilaisella tavalla. Suosittelen lukemaan jonkin kunnollisen oppaan, niitä on internet pullollaan.
EDIT: Tosiaan, ne taulukot. Uskoisin että osaat itsekin sanoa mitä etuja tällä oliolähestymistavalla saadaan. Yllä olevasta aika pitkälle käy ilmi koko olio-ohjelmoinnin perusidea: laitetaan tieto ja sen käsittely yhteen pakettiin.
Tuota, tuota.. selkeästi hallitset HC-koodauksen. Unohdat kuitenkin sen että itse tein ensimmäisen huonon funktion pari viikkoa sitten. Tänään luulin tehneeni ensimmäisen funktion jossa olisi kunnolla järkeä.
Tuo tapasi on varmasti järkevä, hyvä jne. mutta minulle se ei vielä aukea. Siksi kysyin apua.. tajuan viimein että te KAIKKI yritätte sanoa rivien välistä: "luovuta jo, et koskaan opi koodaamaan PHP:tä"
..eli vaikka funktioni on täysin toimiva, niin se on jotenkin todella typerällä tavalla tehty ja siksi se tarkoittaa että en ymmärrä koodauksesta mitään??
<?php
function haeKaikkiTieto($taulu) {
$kysely = yhteys()->prepare("SELECT * FROM " . $taulu . "");
$kysely->setFetchMode(PDO::FETCH_OBJ);
$kysely->execute();
$rivit = $kysely->fetchAll();
return $rivit;
}
// tulostaa...
/**
* $rivit = haeKaikkiTieto("ryhma");
* print_r($rivit);
*
* Array (
*
* [0] => stdClass Object (
*
* [R_Id] => 1
* [rNimi] => Ulkopuolinen
* [rKuva] => ulkopuolinen.png
* [rLyhenne] => up
*
* )
*
* ...
*
* )
*/
?>- yllä oleva koodi hakee kaiken tiedon halutusta taulusta. Palauttaa tiedot arrayn sisällä, jossa tiedot ovat objektejen sisällä, mutta taas väärin??
latenleffahylly kirjoitti:
function haeKaikkiTieto($taulu) { $kysely = yhteys()->prepare("SELECT * FROM " . $taulu . ""); $kysely->setFetchMode(PDO::FETCH_OBJ); $kysely->execute(); $rivit = $kysely->fetchAll(); return $rivit; }(1) Eli mielestäni funktio palauttaa Arrayn ihan jo automaattisesti. Sittenhän arrayn tietoa voidaan käyttää? (2) Mutta eikö valintalistan tulostamisessa tarvita taas uutta funktiota joka luo listan?
1. Funktioiden palautusarvot eivät ole mielipidekysymys. Tulosta palautettu arvo ja katso, mitä dataa olet saanut. Älä arvaile.
2. Miksi joudut vieläkin kysymään asioita, joihin sinulle on vastattu lukuisia kertoja ihan muutamia päiviä sitten? Itsekin annoin jopa käytännön esimerkin aiheesta. Jos sinun tarvitsee jatkuvasti iteroida samojen asioiden päällisiä, niin toista mieluummin vastausten lukemista kuin kysymyksen esittämistä.
Alkemisti kirjoitti:
1. Funktioiden palautusarvot eivät ole mielipidekysymys. Tulosta palautettu arvo ja katso, mitä dataa olet saanut. Älä arvaile.
Enkö juurikin kertonut että palautin Arrayn? (eli taulukon)..
// tulostaa...
/**
* $rivit = haeKaikkiTieto("ryhma");
* print_r($rivit);
*
* Array (....Kysyin onko se hyvä että arrayn sisällä on objekteja. No en tarvi vastausta koska tiedän että esittämäni tapa on oikein hyvä. Luulen että alan karistamaan Noviisin mainettani ja tämä on kova paikka joillekkin. Yritän parantaa jatkossa ulosantia.
Loppuviimein yksi hailee, käyttääkö perustietotyyppinä taulukkoa vai stdClass-oliota, ne kun ovat käytännössä keskenään vaihdannaisia. Ennemmin käyttäisin "kotitekoisia" luokkia, jolloin niiden sisältämät muuttujat ja metodit olisivat helpommin pääteltävissä. Tämä myös siksi, etteivät taulukot tai stdClass-oliot voi periaatteessa käsittää metodeita, joten triviaaleja asioita joutuu tekemään vaikeamman kautta.
(Esimerkiksi ihmisen koko nimen muodostaminen, jos oliolla on vain jäsenet firstName ja lastName.)
Mielenkiintoista. Voitko "A" arvioida pitäisikö minun tehdä lisää fiksumpia funktioita, opetella jotain ihan perusteita vai tutkia luokkia ja olioita? Juttu on se että aion jokatapauksessa päästä php:ssä tietylle tasolle.
Tulevaisuudessa voin tehdä Wordpressin avulla paljon asioita kun hallitsen php:tä.
Pahoittelut, en osannut arvioida kuinka pitkällä ohjelmoinnin opettelussa olet, kun en jaksanut lukea kuin muutaman viimeisimmän viestin.
Ohjelmointia oppii ohjelmoimalla, ei kannata luovuttaa. Olethan jo kuitenkin selvästi ensimmäisen suurimman osan ohittanut, joka on ohjelmakoodin syntaksin kanssa taistelu. Nyt sitten ne perusrakenteet ja pikkuhiljaa siitä eteenpäin.
Työvuoron varausohjelma voi toki olla hieman iso pala jos on vasta alkeissa menossa. Kun se valmistuu osaat todennäköisesti jo ohjelmointia sen verran paremmin, että se kannattaa kirjoittaa alusta saakka uudelleen.
Lisäys: PS. Ideaalisesti yksi funktio (tai metodi jos olioista puhutaan) tekee yhden asian. starttaaAuto(); yhdistaTietokantaan(); vedaVessa(); jne :-)
No minusta sinulla on liian pahasti hakusessa ohjelmoinnin filosofia. Siis yleispiirteinen käsitys siitä, miten koodi pitäisi palastella esimerkiksi funktioihin ja miten niitä pitäisi käyttää.
Mitään yhtä ja ainoaa ratkaisua ei tietenkään ole olemassa, mutta valitsemasi vaihtoehdot ovat yksiselitteisesti melko huonoja. Vaan kun asiat eivät tule selviksi edes suorien käytännön esimerkkien kautta, niin sitten ei ehkä kannata jäädä arpomaan näennäisesti yksinkertaisten asioiden päällisiä viikkokausiksi. Toivokaamme, että joskus tämä valaistuminen tapahtuu muiden asioiden ja kokemuksen kautta.
Tästä syystä ehdotin sitä WP:n opettelua jo aiemmin: tällöin tulet tutustuneeksi siihen, miten koodia pitää* aikuisten oikeasti kirjoittaa. On täysin irrelevanttia, miten hyvin osaat php:n standardikirjaston ulkoa, koska ne funktiot ovat suurimmaksi osaksi sekavia ja vailla mitään logiikkaa. Esimerkiksi Zend Frameworkin kanssa on lähdetty siitä, että monet php:n valmiiksi sisältämätkin funktiot on korvattu uusilla luokilla, joita tulisi käyttää standardikirjaston toimintojen sijaan. (Toki tämä luokat voivat käyttää ko. funktioita pellin alla.)
Samalla tavoin itse en käytä php:n superglobaaleita ($_GET, $_POST, ...) koodissani vaan olen koodannut eri tavan käsitellä http-pyynnön mukana välitettyjä parametreja. Edelleen nämä viritelmäni käyttävät pellin alla kyseisiä muuttujia, mutta täsmälleen yhdessä kohdassa, jonka jälkeen ne tuhotaan unset():lla. Näin ovat Zendin kehittäjätkin tehneet.
* En ole tutustunut WordPressin kirjastoihin, joten en voi vannoa, että suosittelisin sitä alustana itse, mutta oletan sen olevan varsin mukiinmenevä ympäristö.
Suurkiitokset molemmille ("M" & "A"). Ymmärrän alkemistin turhautumisen, mutta on todettava että aloin opetella funktioita noin kuukausi sitten. Sanon vain tuosta ensimmäisestä oikeasta funktiostani (haeKaikkiTieto) ..sen että siinä tapauksessa on hyvä hakea kaikki tieto.
Tätä funktiota voidaan nopeasti laajentaa hakemaan taulujen sarakkeiden tietoja, oletan. Mutta, mutta WP:stä minulla on kokemusta. Omat websivuni.
Toinen asia kun sanot että en opi edes esimerkeistäsi, niin haluan edetä askel kerrallaan ja huom! minusta ei tule koskaan huippu php-koodaria koska aivoni ovat eri maata. Värit, käyttöliittymät, ulkoasu, suunnittelu, dokumentointi, kuvankäsittely, valokuvaus (css3,html5,responsive design)... jne. tälläiset asiat tulevat geeneistä. Painotan kuitenkin että haluan oppia PHP:tä jotta pystyn ymmärtämään WP:tä. Huom! WP:n sisään olen aikaisemminkin laittanut omaa koodia.
Tavoite: "Ohjelmointia oppii ohjelmoimalla, ei kannata luovuttaa."
Taso: "osaan koodata Tapahtumapalvelun käyttäen olio-ohjelmointia"
aika: 1-2 vuotta
Tutkitaan-> "Nyt sitten ne perusrakenteet ja pikkuhiljaa siitä eteenpäin."
Totta mutta myös tarua-> "Työvuoron varausohjelma voi toki olla hieman iso pala jos on vasta alkeissa menossa."
Ensimmäinen versio 1 on jo käytössä. Tuotolla hankin (iPad 3gen. 16GB, Wi-Fi)
Kiitos paljon-> "Ideaalisesti yksi funktio tekee yhden asian." .....huom! tällaisia neuvoja Alkemistin tasoinen koodari ei pysty antamaan, koska ei tajua että tasoni on edelleen: Noviisi, eli pitää rautalangasta vääntää.
Esimerkki neuvosta jota en täysin ymmärrä-> "No minusta sinulla on liian pahasti hakusessa ohjelmoinnin filosofia."
Kiitos-> " valitsemasi vaihtoehdot ovat yksiselitteisesti melko huonoja"
???-> "Esimerkiksi Zend Frameworkin kanssa on lähdetty siitä, että monet php:n valmiiksi sisältämätkin funktiot on korvattu uusilla luokilla..."
Eikö luokista ollut juuri puhe kun kysyin kannattaako minun
A.) keskittyä perusteisiin
B.) harjoitella funktioita lisää ja lisää
C.) tutkia luokkia ja olioita
Korkean tason koodarin puhetta kirjoitti:
Samalla tavoin itse en käytä php:n superglobaaleita ($_GET, $_POST, ...) koodissani vaan olen koodannut eri tavan käsitellä http-pyynnön mukana välitettyjä parametreja. Edelleen nämä viritelmäni käyttävät pellin alla kyseisiä muuttujia, mutta täsmälleen yhdessä kohdassa, jonka jälkeen ne tuhotaan unset():lla.
..huoh, kiitän.. että sellaista tänään.
Moni meistä on sanonut jo aiemmin, että funktioiden pitäisi olla ns. atomisia eli tehdä mahdollisimman vähän. Tätä väittämää pitäisi vielä tarkentaa siten, että funktion toteutuksen eli sen sisältämän koodin pitäisi olla melko lyhyt pituudeltaan.
Sanoin itse myös sen, ettei näiden yleiskäyttöisten funktioiden käyttö suoraan ole kuitenkaan aina järkevää: joskus on parempi kirjoittaa funktio, joka tekee vähän enemmän / useampia asioita, mutta sen toteutuksen tulisi kuitenkin käyttää näitä yleiskäyttöisempiä funktioita. Toisin sanoen on ihan ok välillä tehdä myös funktioita, jotka eivät ole niin yleiskäyttöisiä.
Väärien vaihtoehtojen valitsemisella viittasin taannoiseen ja läpikotaisin puituun select-laatikon tulostamiseen. Monet meistä kertoivat sinulle, että olisi järkevää tehdä funktio, jolle annetaan lista tulostettavista arvoista muodossa "arvo => seliteteksti". Minä annoin jopa käytännön koodiesimerkin.
Silti päädyit tuohon kyseenalaiseen toteutukseen, jossa annatkin selkeän listan sijaan satunnaisen taulukollisen dataa ja kaksi satunnaista indeksiä, joita käyttämällä saat jotenkin taiottua kasaan pudotusvalikon. No miksi sellainen toteutus on huono?
1. On täysin selvää, että joskus haluatkin käyttää tekstinä jotain dataa, mitä ei taulukossa ole valmiiksi, vaan se pitää muodostaa esim. kahden eri sarakkeen arvoista.
2. Funktion rajapinta oli sekava: tarvittavat parametrit olivat aikalailla tuulesta temmattuja ilman mitään perusteita -> koodarin on vaikea oppia funktion käyttö ulkoa, koska loogisesti ajatellen parametrien pitäisi olla ihan jotain muuta. Ja jos kaikki samantapaiset funktiot tehtäisiin käyttämään yhtä sekavia rajapintoja, niin ne olisivat luultavasti kaikki keskenään hyvin erilaisia -> sisäistämisen vaikeus kasvaa potensseissa.
Kohdalla 2 tarkoitan nyt sitä, että selkeästi loogisin vaihtoehto pudotusvalikon tulostavalle funktiolle olisi antaa kolmen parametrin (taulukko, arvon indeksi, selitetekstin indeksi) sijaan YKSI parametri (taulukko muodossa arvo => seliteteksti). Nyt funktion rajapinta on myös loogisesti yhteneväinen monien muiden vastaavien funktioiden kanssa.
Esimerkiksi jos haluat tulostaa listan asioista (vaikka eläimistä tai ihmisistä), niin voit tehdä funktion print_list($items) sen sijaan että tekisit esimerkiksi funktion print_list($data, $value_key). Tai jotain muuta yhtä arvoituksellista. Kyse on siis lähinnä redundanttien parametrien eliminoimisesta.
Tutkin tänään kirjoituksesi. Vkl aikana teen paremman funktion (select). Sanon kuitenkin vielä sadannen kerran sen että ohjelmoinnissa syvällä olevien ihmisten on lähes mahdoton asettua Noviisin asemaan.
Osa kertomastasi ei aukea minulle välttämättä koskaan. Koska sanamuodot ja käsitteet ovat ylemmän tason ohjelmointia. Olisi muutenkin mukava jos "A" voisi yhden tunnin ajan tutustua Wordpressiin ja kertoa mitä mieltä hän on esim. Wordpress Templaten: "Responsive" -rakenteesta (lähdekoodi).
Tarkoitan tällä sitä että se on sinulle uutta, oletan. Nämä funktiot ovat minulle uutta, arrayt vaikeita ja koodirakenteen hahmottaminen mahdotonta. Nyt kuitenkin kauppaan, tuoretta leipää ja kahvia...
latenleffahylly kirjoitti:
Sanon kuitenkin vielä sadannen kerran sen että ohjelmoinnissa syvällä olevien ihmisten on lähes mahdoton asettua Noviisin asemaan.
Tuota logiikkaa en ymmärrä yhtään. Jokainen kokenut ohjelmoija on ollut joskus noviisi. He ovat selvinneet tuon vaiheen yli osaajaksi. Heillä on siten kokemusta siitä, miten tuo prosessi tapahtuu ja voivat antaa vinkkejä siitä, miten asioita kannattaa hahmottaa.
latenleffahylly kirjoitti:
Tutkin tänään kirjoituksesi. Vkl aikana teen paremman funktion (select).
Miksi? Mitä se auttaa? Vaikkei tämä olekaan mikään taivaasta pudonnut universaali totuus, niin olen monesti sanonut, ettei alkeisiin pidä takertua ja jäädä iteroimaan pikkuasioiden päällisiä. Olen antanut sinulle toimivan esimerkkiratkaisun, joka hakkaa kaikki tähänastiset yritelmäsi, joten sen kuin kopioit sen ja lähdet siitä jalostamaan laajempaa versiota, jos laajempaa toiminnallisuutta tarvitset.
Joka tapauksessa kaikki tuon select-laatikon tulostamiseen käyttämäsi tunnit, päivät ja viikot ovat kaikki hukkaanheitettyä aikaa: WordPressissä on jo omat työkalunsa lomake-elementtien ja kokonaisten lomakkeiden hallitsemiseen.
$sql = '
SELECT
a.id,
a.url,
a.parent_id,
a.name,
a.content
FROM pages a
ORDER BY a.name
';Voisiko yllä olevan kohdalla olla tällainen taulu:
Sivut
sId ---> 1
sUrl ---> http://localhost/tapahtumapalvelu/index.php?sivu=etusivu
sRyhmaId --->1
sNimi ---> etusivu
sSisalto ---> ?
Tuleeko tietokannassa esim. sisältö kohtaan tekstiä tai jokin html-rakenne, jonka sisällä teksti ja kuvalinkit ovat? Ajattelin laittaa omat sivuni tietokantaan. Nyt ne ovat index.php -tiedostossa näin:
// sisältö sivut $sivut = array( 'testi' => 'testi.php', 'etusivu' => 'etusivu.php' );
Ainakaan sivun urlia ei kannata tallentaa kantaan eikä varsinkaan protokollamäärittelystä ja domainista alkaen. Osoitteen voi muodostaa ajonaikaisesti linkkiä luotaessa ja samoin http-pyynnön osoitteesta voi päätellä haettavan sivun tunnisteen.
Sisältöäkään en tallentaisi yhtenä könttänä vaan tekisin sen niin, että yhdelle sivulle voi lisätä monta "klippiä", jotka voivat olla tietotyypiltään vaikkapa rikastekstiä tai dynaamista sisältöä.
"Dynaamisella sisällöllä" tarkoitan esimerkiksi sitä, että jos sivustolla on kuvagalleriamoduuli, niin tuollainen "klippi" voisi sisällyttää vaikka tietyn gallerian listauksen tai yksittäisen kuvan siten, ettei erikseen tarvitse syöttää koodiin kuvagallerian html-rakennetta kuvineen vaan moottori osaisi automaattisesti hakea pudotusvalikosta valitun gallerian sisällön ja tulostaa sen haluttuun kohtaan sivulle.
Ilmeisesti et sitten kuitenkaan käytä sitä WordPressiä vaan olet puhtaalta pöydältä kasannut sivusi?
PHP-koodin tallentaminen tietokantaan on yleensä hölmöä ja taitamattoman tekemänä myös erittäin vaarallista.
Tässähän oli ilmeisesti kyse oman cms:n tekemisestä eli siis ohjelmistosta, jonka avulla voi yksityistä sivustoa ylläpitää. Silloin ei ole välttämättä hirveästi väliä, mitä kaikkea voi admin-liittymästä tehdä, koska sivusto on joka tapauksessa ylläpitäjänsä vallassa. Mutta jos tarvitsee kylvää php-koodia cms:n sisällönsyöttötoimintojen kautta, niin se yleensä kertoo siitä, ettei cms-järjestelmä sisällä kaikkia tarvittavia toimintoja.
Jos tuo nyt liittyi minun aiempaan viestiini, niin sitten et ymmärtänyt, mitä itse tarkoitin.
The Alchemist kirjoitti:
Tässähän oli ilmeisesti kyse oman cms:n tekemisestä
Ehkä olen jättänyt jotain lukematta, mutta minusta tässä on kyllä edelleenkin kyse ihan muusta projektista, jostain tapahtumien järjestämiseen liittyvien työvuorojen varaamisesta.
Niin no, en itse enää tiedä, että liittyykö viime aikoina vallinnut keskustelu enää mitenkään työvuoronvarausohjelmaan. Luullakseni tässä on lennosta vaihdettu milloin mihinkin aiheeseen. Joskus on ollut puhetta WordPressin käyttämisestä alustana, mikä ei ainakaan voi mitenkään liittyä äsköiseen puheeseen sivujen siirtämisestä tietokantaan, toisaalta paljon on myös käytetty aikaa select-laatikoita tuottavan koodin kanssa arpomiseen ja muuhun pieneen näpertelyyn.
Noniin.. Eli versio 1 on WP+oma koodi. Versio 2 pelkästään oma koodi. Tutkin vain tuota sql lausetta ja siksi kysyin, kun siinä esim. Url sarake.
Olen tätä versio kahta tehdessä tajunnut kuinka hieno asia WP on. Hyöty on kuitenkin se että joudun miettimään kaiken itse. Esim. Kirjautuminen ja istunnot.
Mitä haittaa siitä on, että myös se lopullinen versio olisi WP+oma pulikka?
Eli nyt haluan ehdottomasti tehdä kaiken itse jotta opin. Parhaassa tapauksessa versio 3 käyttää WP:tä ja varsinkin Responsive Design filosofiaa.
Responsive Design ei liity tähän mitenkään. Tai toivon ainakin ettei järjestelmäsi ole riippuvainen siitä, millainen ulkoasu sivustollasi on.
Tarkoitin että WP:ssä on templateja jotka tukevat tätä ideologiaa. Haluan että tapahtumapalvelu toimii näillä:
-desktop
-laptop
-tablet
-smart phone
Kysymys, yritän tehdä popup boxia joka avaisi varaa työvuoro lomake näkymän. Miten ja mistä te lähtisitte hakemaan etsimään tietoa? (mm. jquery ui kirjasto ei tällaista valmiiksi sisällä).
Ennen kuin joku sanoo google ja että se on täynnä malleja. Niin toivomus olisi luotettava tutoriaali joka tukisi vanhaa ja ottaisi huomioon responsive design idean. Huom! Kysyn vain miten te ratkaisisitte asian.. Mistä aloittaisitte?
latenleffahylly kirjoitti:
Ennen kuin joku sanoo google ja että se on täynnä malleja. Niin roivomus olisi luotettava tutoriaali joka tukisi vanhaa ja ottaisi huomioon responsive design idean. Huom! Kysyn vain miten te ratkaisisitte asian.. Mistä aloittaisitte?
Aika paljon Google kuitenkin näytti, miten jQuery UI:n dialog-ikkunaan ajaxilla ladataan sisältöä.
Miten niin jQuery UI -kirjasto ei valmiiksi sisällä tarvittavia palikoita? Millaista ratkaisua sitten etsit?
Popup ikkuna ok, mutta onko tooltip muka tähän verrattavissa? No joo.. Jatkossa tulen joka tapauksessa tarvitsemaan popup ikkunoita, ja tooltip systeemejä, joten ehkä jQuery kurssi olisi hyvä.
latenleffahylly kirjoitti:
Popup ikkuna ok, mutta onko tooltip muka tähän verrattavissa? No joo.. Jatkossa tulen joka tapauksessa tarvitsemaan popup ikkunoita, ja tooltip systeemejä, joten ehkä jQuery kurssi olisi hyvä.
Tooltip? Ollaanko me enää edes samassa internetissä?
No ei tietenkään mikään tooltippi toimi mutta dialogi-ikkuna olisi jo jotain. Tai ainakin äsken vielä sanoit haluavasi dialogi-ikkunan, siksi ihmettelinkin, että miksei se muka kelpaa.
Ok, sanavirhe.. dialogi ikkuna parempi. Nyt taistelen SQL-lauseita vastaan... ja toivon pääseväni niistä vielä joskus eroon.
latenleffahylly kirjoitti:
Ok, sanavirhe.. dialogi ikkuna parempi. Nyt taistelen SQL-lauseita vastaan... ja toivon pääseväni niistä vielä joskus eroon.
Joo, hemmetisti selventää se, että puhutaan samoilla termeillä, varsinkin kun käyttämäsi termit on yleisesti käytössä ja tarkoittavat aivan eri asiaa.
JQuery UI -kirjastossa on valmiina widgetteinä sekä Dialog että Tooltip, joten mitähä lie mahdettukaan alun perin tarkoittaa...
The Alchemist kirjoitti:
JQuery UI -kirjastossa on valmiina widgetteinä sekä Dialog että Tooltip, joten mitähä lie mahdettukaan alun perin tarkoittaa...
Toisaalta, mitä odottaa ihmiseltä, jolle ei saa sanoa "Google on täynnä malleja"...
Täytyy sanoa tässä vaiheessa että;
Liirum laarum lallatilaa, Dibadaabaa doobermanni trallallaa.
Lööpi troopi trokaridaa, lorem ipsum ftw afk.
Olipahan video kun ei edes tabletilla toimi. No joo... Eli käsitin että popup ikkuna tai popup box on yleinen termi. Klikkaa linkkiä ja tällainen lomake ilmestyy tyhjästä.
Elokuva-aiheiset web-sivuni sisälsivät aikoinaan tällaisen tavan varata elokuva. Sitten arvostelijoilleni tiedoksi että php osaamiseni on mennyt eteenpäin. jQueryä en osaa mutta jonain päivänä ehkä osaankin. WP tulee myös olemaan keskeisessä roolissa, mutta ette voi suuttua heti siitä jos funktiot eivät ihan heti aukea...
Jos vähän keskustelua seuraisi... Minä kommentoin sitä, ettei tietenkään JQuery UI:n Tooltip-widgetti toimi, koska se on tarkoitettu ihan muihin asioihin. Sen sijaan oikeampi lähtökohta olisi ollut Dialog-widgetti. Kukaan ei ole nostanut esille popup-termin käyttöä. Eikä se ole mikään "sanavirhe", jos ehdottaa aivan täysin väärää komponenttia.
Alkemisti kirjoitti:
Sen sijaan oikeampi lähtökohta olisi ollut Dialog-widgetti. Kukaan ei ole nostanut esille popup-termin käyttöä.
Niin... siis minä nostin "termin" koska olen tähän saakka ollut siinä uskossa että popup box tarkoittaisi jotain tällaista, kuin nämä Google otsikot:
- 32 Best jQuery Popup Window Dialog Box Example | Smashing Spy
- Best 10 jQuery Popup Window Tutorials | jQuery4u
Dialog-widget on terminä tuntematon. Eli idea klikkaa linkkiä ja eteesi ilmestyy uusi ikkuna, jossa esim. form. Tänään kuitenkin harjoittelen olio-ohjelmointia (putkan oppaat)
Etkö käy töissä?
latenleffahylly kirjoitti:
Dialog-widget on terminä tuntematon. Eli idea klikkaa linkkiä ja eteesi ilmestyy uusi ikkuna, jossa esim. form. Tänään kuitenkin harjoittelen olio-ohjelmointia (putkan oppaat)
Itse sanoit, ettei JQuery UI sisällä tarvitsemiasi asioita. Kuten sanottua, sekä Tooltip että Dialog ovat JQuery UI:n widgettejä. Miten nämä voivat olla sinulle tuntemattomia asioita, kun kuitenkin tiedät sanoa, ettei JQuery UI:ssa ole tarvittavia palikoita?
latenleffahylly kirjoitti:
Dialog-widget on terminä tuntematon. Eli idea klikkaa linkkiä ja eteesi ilmestyy uusi ikkuna, jossa esim. form.
- Klikkaa linkkiä *Check*
- Uusi ikkuna *Check*
- Form *Check*
- (jQuery UI *Check*)
http://jqueryui.com/dialog/#modal-form
Löytyy siis ihan jQuery UI:n omista esimerkeistä.
edit:
Sen sijaan että käyt täällä kyselemässä useamman kerran päivässä tyhmiä, niin suosittelen oikeasti paneutumaan (katso vaikka kaikki esimerkit läpi) vaikkapa aluksi tuohon jQueryUI:n omiin esimerkkeihin.
Kukaan ei sanonut että ohjelmointi on helppoa, mutta kun itse osaa etsiä tietoa, niin homma helpottuu huomattavasti.
Ongelma on kai se, että Late haluaa "tutoriaaleja", joilla ilmeisesti tarkoittaa jotain sellaista opasta, jossa opetettaisiin vain ja ainoastaan halutut asiat nollasta täydellisyyteen ja mielellään vielä kuvien kanssa. Tällaisia oppaita et tule ikinä löytämään, vaan joudut opettelemaan koostamaan tietoa eri puolilta nettiä kerätyistä murusista.
Noniin.. Olen ehkä vihdoin ja viimein tajunnut jotain kovan painostuksen alla. Eli perjantai omistetaan tällaiselle asialle:
Harjoitus, jossa mm. Funktioiden teko, tietokantaan vieminen, hakeminen, yhdistäminen, hitusen luokkia, olioita ja lomake.
(!) APUNA SAA KÄYTTÄÄ AINOASTAAN PHP DOKUMENTAATIOTA (php.net)
- nyt idea on että koodaisin tyhjästä itse ja tarkistaisin manuaalista miten syntaksi kirjoitetaan, tai miten arrayta tai foreach tageja käytetään... Toki toivon että alan tekemään näin perjantaista lähtien aina. Ohjelmointiputka oppaat ovat upeita, niihin on käytetty valtavasti työtä, ne ovat viimeisteltyjä kokonaisuuksia ihmiseltä, joka ymmärtää php:n syvintä olemusta.
Olen tehnyt suuren virheen kun olen ensin lukenut opasta, kopioinut malleja ja vielä yrittänyt muuttaa niitä omiin tarkoituksiini. Hmm.. Luulen että paras tapa on jokin tehtävä:
1.) tee lomake
2.) yhdistä tietokantaan funktio
3.) tallenna kantaan funktio
4.) hae + tulosta kannasta funktio
5.) kiedo asiat luokan sisään
Nyt tehtävä on jakaa kukin kohta pienempiin osiin. Huom! Kirjoita ensin paperille mitä teet. Sitten koodaa tyhjästä. Ja ainoa paikka josta saa tutkia on php.net ja sielläkin mieluiten syntaksi ja php elementin käyttötarkoitus.
Pitää oppia tulostamaan haettua tietoa, jotta olen koko ajan selvillä mitä teen. Tämä vähenee ajan kanssa. Sitten kommentoin lyhyesti koodin alussa mitä koodi tekee. Muuttujan nimeäminen järkevästi, sama funktioiden kohdalla. Koodia kirjoitan zend tyylisesti.
---
Edelliseen kysymykseen hain sitä miten te lähestyisitte jQuery UI ympäristöä. Antaa sen nyt olla. Minun on opittava käyttämään Googlea paremmin ja luettava kärsivällisemmin tutoriaaleja tai oppaita. Toisaalta minun pitäisi uskaltaa koodata rohkeammin ja oppia ymmärtämään virheilmoituksia paremmin. Geijolle terveisiä, että käyn "töissä" mutta taloudellisen tilanteen vuoksi olisi hieno onnistua rakentamaan versio 2.
Siinä tavoite saada mm. 1 luokka jonka sisällä muita luokkia jotka perivät ominaisuuksia.
-Yhteys
--Sql
---ryhma
----tyontekija
----tapahtuma
Näin tietokantayhteys funktio (atribuutti) löytyisi Yhteys luokan sisältä. yhteys() tagia voisi käyttää Sql luokan sql kyselyissä-> yhteys() ...sitten idea olisi että työntekijän kaikki tiedot haetaan kerralla siis kaikkien työntekijöiden. Nyt voisin kutsua näytä id ja etunimi jne.
Toki mikä ero on työntekijällä ja työntekijöillä? Eli tämä suuri kokonaisuus on vasta kehitteillä. Noniin.. Taas meni selittelyksi, mutta nyt tajusin että en saa enään etsiä tietoa kuin php.net sivulta. Muiden mallitkin voin ohittaa. Parempi esim. Kirjoittaa hakukenttään: foreach ja lukea selitys...
The foreach construct provides an easy way to iterate over arrays. foreach works only on arrays and objects, and will issue an error when you try to use it on a variable with a different data type or an uninitialized variable. There are two syntaxes:
foreach (array_expression as $value)
statement
foreach (array_expression as $key => $value)
statement
Ei sinun tänne tarvitse selostaa asioita vaan alat toteuttaa niitä käytännössä. Php:ssä ei muuten ole mitään tageja (paitsi ehkä alku- ja loppusymbolit <?php ja ?>). Foreach on kielirakenne ja funktioita kutsutaan ihan tutulla ja turvallisella nimellä "funktio".
Kyllä, kyllä.. olet oikeassa. Teot, ei puhe. Varmasti kuukauden sisällä laitan lyhyen koodin pätkän, josta näkee että olen päässyt Noviisista -> tasolle Web Developer
Noniin tässä nyt yksi funktio jonka tein. Mielestäni selvää edistystä:
function toimistotlista($name, $offices) {
$a = "";
$a .= "<select name=" . $name . ">";
foreach ($offices as $key => $value) {
$a .= "<option value=" . $key . ">" . $value . "</option>";
}
$a .= "</select>";
return $a;
}
// ÄLÄ MUOKKAA TÄSTÄ ALAS
/*
<select name="office">
<option value="hki">Helsinki</option>
<option value="tre">Tampere</option>
</select>
*/
$offices = array(
'hki'=>'Helsinki',
'tre'=>'Tampere',
);
$lista = toimistotlista('office', $offices);
echo $lista;
echo $lista;Eli funktion tarkoitus on palauttaa select boksi. Näin ollen select boksia voidaan kutsua niin monta kertaa kuin tarve. Tarkistin koodin vielä Firebugin avulla.
Funktion nimi on huono, koska se antaa ymmärtää, että funktio toimii vain toimistojen tulostamiseen select-lootaan. Jos haluat tulostaa vaikka työntekijöitä, osoitteita tai mitä tahansa muuta, niin joudut kopioimaan täsmälleen saman koodiin uusiin funktioihin -> no good. Lisäksi et suorita tulostettaville muuttujille minkäänlaista sanitointia. Vinkki: htmlspecialchars. Funktion nimeäminen ei myöskään noudata mitään yleistä suositusta: lowerCamelCasea taikka underscore_separated_wordsia.
Siis: jos teet geneeristä koodia, niin myös nimeä funktiot ja niiden sisällä olevat muuttujat geneerisesti.
Php:n olio-ohjelmoinnin standardeista voi lukea täältä: https://github.com/php-fig/fig-standards/tree/master/accepted.
Ylläoleva meni harjoituksen puitteissa (tekosyy). Mutta oikeasti esim. function valintalista tai function tulostaValintalista ($name, $array)...
No minulla on paljon tekemistä. Tuo antamasi linkki on hyvä, mutta toistaiseksi en täysin halua sitä tutkia, koska en halua mennä asioiden edelle. Tuo yllä oleva on juurikin tämän hetkistä tasoani vastaava. Haluaisin kuitenkin heti alkuun kirjoitta standardien muikaista koodia ja tehdä asiat kuin ammattilaisetkin, kiitän.
Hei kaikille tähän topicciin kirjoittaneille,
Haluaisin hieman pahoitella aikaisempia postauksiani. Eli olen nyt käynyt läpi mm. foreach -silmukan ja array -taulukon. Niillä voi tosiaan tehdä ihmeitä. Myös pdo:ta olen tutkinut php-dokumentaation kautta. Oikeastaan ensimmäistä kertaa olen viihtynyt dokumentaation parissa.
Ainoa mikä tietysti häiritsee on php.net web-sivujen järkyttävä ulkoasu ja karmiva värimaailma. Tulevaisuudessa tarkoitukseni on tehdä 1 kunnon funktio joka auttaa Tapahtumapalvelu versio 2:den rakentamisessa, tarkemmin koodin yksinkertaistamisessa. Funktio laitetaan funktiokirjastoon.
Funktiota kutsuttaessa, voi antaa taulun nimen ja muuttujan jossa on sisällä paljon tietoa.. Tästä lisää myöhemmin. Kiitos kuitenkin että olette aina jaksaneet auttaa. Ohjelmointiputka on Suomen paras foorumi.
Aihe on jo aika vanha, joten et voi enää vastata siihen.