Eli pientä johdatusta aiheeseen:
Nyt 3 vuotta keskustelufoorumeita seuranneena ja itsekin tietoturvasta välittämättä koodanneena tiedän sanoa että harva n00b ottaa huomioon tietoturvaa, joko laiskuuttaan tai osaamattomuuttaan.
Tiedän että maailmasta löytyy jos mitä ja vaikka mitä projektia, parhaimpana ehkä PEAR jossa näitä seikkoja on huomioitu.
Oma kunnianhimoinen tavoitteeni olisi tehdä PEARin tietokantamoduulista (ja muutamasta muustakin moduulista) suomenkielinen, melko lailla supistetumpi (ja helppokäyttöisempi) versio, jota kuka tahansa voisi käyttää, ja jonka asentaminen ei vaatisi insinöörintutkintoa saati rahaa.
Ja kuten kaikki tietää projektin etenemisen, tehdään aluksi päätös projektin toteutuksesta ja sen jälkeen projektille hienot kotisivut (no ei tosissaan, uskokaa minua kun sanon että hommaa on jo jopa speksattu :D).
Kaikki siis joukolla osoitteeseen http://www.futureality.net/filib josta löytyy johdatusta projektiin ja joillekin funktioille jopa alustavia kuvauksia (kolmelle jos ollaan tarkkoja).
Kommentit, ja ehkä vielä enemmän niiden perustelut, positiiviset ja negatiiviset ovat enemmän kuin tervetulleita. Myös mahdollinen osallistumishalukkuus projektiin kunhan versio 0.1b julkaistaan olisi mukava selvittää.
Kiitokset kaikille jo etukäteen, käyn aina silloin tällöin katselemassa tätä threadia ja vastailemassa mahdollisiin kysymyksiin.
Tuo on oikein hyvä hanke! Kannatetaan!
Kuulostaa hyvältä ja hyödylliseltä projektilta.
Suomen kielen käyttäminen on mainio päätös. Nykyään jotkut sanovat, että suomalaisenkin pitäisi muka koodata englanniksi, missä ei minusta ole järkeä. Tämmöinen suomenkielinen projekti varmaan kannustaa käyttämään suomea muutenkin ohjelmoinnissa.
Minä voin olla tarpeen tullen mukana vaikka oikolukijana ja kieliasun tarkistajana. Tässä pari alkukommenttia:
Hyvä homma, oikolukijoita aina tarvitaan, kiitos jo etukäteen.
Hieman vastauksia kommentteihin:
1) Vanhana patuna olen niin pahasti vieraantunut ääkkösistä, että alustavasti ne oli tullut vanhasta tottumuksesta aakkosina. Kuitenkin pointti on hyvä, ja aion ehdottomasti käyttää ääkkösiä (vaikka editorini syntax highlight sekoaa aina ä:n tullessa muun kuin stringin sisällä :D)
2) Funktion on tarkoitus hoitaa sekä INSERT että UPDATE riippuen löytyykö tietokannasta vastaavuus jonka käyttäjä on määritellyt. Lisää ei siis toimi mutta "laita" voisi olla harkitsemisen arvoinen. Muita nimiehdotuksia?
3 ja 4) sulje ja poistataulu ehdottomasti. Taas huomaa että yritän vääntää liian virallisia käännöksiä.
Projekti soljuu hitaasti mutta varmasti eteenpäin (kotikoneella on jo versio 0.02 odottamassa koeajoa). Lisäksi sivustolle on tullut kommentointimahdollisuus kuvattuihin funktioihin, eli sinne voi myös käydä kylvämässä ehdotuksia. Palautetta otetaan myös vastaan osoitteeseen filib [ A T ] futureality [ D O T ] net jos ujostuttaa kuulutella ideoita julkisesti.
Sitten tarvittaisiin taas kommentteja, lähinnä loogisuudesta seuraavista tulokkaista:
DEBUG-tilan käytöstä
http://www.futureality.net/filib/functions.php?f=Tietokanta->DEBUG
Taulun luonti
http://www.futureality.net/filib/functions.php?f=Tietokanta->luotaulu
Taulun poisto
http://www.futureality.net/filib/functions.php?f=Tietokanta->poistataulu
Lisäksi olen miettinyt funktioiden nimeämisiä, ja toivoisin teiltä kommenttia myös seuraavaan ideaan:
Kannattaisiko funktiokirjaston nimeämisessä käyttää aina pääryhmää ensimmäisenä ja toimintoa vasta toisena, jolloin esim. taulufunktiot olisivat loogisesti peräkkäin (ja suomenkieli kärsisi)
Nyt:
->luotaulu
... funktiot välissä
-> poistataulu
Idea:
->taululuo
->taulupoista
... välissä olleet funktiot
?
EDIT: Urliparseri tökkii, muuntaa näköjään yhden kirjaimen kolmeksi pisteeksi (fu...ctions.php?jne.)
Ja fiitsöä pukkaa. Meneekö ydinfyysikkotasolle jos PHP FiLib tietokantamoduuli ottaisi vastaan ehtolauseita myös taulukkomuotoisina? Eli:
<?php $arr_ehto = array ( "id" => "= 1&&", "enabled" => "< 0&&", 0 => array ( "aika" => ">= NOW()||", "kayttaja" => "= 'admin'", ), "&&teksti" => "IS NOT NULL", ); ?>
Muotoituisi koodin käsissä:
id = 1 AND
enabled < 0 AND
(
aika >= NOW() OR
kayttaja = 'admin'
)
AND teksti IS NOT NULL? Luonnollisesti myös tekstimuotoista ehtolausetta tuettaisiin, mutta itselläni tuo helpottaisi monimutkaisien ehtojen hallintaa huomattavasti (tuppaan itse olemaan sulkuexpertti, eli seitsemän alkavaa ja viisi tai yhdeksän päättyvää suljetta :D)
EDIT: Jos joku miettii että hullu kun koodaa uutena vuotena, voin kertoa että flunssakuumeessa on paha juhlia (mutta huva koodata *wirn*)
Tietenkään DEBUG ja debuggaaminen eivät ole hyvää suomea, mutta mikä olisi sopiva käännös?
Koodiesimerkeissä ($muuttuja == FALSE) olisi tyylikkäämmin (!$muuttuja) ja minä vähän vierastin tyypin alun kirjoittamista jokaisen muuttujan nimeen.
leftover kirjoitti:
Kannattaisiko funktiokirjaston nimeämisessä käyttää aina pääryhmää ensimmäisenä ja toimintoa vasta toisena, jolloin esim. taulufunktiot olisivat loogisesti peräkkäin
Minusta ei, koska nimet muuttuvat silloin huonoiksi. Funktioiden luettelossa järjestyksen voi päättää sitten myöhemmin sopivaksi, esim. aakkosjärjetyksen ohella myös aiheen mukaan.
leftover kirjoitti:
Urliparseri tökkii, muuntaa näköjään yhden kirjaimen kolmeksi pisteeksi (fu...ctions.php?jne.)
Pitkien linkkien keskelle tulee kolme pistettä, ja tämä sattuu juuri olemaan rajalla. Itse linkki sentään osoittaa oikein.
leftover kirjoitti:
Meneekö ydinfyysikkotasolle jos PHP FiLib tietokantamoduuli ottaisi vastaan ehtolauseita myös taulukkomuotoisina?
Kiinnostava idea. Minä kehittelin vähän toisenlaista merkintää, jossa AND- ja OR-yhdistykset ilmoitetaan kaikki- ja jokin-funktioiden avulla. Funktiot hyväksyvät minkä tahansa parametrien määrän. Kentän nimen ja vertailun pidin kuitenkin yhdessä. Lopussa on sama kysely minun merkintääni käyttäen.
<?php
function kaikki() {
return "(" . implode(func_get_args(), " AND ") . ")";
}
function jokin() {
return "(". implode(func_get_args(), " OR ") . ")";
}
$ehto = kaikki("id = 1",
"enabled < 0",
jokin("aika >= NOW()",
"kayttaja = 'admin'"),
"teksti IS NOT NULL");
?>Antti Laaksonen kirjoitti:
Tietenkään DEBUG ja debuggaaminen eivät ole hyvää suomea, mutta mikä olisi sopiva käännös?
Itse mietin vaihtoehtoina mm. vikasieto ja virhetila mutta tulin siihen tulokseen että käytännössä 95% koodareista olisi sen jälkeen "wtf?" kun eivät tajuaisi yhdistää sitä debuggiin. Lisäksi debug on iskostunut IMO niin hyvin suomalaisiin tietoteknikoihin että kielitoimisto saisi päättää sanan olevan suomalainen lainasana :D
Antti Laaksonen kirjoitti:
Koodiesimerkeissä ($muuttuja == FALSE) olisi tyylikkäämmin (!$muuttuja) ja minä vähän vierastin tyypin alun kirjoittamista jokaisen muuttujan nimeen.
Itse taas vierastan koodin lyhentelyä, koska esim. !$muuttuja == FALSE|0|NULL jolloin esimerkiksi laske-funktion esimerkissä koodi luulisi !$int_lkm tuloksen nolla olevan virhe (jota se ei ole, tarkoittaa vaan että funktio ei löytänyt yhtään vastaavuutta kannasta).
Toinen hirviö on yksirivisten ehtolauseiden sulkeettomuus, joka opettaa vääriä koodaustottumuksia. Siksi niin projekti kuin kaikki esimerkitkin on aina suljettu sulkeilla ehtolauseissa.
Muuttujatyypin lisääminen muuttujanimen alkuun etenkin esimerkeissä on turhaa koska kyseessä on hyvin lyhyt koodi. Pidemmässä koodissa olen taas huomannut koodauksen nopeutuvan kun tiedän että $arr_merkit on taulukko eikä esim. merkkijono ilman että tarvitsee palata alkuun tarkistamaan miten sen on koodiin sijoittanut.
Antti Laaksonen kirjoitti:
leftover kirjoitti:
Kannattaisiko funktiokirjaston nimeämisessä käyttää aina pääryhmää ensimmäisenä ja toimintoa vasta toisena, jolloin esim. taulufunktiot olisivat loogisesti peräkkäin
Minusta ei, koska nimet muuttuvat silloin huonoiksi. Funktioiden luettelossa järjestyksen voi päättää sitten myöhemmin sopivaksi, esim. aakkosjärjetyksen ohella myös aiheen mukaan.
Näin itsekin tämän pähkäilin, suomen kieli ennen koodin helppoutta. Lisäksi tällä menetelmällä on etuna se, että kaikki samaa toimintoa eri osa-alueilla tekevät saataisiin tarvittaessa yhteen pötköön. Pitääkin laittaa ylös että koodaan sivulle sorttausrutiinin jota käyttäjä saa vaihdella.
Antti Laaksonen kirjoitti:
leftover kirjoitti:
Urliparseri tökkii, muuntaa näköjään yhden kirjaimen kolmeksi pisteeksi (fu...ctions.php?jne.)
Pitkien linkkien keskelle tulee kolme pistettä, ja tämä sattuu juuri olemaan rajalla. Itse linkki sentään osoittaa oikein.
hmm... Eihän tuon silti pitäisi pidentää merkkijonoa? Eli jos maksimipituus olisi vaikka 100, pitäisi koodin laskea urlin pituus + 2 koska silloin saataisiin kitkettyä pois yhden merkin muunnos kolmeksi pisteeksi.
Antti Laaksonen kirjoitti:
Kiinnostava idea. Minä kehittelin vähän toisenlaista merkintää, jossa AND- ja OR-yhdistykset ilmoitetaan kaikki- ja jokin-funktioiden avulla. Funktiot hyväksyvät minkä tahansa parametrien määrän. Kentän nimen ja vertailun pidin kuitenkin yhdessä. Lopussa on sama kysely minun merkintääni käyttäen.
<?php function kaikki() { return "(" . implode(func_get_args(), " AND ") . ")"; } function jokin() { return "(". implode(func_get_args(), " OR ") . ")"; } $ehto = kaikki("id = 1", "enabled < 0", jokin("aika >= NOW()", "kayttaja = 'admin'"), "teksti IS NOT NULL"); ?>
Tuo vaikuttaa myös näppärältä tavalta, ja periaatteessa tuo tukisi sisennyksien avulla myös ehtolauseen rakenteellista tarkastelua. Nyt kun tarkemmin ajattelen, olisi järkevää opastaa taulukkomuunnoksessa avaimettomaan muunnokseen (jota koodi tukisi pienellä muutoksella) jolloin yksittäinen ehto pysyisi aina omassa lohkossaan ilman häiritseviä '] => ' välejä. Lisätäänpä todo-listaan.
EDIT: opettelen suomea
leftover kirjoitti:
Antti Laaksonen kirjoitti:
Tietenkään DEBUG ja debuggaaminen eivät ole hyvää suomea, mutta mikä olisi sopiva käännös?
Itse mietin vaihtoehtoina mm. vikasieto ja virhetila mutta tulin siihen tulokseen että käytännössä 95% koodareista olisi sen jälkeen "wtf?" kun eivät tajuaisi yhdistää sitä debuggiin.
Debug ja debuggaaminen eivät taida kääntyä "virhesiedoksi" oikein mitenkään, sehän tarkoittaa, että siedetään virheitä. Itselläni tuli mieleen virheenkorjaus (= debuggaaminen) ja virheenkorjaustila (= DEBUG tuossa kontekstissa). Pirullisen pitkiä tuppaavat nämä suomen sanat vain olemaan :)
fawkz kirjoitti:
Debug ja debuggaaminen eivät taida kääntyä "virhesiedoksi" oikein mitenkään, sehän tarkoittaa, että siedetään virheitä. Itselläni tuli mieleen virheenkorjaus (= debuggaaminen) ja virheenkorjaustila (= DEBUG tuossa kontekstissa). Pirullisen pitkiä tuppaavat nämä suomen sanat vain olemaan :)
virheenkorjaus taitaa olla se virallinen suomennos, mutta aivan kuten sanoit, turhan pitkä sana vaan. Periaatteessa pituus ei kovin paljoa häiritsisi, koska tila kytkettäisiin päälle melko satunnaisesti. Mutta edelleenkin olisi se 95% jotka ei tajuaisi kyseessä olevan debuggaustila :(
haha hieman turha
Noin, nyt olen päässyt niihin varsinaisiin funktioihin eli haku-, lisäys/päivitys- ja poistofunktioihin. uusin tulokas olisi aseta (anteeksi Antti, ei oikein ole löytynyt yksittäistä sanaa joka tarkoittaisi INSERT tai UPDATE :D) ja kuvaus funktiolle olisi osoitteessa
http://www.futureality.net/filib/functions.php?f=Tietokanta->aseta
Huomatkaa että olen miettinyt mukaan myös inhimillisen erheen, eli funktio estää toiminnon "WHERE 1" ellei käyttäjä sulje ykköstä lainausmerkkeihin tai toteuta ehtoa taulukkona. Arvelin että jotakuta saattaisi hieman ketuttaa kun viekun kaikkiin kommentteihin päivittyisi adminin vastaukseksi "Ihan kiva, tervetuloa" kun koodin olisi eksynyt limit yhden pykälän liian aikaisin :)
Lisäksi tein periaatepäätöksen ja poistin kaikki rivifunktiot, koska käytännössä LIMIT 1 hoitaa tämän kiltisti. Poistofunktioon tulee sitten pakolliseksi kentäksi rajoitus, mutta miten saan funktion poistamaan tarvittaessa kaikki rivit, on vielä avoin. varmaankin tyyliin negatiivinen arvo == ei limittiä.
EDIT: Hölmöä, en voi vastata lainaamalla viestiin koska kirjoitin kommentin... no, vastataan perään:
leftover kirjoitti:
Kommentit, ja ehkä vielä enemmän niiden perustelut, positiiviset ja negatiiviset ovat enemmän kuin tervetulleita.
mankeli kirjoitti:
haha hieman turha
Kiva kun saadaan vastarannan kiiskikin mukaan keskusteluun, koska niiltä tulee ne parhaimmat kehitysideat. Mutta et sitten raaskinut perustella?
On kyllä totta, että suomen kielen vaalimista tärkeämpää on käsitteiden ymmärrettävyys. "Debug" vain soveltuu huonosti suomeen (toisin kuin esim. function => funktio ja index => indeksi). Jos nyt ihan uusi sana pitäisi keksiä, oma ehdotukseni olisi "virhestää" (virhe + estää, muistuttaa myös sanaa "metsästää"), mutta tämmöiset sanat tuntuvat hyvin vierailta ja käsittämättömiltä aluksi.
Uudessa ehtotaulukossa indeksit voi varmaan jättää kokonaan merkitsemättä, koska silloinhan ne menevät automaattisesti numerojärjestykseen nollasta alkaen (muok: tämä onkin ilmeisesti jo suunnitelmissa).
Vertailuissa pitäisi varmaan käyttää ===-merkintää silloin, kun funktio voi palauttaa sekä arvon 0 että falsen (ainakin laske-funktiossa).
Virhestää kalskahtaa tosi pahasti korvaan, virheistää taas ei. Taidan tyytyä kuitenkin beta-vaiheessa tuttuun ja turvalliseen DEBUG-käyttöön. katsotaan jos tulee ehdoton kuningasehdotus jonka kaikki ymmärtää :)
Taas vaihteeksi koodaus ilman kahvia on kuin heikoilla jäillä tallustelu. väljällä vertailulla tosiaan oli (oli pakko tarkistaa php.netistä kun en uskonut) 0 = FALSE. Samoiten indeksien heitto romukoppaan kuulostaa hyvältä, ei taas pää pelannut.
Nyt olisi tullut ensijulkaisun aika.
Osoitteessa http://www.futureality.net/filib löytyy 0.1b latauspaketti, funktioissa kuvaukset kaikista funktioista ja kehittäjät-sivulla ohje mukaan liittymisestä.
Suurin osa funktioista on vielä kokeellisia, eli ei missään nimessä kannata alkaa rakentamaan mitään isoa tuon varaan. Jaeltava paketti on vain bugien, epäloogisuuksien ja kehitysprojektiin mukaan haluaville testausta varten.
Yritän koodata sivustolle vielä tämän päivän aikana bugien / ominaisuuksien lähettämistoiminnon, ja ennen sen julkaisemista bugeja ja ominaisuuksia voi lähetellä esim. sähköpostilla tai tähän threadiin. Jos haluatte, voitte kommentoida myös funktiosivuilla itse funktiota.
Kaikki siis joukolla testaamaan että saadaan nopeasti 1.0 jakoon ja käyttöön.
Hyvältä idealta vaikuttaa.
Yritin testata, mutta eipäs toiminutkaan "Fatal error: Cannot re-assign $this in E:\htdocs\test\tietokanta.php on line 57"
Tosin syy voi olla, että PHP on 5.1.0-dev
Koetapa poistaa rivi 57 eli $this = FALSE; . Sen ei pitäisi vaikuttaa ilmeisesti mitenkään, koska käsittääkseni luokka palauttaa automaattisesti FALSE jos konstruktori epäonnistuu.
Kirjaan tuon ylös bugeihin ja koetan keksiä ratkaisua.
Hmm... Tärkein unohtui mainita: koko herkku vaatii MySQL tuen.
Tarkentakaa tuo asia sivuillenne / tähän topikkiin.
Webbisivustosta sen verran, että alleviivaamattomat linkit ovat kauhean epäselkeitä normaalin tekstin seassa.
Eli alleviivaus tekstin seassa oleville linkeille tekisi hyvää :)
Kommentoin ton rivin, sen jälkeen sama ilmoitus riviltä 67, sen kommentoinnin jälkeen näyttäisi toimivan ainaskin tietokantaan yhdistäminen.
En PHP:n luokista juuri mitään tiedä, mutta eikös noi rivit ole turhaan, kun return palauttaa myös falsen.
Mites on alikyselyt ton kirjaston kanssa
T.M: Hyvä pointti, pitääkin lisätä huomautus samoin tein. Lisäsin samalla alleviivauksen sisällön linkkeihin
Opiskelija: Hyvä homma että sait toimimaan, laitetaan korjaustapa muistiin. Alikyselyille ei ole vielä tukea koska a) oma palveluntarjoajani ei ole päivittänyt MySQL (eli en vaan osaa enkä edes pysty opettelemaan muuten kuin teoreettisesti). Arvelin että tämä tilanne on vielä niin monella että tehdään homma old-fashioned -tavalla
Eipä ollut sairaslomalla parempaakaan tekemistä, joten näpertelin aikani kuluksi version 0.2b valmiiksi. Ohessa muuttuneet kohdat:
Versio 0.2b
5.1.2005
- Lisätty #1 funktiot pienin ja suurin
- Korjattu #2 ongelma PHP 5 suhteen
- Eriytetty tietokantaan yhdistys luokan konstruktorista
- Lisätty funktio yhdistä
- Muutettu funktio sql->suoritaKysely ja asetettu palautusarvoksi resurssitiedot
- Virallinen tuki toiminnolle Tietokanta->MODUULI
- Virallinen tuki toiminnolle Tietokanta->SPONSOROI
- Muutettu funktioiden nimeämiskäytäntö Java-tyyliseksi (esim. luoTaulu)
- Lisätty funktio aikaTyyppi
- Lisätty funktio tuoAika
- Lisätty funktio vieAika
Nyt olen taas askeleen lähempänä oikeaoppista olio-ohjelmointia kun konstruktori palauttaa aina luokan. Lisäksi taivuin javatyylisten funktionimien käyttöön, kun huomasin PHP:n olevan incasesensitive metodien nimien suhteen. Eli näyttää paremmalta mutta ei hidasta kun ei tarvitse muistaa mikä olikaan se kohta jossa tuli iso kirjain.
Ajan muotoilemiseksi tuli muutama pyyntö, joten ajattelin että mikä ettei. aikaTyyppi on melko alkutekijöissään, mutta sinne saa ehdotella lisää virallisia ajan merkintätapoja (sillä edellytyksellä että PHP ja MySQL ei kerro viikonpäiviä ja kuukausia kuin englanniksi, eli vain niitä tuetaan ei-numeraalisissa merkinnöissä).
sql vaihtui ihan selkeyden vuoksi muotoon suoritaKysely ja tarvittaessa sieltä saadaan ulos resurssitiedot.
Harkinnassa on myös tuki alikyselyille, ja varmaankin rinnakkaiskirjasto jossa olisi samat toiminnot mysqli-funktioilla. Näistä lisää (ehkä) tulevaisuudessa.
Sivustolle on tullut uusina elementteinä bugien raportointi, jonne voi ihan rohkeasti lisäillä bugeja ja toiveita vaikka lempinimellä. Funktioiden alta löytyy alue myös tuleville muutoksille. Ja edelleen olisi kiva jos saisi mukaan myös muita kehittäjiä (saadaan maukkaampi soppa kunhan annetaan padan vain muhia rauhassa).
Nyt oltaisiin päästy sitten versioon 0.5b, jossa mm. sisäänrakennettu virheenhallinta. Alla uusimman version muutosloki:
Versio 0.5b
8.1.2005
- Korjattu #3 virheellinen ehtotarkistus laske , pienin ja suurin
- Lisätty parempi virheenhallinta Tietokanta->virheenTarkistus
- Muutettu yhdistä -> avaaYhteys
- Muutettu sulje -> suljeYhteys
- Nimetty tietokanta.php class.tietokanta.php
- Lisätty ominaisuus DEBUG_VIRHE josta löytyy vikatilanteissa virheviesti
- Yhdistetty kaikki funktiot käyttämään luokan omaa virheen tarkistusta
- Kokeellisuus poistettu: Tietokanta , MODUULI , SPONSOROI , avaaYhteys , suljeYhteys , laske , pienin , suurin , valmistele ja valmisteleEhto
Aihe on jo aika vanha, joten et voi enää vastata siihen.