voi varmaan tehdä näin:
kääntäjä ei ainakaan herjaa mistään!
miksi sun mielestä olisi edullisempaa laittaa koko merkkijono echon sisälle sensijaan, että echolla tulostetaan vain päivämäärä?
volume kirjoitti:
voi varmaan tehdä näin:
kääntäjä ei ainakaan herjaa mistään!
Juurikin noin, niin on selkein.
Oho, katsoin väärin ja sekotin tuon viimeisen pisteen ns. "ja" merkiksi echo:ssa vaikka eihän se koko merkkijono ole echon sisällä, koska ohjelmoin omaa koodia tässä samalla, eli kuten Lebe80 sanoi, tee juuri noin. :D
Kannattais harkita oikeaoppista sisentämistä.
Lebe80 kirjoitti:
volume kirjoitti:
voi varmaan tehdä näin:
kääntäjä ei ainakaan herjaa mistään!
Juurikin noin, niin on selkein.
No ei todellakaan ole. Aivan järkyttävää. Tekninen toteutus ja näyttömuoto täytyy aina pitää erillään. Olet aivan kusessa, jos roiskit tuommoista kuraa joka paikkaan sivuillasi ja joku päivä joudutkin vaihtamaan päivämäärien esitystapaa.
<?php
class MyDate {
public static $default_format = 'j.n.Y';
private $stamp;
private $format;
public function __construct($stamp = null) {
$this->stamp = is_null($stamp) ? time() : $stamp;
$this->format = self::$default_format;
}
public function __toString() {
return date($this->format, $this->stamp);
}
}
?>
Lorem ipsum dolor sit amet: <?= new MyDate() ?>volume kirjoitti:
miksi sun mielestä olisi edullisempaa laittaa koko merkkijono echon sisälle sensijaan, että echolla tulostetaan vain päivämäärä?
Sillä ei ole mitään väliä. Tärkeintä on se, että koodi on ohjelmoijalle mahdollisimman selkeää ja mukavaa luettavaa. Redundanttien merkkijonojen tunkeminen print-kutsun sisälle ei ole helppolukuista eikä mukavaa edes kirjoitusvaiheessa.
Yleensäkin pitäisi pyrkiä siihen, ettei kahden tulostuskutsun välissä ruveta prosessoimaan dataa. Ensin suoritetaan datan käsittely ja vasta sitten tulostetaan tulokset.
Olen joutunut käsittelemään työni puolesta jopa yli 2000-rivisiä pökäleitä, joissa aivan holtittomasti tulostetaan ja prosessoidaan joka välissä vähän vaikka mitä. Tällaisen (t)ulostuksen kanssa menee tuntikausia jo ihan saada selvää, että mihin kohtaan pitäisi muutoksia tehdä, jottei koko paska lässähdä peruuttamattomasti kasaan.
se taitaa olla täsmälleen näin
Kiitos. Minä en ainakaan tiennyt The Alchemist:n tavasta paljon mitään, mutta kuitenkin tajuan rakenteen ja toiminnan. En ollut ikinä edes kuullut tuollaisesta <?=:stä, koska en ole käyttänyt luokkia oikeastaan, ainakaan muistaakseni. Miksi function nimessä on "__"? :)
'<?= $stuff ?>' on vain lyhyempi - sanoisin myös että selvempi - ilmaisutapa notaatiolle '<?php print $stuff ?>'. Se ei liity olioihin. Kahden alaviivan etuliite on php:ssä varattu taikametodeille, joiden avulla voi muokata sitä, miten oliot käyttäytyvät tietyissä tilanteissa tai mitä kaikkea niillä voi ylipäätään tehdä.
The Alchemist kirjoitti:
No ei todellakaan ole. Aivan järkyttävää. Tekninen toteutus ja näyttömuoto täytyy aina pitää erillään.
Ohjelmoinnissa ei kannata olla liian ehdoton. Jos teen yksittäisen sivun, jossa täytyy näyttää päivämäärä, niin tuo alkuperäinen ratkaisu on erittäin hyvä ja esittämäsi luokka tuntuu lähinnä trollaukselta. Koodin pituuden kymmenkertaistuminen on myös erittäin huono asia.
Päivämäärän esitystavan muuttuminen on huono perustelu, koska 1) esitystapa ei muutu ja 2) jos se kuitenkin muuttuu, niin merkkijonon "j.n.Y" korvaaminen uudella on helppoa myös alkuperäisessä toteutuksessa.
Yksittäisiä poikkeustapauksia toki on, mutta yhden placeholder-sivun verkkosivustoa ei mielestäni kannata erikseen mainita, vaan voi olettaa ihmisen loogisen ajattelukyvyn pelaavan normaalilla tasolla.
Luit myös väärin perusteluni korkeamman abstraktiotason ratkaisulleni. Sanoin, että jos roiskii usealle sivulle kiinteästi määriteltyjä päivämääriä, niin joku kaunis päivä voi huomata olevansa ongelmissa. Toinen syy voisi olla se, että kun on yksi hyvä yleiskäyttöinen luokka päivämäärien käsittelyyn, niin sitten sitä luokkaa kannattaa käyttää kaikkialla. Lisäksi päivämäärän muodon määrittely jokaiseen tulostukseen erikseen on työlästä ja tekee koodista rumaa.
Ja vaikken taaskaan maininnut, etteivät perusteluni välttämättä ole hyviä, jos halutaan vain yksi irrallinen placeholder-sivu, niin toivon jokaisen osaavan kysymyksen kohdatessaan pohtia, mitä silloin kannattaisi tehdä.
The Alchemist kirjoitti:
Sanoin, että jos roiskii usealle sivulle kiinteästi määriteltyjä päivämääriä, niin joku kaunis päivä voi huomata olevansa ongelmissa.
Mitä ongelmia tarkalleen syntyy? Minulle ei tule mieleen mitään toteutusta, jossa päivämäärän muodon muuttamiseen menisi yli minuutti aikaa.
"Tulevaisuuteen" varautuminen johtaa helposti liian monimutkaiseen koodiin. Olen seurannut monen henkilön olio-ohjelmoinnin opettelua, ja ongelmana ei ole koskaan ollut, että koodi olisi liian yksinkertainen. Sen sijaan on erittäin yleistä, että luokkia ja funktioita on liikaa. Jokainen uusi luokka ja funktio kasvattaa koodin monimutkaisuutta, minkä vuoksi niitä ei kannata tehdä turhan takia.
Ei ole ollenkaan vaikea saada aikaan koodia, jota ei pelkällä search & replacella korjata. Toki aloittelijoiden pienissä projekteissa manuaalisen työn osuus jäänee aika pieneksi, paitsi jos ja kun tällaisia korjaavia iteraatiokierroksia joudutaan tekemään muissakin vastaavissa asioissa, ei pelkästään date()-kutsujen osalta. Ongelmissa on sekin filosofinen hienous, että jos ne kaikki voisi nähdä ennalta, niin ne olisi myös paljon helpompi kiertää kuin varman päälle tekemällä.
Php:n puutteiden korjaaminen kirjoittamalla perustietotyypeille käärinluokat ei ole ylivarautumista ja päinvastoin ainoastaan helpottaa sekä koodaamista että koodin lukemista, kuten jo esimerkin voimin havainnollistin.
Minusta suurempi ongelma on se, ettei osata tehdä selkeää ryhmittelyä ja pitäytyä atomisissa funktioissa, vaan yritetään saada katettua yksi tarve yhdellä funktiolla, jolloin joudutaan koodaamaan 90-prosenttisesti samanlainen toiseen hieman erilaiseen tarpeeseen.
Teet PHP:sta liiankin kaupallista ja voihan sitä aina tehdä monia .php tiedostoja, jos ei tajua, vaikka se kuulemma hidastaakin.
"Ongelmissa on sekin filosofinen hienous, että jos ne kaikki voisi nähdä ennalta, niin ne olisi myös paljon helpompi kiertää kuin varman päälle tekemällä."
Kirjoita koodi ensin paperille päästäsi ja koodaa sitten virheet tunnistavalla ohjelmalla, näin tiedät ongelmat etukäteen. :)
Ei kaikki ole niin nörttejä, että tietävät todella paljon PHP:stä ja sen hienoista salaisuuksista, eli ohjelmoijien pitäisi vain ohjelmoida koodia mitä he itse pitävät parhaana ja mikä toimii, eikä mitä joku muu pitää parhaana vaihtoehtona, koska kukaan ei koodaa täydellistä koodia ja ei ole sitä parasta tapaa, koska on niin monia tapoja koodata.
Siinä ei pitäisi olla muille mitään ongelmia, jos joku pitää koodista enemmän omalla ihan kuinka työläällä ja rumalla tavallaan.
Se näissä keskustelupastoissa onkin huono juttu, että kaikki alkavat säätämään jotain omaa.
The Alchemist kirjoitti:
Php:n puutteiden korjaaminen kirjoittamalla perustietotyypeille käärinluokat ei ole ylivarautumista ja päinvastoin ainoastaan helpottaa sekä koodaamista että koodin lukemista, kuten jo esimerkin voimin havainnollistin.
Tuossa voi sitten jo miettiä, että kannattaako ylipäätään tehdä PHP:llä vai kenties jollain vähemmän puutteellisella kielellä.
volume kirjoitti:
voi varmaan tehdä näin:
Voi tehdä joo. Ja voi olla sitä mieltä, että kannattaa tehdä jotenkin strukturoidummin, mutta se on jo sitten aika laaja kysymys ja riippuu siitä, mitä ollaan tekemässä.
Toinen näkökohta on, että kun näin tulostat päivämäärän palvelimessa toimivalla koodilla, tulostat palvelimen aikavyöhykkeen mukaisen päivämäärän hetkellä, jolla palvelin suorittaa koodin. Tämä voi olla hyödyllistä, mutta tätä arvioitaessa kannattaa pitää mielessä, mistä päivästä siis on kyse. Ehkäpä tavallisinta on, että käyttäjälle näytetään päivämäärä ja kellonaika, ilmeisesti olettaen, ettei käyttäjällä eikä hänen koneessaan ole kelloa, ja unohtaen, että palvelimen aika ei välttämättä ole käyttäjän aika.
Jami kirjoitti:
Teet PHP:sta liiankin kaupallista ja voihan sitä aina tehdä monia .php tiedostoja, jos ei tajua, vaikka se kuulemma hidastaakin.
Kaupallista? Koodin jakaminen moneen tiedostoon ei hidasta koodin suoritusta niin paljon, että sillä olisi käytännön merkitystä.
Jami kirjoitti:
Se näissä keskustelupastoissa onkin huono juttu, että kaikki alkavat säätämään jotain omaa.
Minusta on hyvä, että keskustelussa tulee esille erilaisia tapoja toteuttaa asioita. On sinänsä hieno tavoite miettiä asioita itse ja koodata omalla tavallaan, mutta on virhe kuvitella, ettei muiden neuvoista olisi hyötyä.
Itse en esimerkiksi rupeisi "The Alchemist":n tapaa toteuttamaan, jos skriptin ainoa tarkoitus olisi vain tulostaa tekstin sekaan päivämäärä.
Jatkon kannalta taas tapa on varsin hyvä, mikäli projekti kasvaa ja kasvaa.
keskustelu meni vähän liiaksi filosofiselle puolelle, mutta The Alchemistin perusteluissa oli mielestäni yksi varsin painava kohta: "Tekninen toteutus ja näyttömuoto täytyy aina pitää erillään". tämä pitää varmasti paikkansa oli sitten kyse mistä tahansa ohjelmointikielestä! tässä on mielestäni kyseessä aika syvälle ohjelmoinnin perusteisiin menevä ajatus -ihan sama on myös xhtml&css -puolella siten että sisältö ja ominaisuudet ovat irti toisistaan. on myös varmaan niin, että oikeat ohjelmointiperiaatteet olisi syytä opetella heti alussa ettei niitä tarvitse sitten myöhemmin korjailla!
Grez kirjoitti:
The Alchemist kirjoitti:
Php:n puutteiden korjaaminen kirjoittamalla perustietotyypeille käärinluokat ei ole ylivarautumista ja päinvastoin ainoastaan helpottaa sekä koodaamista että koodin lukemista, kuten jo esimerkin voimin havainnollistin.
Tuossa voi sitten jo miettiä, että kannattaako ylipäätään tehdä PHP:llä vai kenties jollain vähemmän puutteellisella kielellä.
Itse olen pohtinut asiaa jo pidempään ja kokeillut joitakin vaihtoehtoja, mutta php vaikuttaa kaikista typeryyksistään huolimatta myös soveliaimmalta kieleltä webbikehitykseen. Itse olen oikeastaan ajautunut tilanteeseen, jossa liki kaikki php:n natiivit funktiot on korvattu oliovastineillaan. Tilanteesta riippuen joko koodailen luokat itse tai perustan projektin esimerkiksi Zendin päälle.
Antti Laaksonen kirjoitti:
Jami kirjoitti:
Teet PHP:sta liiankin kaupallista ja voihan sitä aina tehdä monia .php tiedostoja, jos ei tajua, vaikka se kuulemma hidastaakin.
Kaupallista? Koodin jakaminen moneen tiedostoon ei hidasta koodin suoritusta niin paljon, että sillä olisi käytännön merkitystä.
Palvelimilla on muutenkin käytössä erilaisia välimuistittajia, joiden tarkoitus on vähentää redundanssia niin levyn lukemisessa (file cache) kuin eri sivupyyntöjen välillä muuttumattoman php-koodin kääntämisessä (APC).
Joka tapauksessa laskentatehon hinnan halpeneminen on jo nyt johtanut siihen, että koodaamisessa tärkeimmät pointit ovat helppolukuinen ja "autonominen koodi", joka ottaa hoitaakseen triviaalit asiat, jotka ennen väännettiin käsin, kuten nyt vaikka tämä päivämäärän muotoilu.
Olen itse sitä mieltä, että järkevä luokkahierarkia, joka koostuu riittävän yksinkertaisista luokista jotka on eroteltu omiin tiedostoihinsa, on paljon mukavampi plärätä kuin yli tuhatriviset funktiokokoelmat. Zendinkin kanssa puljatessa näen jo suoraan luokan nimestä ja kontekstista, mistä hakemistosta ja tiedostosta sen lähdekoodi löytyy, jos haluan tarkistaa, mitä se pellin alla tekee.
volume kirjoitti:
keskustelu meni vähän liiaksi filosofiselle puolelle, mutta The Alchemistin perusteluissa oli mielestäni yksi varsin painava kohta: "Tekninen toteutus ja näyttömuoto täytyy aina pitää erillään". tämä pitää varmasti paikkansa oli sitten kyse mistä tahansa ohjelmointikielestä! tässä on mielestäni kyseessä aika syvälle ohjelmoinnin perusteisiin menevä ajatus -ihan sama on myös xhtml&css -puolella siten että sisältö ja ominaisuudet ovat irti toisistaan. on myös varmaan niin, että oikeat ohjelmointiperiaatteet olisi syytä opetella heti alussa ettei niitä tarvitse sitten myöhemmin korjailla!
Tämä on minustakin yksi oleellisimmista kulmakivistä ja toistan sitä aina ja joka tilanteessa myös elävässä elämässä. Php on itse asiassa hyvin omalaatuinen kieli juuri siinä suhteessa, että siinä on mahdollista upottaa käyttöliittymän sekaan koodia liiankin helposti.
Useissa webbikielissä ei ole mitään avaus/lopetustagihässäkkää (pl. nämä iki-ihanat jispit ja aspit), jonka avulla voitaisiin rakentaa sulautettuja html+skripti-hirvityksiä kuin vahingossa. Ja koska print-kutsun avulla suurten lohkojen tulostelu on rumaa ja vaikeaa, niin tämä on johtanut ns. template engineiden käyttöön, jotka tarjoavat melko rajoittuneet mahdollisuudet sotkea käyttöliittymän sekaan ohjelmakoodia, mikä jälleen korostaa näyttömuodon ja taustalaskennan erottelua.
Käytännössä homma menee niin, että moottorin puolella lasketaan lähes kaikki valmiiksi ja käyttöliittymäkoodille ainoastaan annetaan kasa muuttujia, jotka sisältävät suurin piirtein kaiken sen datan, mitä näkymässä on esillä. Tietysti on muitakin (sallivampia) periaatteita, joita voi pitää hyvinä tapoina ratkaista ongelma tiedon tuomisesta käyttäjän ruudulle.
Ja totta puhuen puristinen pyrkimys täydelliseen näyttömuodon ja taustatoteutuksen erottamiseen johtaa sekin ongelmiin joissakin asioissa, jolloin vaihtoehtoina on joko lieventää kompromissia lisäämällä järjestelmän kompleksisuutta tai sitten lipsua omista periaatteista.
Antti Laaksonen kirjoitti:
Ohjelmoinnissa ei kannata olla liian ehdoton.
Riippuu tilanteesta ja mitä tarkoittaa "liian". Mielestäni koodaaminen olisi nykyistä helpompaa, jos kaikki olisi standardoitu järkevästi. Ainakin edellisessä projektissa oli hieman ikävää parsia käsin tehtyä Excel-tiedostoa, jossa osa datasta oli mennyt väriin soluihin. Jos tiedosto olisi tehty järjestelmällisesti, olisi koodaaminen ollut paljon sujuvampaa.
Mutta toisaalta eipä kaikkea voikaan standardoida, kun maailma muuttuu, uusia tarpeita esiintyy ja ihmiset koodaavat eri tyyleillä.
The Alchemist kirjoitti:
Olen itse sitä mieltä, että järkevä luokkahierarkia, joka koostuu riittävän yksinkertaisista luokista jotka on eroteltu omiin tiedostoihinsa, on paljon mukavampi plärätä kuin yli tuhatriviset funktiokokoelmat. Zendinkin kanssa puljatessa näen jo suoraan luokan nimestä ja kontekstista, mistä hakemistosta ja tiedostosta sen lähdekoodi löytyy, jos haluan tarkistaa, mitä se pellin alla tekee.
Meinaatkos, että proseduraalista koodia ei saa järjesteltyä hallittavaksi ja selkeäksi kokonaisuudeksi? Kyllä siistiä ja modulaarista koodia pystyy kirjoittamaan ilman luokkiakin. Esimerkiksi omista käyttämistäni ohjelmointikielistä PL/I käyttää tähän tarkoitukseen paketteja, Modula-2, Limbo ja Fortran 90 käyttävät moduuleja.
Aihe on jo aika vanha, joten et voi enää vastata siihen.