phpkonferenca je kul

July 5th, 2008

bilo je zanimivo. Organizacija dobra (hvala Anžetu in ostalim), tematike ustrezne, predavatelji kompetentni (čeprav ne vsi z dobrim View layerjem, hihi). Predavanja so bila bolj splošno-tehnične narave, brez umazanih podrobnosti, tako da veliko novega nisem izvedel. Vsaka tema sama zase bi sicer lahko porabila cel dan in še ne bi prišli do konca, tudi občinstvo je bilo široko (par zelo mladih, vzpodbudno), tako da je to razumljivo. Skratka, bilo je fajn.

Malo je nagajal samo naš “krožek” zgoraj, ker smo bili z vprašanji vztrajni in kritični (upam, da ne tudi tečni). Se mi je zdelo, da je po prvih nekaj predavanjih vsak predavatelj pogledoval proti nam in vprašanja že pričakoval. Upam, da nisem komu pokvaril predavateljske izkušnje. :)

Me je pa presenetilo število ljudi, ki razvijajo vse na lastni kodi; konkretno frameworke. Sicer smo tudi pri nas to počeli, vendar se na dolgi rok to ne splača. Open-source frameworkov in CMS-ov je malo morje, vsak lahko najde ustreznega, ki je aktivno v razvoju, ima spodobno dokumentacijo in skupnost, tako da to ni izgovor. Res je, da se je potem potrebno malo prilagoditi (pač ni spisan tebi na kožo), ampak prednosti premagajo vse. Mimo tebe se software razvija, odpravljajo se hrošči, dodajajo se funkcionalnosti, vse to dobesedno zastonj. Ves čas lahko posvetiš programiranju specifičnih zahtev svojih aplikacij. Kaj šele, če katerega od svojih razvijalcev dodeliš za par ur tedensko na ta projekt, namesto, da razvija lastno rešitev? In ja, seveda obstajajo izjeme, kjer je lastni razvoj bolj smiseln, ampak za enostavne strani in tipične aplikacije to vsekakor velja.

Druga zadeva, ki me je presenetila, je število zagovornikov templatinga. Gre za večni boj templejtov proti uporabi čistega php-ja. Kot nekoč zagrizen Smartyjevec, z bežnimi izkušnjami s PHPTAL-om in svojimi preprostimi templating rešitvami, nekako razumem, da argumenti v prid templejtom obstajajo. Ampak zdaj, ko sem šel na drugo stran, se mi ti argumenti zdijo večinoma slabi, puščajo vodo, nekateri pa so že kar nesmiselni. Na kratko rečeno: prav nobene prednosti ne vidim v uporabi templating sistema. Razen v izjemnih primerih, se razume. In razume se tudi, da večina uporabnikov templejtov teh izjemnih primerov nima (drugače ne bi bili izjemni, hehe).

Kakorkoli, zanimiv in zabaven dogodek. Za drugo leto držim pesti za večdnevno zadevo, po možnosti s poglobljenimi delavnicami na kakšnih zanimivih področjih. In držim pesti, da bo žrebanje in da bom jaz dobil maca, letos so bili listki očitno nekaj pomešani, ker ga nisem. :D

PS. baje sem edini, ki uporablja unit testing. Upam, da si samo ljudje niso upali dvigniti roke, ker je 1/150 hudo majhen delež. ;)



15 Responses to “phpkonferenca je kul”

  1. Ice-Heki Says:

    No, pa sem le ugotovil, kdo je bil najbolj vztrajen z vprašanji (na php-si.com sem te poimenoval kot “gospod iz zadnje sredinske vrste” :)

    Glede Mac-a pa se mi zdi, da drugo leto ga dobim jaz – letos ga je dobil nekdo, ki je sedel pred mano, zato (predvidevam) drugo leto pripada meni :P

  2. Jernej Says:

    No glede CMSjev in frameworkov se ne strinjam, recimo phpBB2 ko je nekdo našel buga pa je takoj par tisoč forumov dol padlo ? Opensource power …

    Kar je pa druga stvar, razvijanje svojega vsekakor ni zgubljanje časa, če ne druga zato ker vadiš programiranje :D . No pa resno, hitro vse najdeš in točno več kje je kaj. Če delaš lepo imaš lahko zadevo že v osnovi zelo lepo optimizirano (govorim o SEO), da ne vzamemo kakega CMSja, pri katerem se nemoreš rešiti IDjev v URLju, ter se mučiš z nevem koliko preusmeritvami in mod_rewrite pravili da nimaš duplicate content.

    Pa še ena glede hitrosti, boš hitreje naredil nek page iz tujega CMSja, kjer boš popravljal in se zafrkaval z nekimi stvarmi, ki so jih drugi mislili drugače narediti … pa 80% časa boš iskal kje je kaj nametano, ali pa boš 1 krat sprogramiral svoj CMS in boš vedel kje v njem se nahaja 95% ter ga boš lahko hitro prilagajal svojim potrebam.

    Opensource in to ja … ampak na krajši rok, po moje se pa na daljši rok bolj splača delati svoje zadeve.

  3. Jernej Says:

    Typo … “95% stvari” bi moralo biti :) .

  4. Krof Drakula Says:

    @Jernej: Seveda je vse odvisno od frameworka, ki si ga izbereš za delo. Če je phpBB2 namenjen forumskim sitom, potem pač z njim ne greš narediti intraneta. Pravo orodje za pravi problem.

    Zend in Symfony sta zgledna primera tega, kako je lahko framework prilagodljiv veliki populaciji problemov (da ne bo pomote – še zdaleč ne vsem!), pri čemer je Zend bolj splošen kot Symfony, pri vsem skupaj pa imaš poleg nepretrganega razvoja še podporo ostalih uporabnikov, tako naprednih kot začetnikov, ki ti lahko pomagajo pri delu. Seveda je pri tem pomembna dokumentacija, zato pa tudi izbereš framework, ki je dobro dokumentiran, pri čemer odpadejo vsi razen prvega argumenta proti uporabi popularnega frameworka.

    Kar se tiče pa komprimiranja sistema na podlagi najdenega buga, gre ponavadi tu za starejše različice, ki podležejo takšnim napadom – ob ustreznem vzdrževalnem ciklu naj bi bilo večino takšnih pripetljajev močno omejenih, ker gre pa za one-off inštalacijo in nobene naknadne nadgradnje, se pa dogaja to, kar se je že zgodilo.

  5. fett Says:

    what Krof said. Plus, gre za ekonomsko računico. Koliko časa zgubiš, če razviješ svoj framework in ga vzdržuješ nekaj let, odpravljaš hrošče, pišeš dokumentacijo in razvijaš dodatke?

    Koliko časa izgubiš, ko nove programerje uvajaš v svoj framework, dostikrat na pomanjkljivi dokumentaciji in “lastnem pristopu”, namesto, da bi ga uvajal v nek standardni princip, ki se ga hitreje nauči (več dokumentacije, bolj destilirana koda = bolj logično in jasno), mogoče ga pa že od prej zna? Če zna od prej Symfony, se bo v CakePHP ali ZF uvajal le 30% časa in obratno. Tvojega frameworka od prej ne zna.

    Edina splošna prednost razvoja lastnega frameworka je ta, da lahko narediš stvari natanko tako, kot jih rabiš. Kar pomeni nižji kodni overhead pri programiranju ponavljajočih aplikacij, kjer javni frameworki rešujejo stvari splošno (ker morajo zadostiti širši skupini ljudi) in je posledica nekaj večja koda. Ampak tega jaz ne vidim kot slabost, temveč kot možnost razširitve. Spreminjanje poslovne logike v splošnih frameworkih je dobesedno zastonj, v specifičnem pa lahko stane ohoho.

    Ponavljam — so izjeme, kjer je lastni framework prava opcija. Lahko tudi, da sploh ne potrebuješ frameworka. Ampak moj point je, da večina php programerjev, prisotnih na sobotni konferenci, ne razume, da njihov primer ne spada med te izjeme.

    Za konec še ideja v razmislek. Vzameš od vseh OS frameworkov tistega, ki ti najbolj ustreza (torej je najbližji tvoji idealni rešitvi) in je hkrati aktivno v razvoju, ima dobro dokumentacijo in široko skupnost. Takega najdeš brez dvoma. Zdaj pa: ves čas, ki bi ga programerji v podjetju drugače porabili za razvoj interne rešitve, raje namenijo v razvoj tega OS frameworka. V službenem času, na račun firme, tako kot gre službeni čas za razvoj lastnega frameworka. Kaj meniš, kakšna bo kvaliteta izdelka, v primerjavi z lastno rešitvijo? Za isto ceno.

  6. black Says:

    fett, ta zadnji argument običajno dobi luknje kot švicarski sir, ker čisto noben projekt na svetu ni organiziran iz strani communitya, kar se tiče featurejev, ampak ima običajno vsaj ene 2-3 ljudi pri vrhu, kateri so projekt zasnovali in posledično usmerjajo tudi razvoj.

    Praktično to pomeni, da je smer razvoja odvisna predvsem od teh ljudi in se mora ta “firma” katera se je spravila pridruzit razvoju tega OS frameworka prilagajat tem vodjam projekta, namesto, da bi šel razvoj bolj po njihovem načinu.

    Praktično je zaradi tega nastal Hardened PHP project (kjer je povdarek na večji varnosti), pa mysql-max (kjer je povdarek na več standardnih featurejev nad standardnim mysqlom), ncache (modifikacija nginx z caching proxyjem).

    Dost projektov se odcepi, ko pride mimo dovolj močna skupina ljudi, ki hoče, da gre razvoj tega v neko drugo smer, ki njim bolj odgovarja.

    @fatg, glede templating sistema bom naredil celo kaskado benchmarkov po tem sistemu: http://alexeyrybak.com/blitz/blitz_en.html

    Pričakujem, da bo Mini TPL nekako hitrejši od Smartyja, zelo blizu PHP include benchmarka (logično počasnejši kot PHP include, ker se gre vseeno za 3KB dodatnega overheada)

    Zanimivo, ko sem danes našel tale benchmark, tist glede Fast Templatea kar sem rekel na konferenci drži kot pribito, tist “Fast” je lahko sam čas razvoja s strani avtorja, nikakor pa ne hitrost izvajanja :)

    Aja drugač pa, mene je tud presenetilo število zagovornikov templateov. Ko sem vprašal koliko uporablja kakšen templating sistem, je samo tretjina dvignila roke, sem kar šokiran, da jih je bilo tolk malo.

  7. domn Says:

    nisi edini, jaz sem tud že spisan nekaj unit testov. in ja, upravičeno lahko govorim v množini :)

  8. fett Says:

    black: seveda vodijo projekt vodje razvoja. Moj argument ne pušča vode, iz dveh razlogov. Prvič: ker sploh ni argument, ampak samo ideja v razmislek. In drugič, ker privzame, da štartaš s projektom, ki je že v osnovi blizu tvoji lastni idealni rešitvi. Jasno je, da zadeva ne bo popolna (za kontrast: tudi lastni framework ne bo). Jasno pa je, da lahko podjetje, ki vlaga v projekt recimo 20 ur tedensko, bolj vpliva na razvojne odločitve produkta, kot pa nek samostojen programer, ki produkt samo uporablja in ne pomaga pri razvoju. To je znano in veljavno dejstvo, ki ne rabi drugega dokaza, kot da pogledaš po OS projektih: več kot nekdo investira, več vpliva ima. Primeri, ki jih navajaš, so druge narave; tam so se zgodili forki, ker spremembe niso bile kompatibilne z večino aplikacij in filozofija sprememb ni prepričala glavnih razvijalcev oz. niso videli potrebe po drastičnih spremembah. Lahko pa so samo nesporazumi med skupinama glavnih razvijalcev. Ko se to zgodi, se produkta jasno ločita, ker gresta naprej po ločeni poti.

    Glede templejtov pa mislim, da ne razumeš. Ne gre za benchmarke, benchmarki pridejo v igro, ko (če) se odločiš templejte uporabljati. Tudi ne gre za uporabniške preference. Jasno je, da če nekdo hoče uporabljati neko zadevo, ima vso pravico. In tudi ne gre za ločitev kode od oblike. Kot prvo je fraza napačna, ker stremimo k ločitvi poslovne logike od prezentacijske logike, ne pa za ločitev kode od oblike. To ne pomeni, da ne smeš imeti kode v prezentaciji. Gre bolj za enostavno dejstvo, kaj je objektivno gledano v splošnem boljša rešitev. Templejti ne dodajo projektu nič, razen dodatne plasti komplikacij, razen izjemoma. Še vedno čakam, da mi slišim kakršnokoli prednost namenskih templejtov pred uporabo PHP-ja.

    domn: zakaj pol nisi dvignu roke? :D

  9. Tit Petrič Says:

    Za 20% počasnejše izvajanje posamezne template datoteke, kot pa če bi direktno napisal zadevo v PHPju, ti razlike v berljivosti template datotek in krajša sintaksa nad PHPjem pride zelo prav.

    Template enginei so logična evolucija uporabe PHPja, ker dejansko so programerji leni in zato hočejo imeti zadeve bolj enostavne. Če to nebi bilo res, bi cel svet uporabljal PHP brez (zdaj že zelo velikega števila) template sistemov. Tako pa nekako ostajaš v manjšini in, kar mi je najbolj nelogično, se je oprijemaš kot pijanec plota.

    Si pač pure php evangelist, kaj te je pa pripeljalo do tega razmišljanja pa ne vem. Sam praktično napišem še vedno veliko PHP kode, veliko stvari tudi samo PHP kodo, ampak da bi pa pisal vse brez template datotek, se mi zdi pa kot da bi zavrtel razvoj minimalno tri do štiri leta nazaj, kar je pa že skoraj kamena doba, ko pride do razvoja.

  10. fett Says:

    Mene sploh ne matra hitrost templejtov, ker so (če gre za kolikor toliko spodoben engine) skompajlani v php in posledično skeširani. To je sicer odveč, ker rešuje problem, ki ga templejti sami ustvarijo, ampak ok, hitrost recimo ni problem, razen v posebnih primerih.

    Zdi se mi, da nočeš videti, da preglednost templejtov s kompleksnostjo pada, če pa jih poenostavljaš, pa itak potiskaš view kodo v php in templejti izgubljajo pomen. Praktično vsak ne-trivialen templejt ima več predpriprave in kode od analogne verzije v php-ju. Toliko o preglednosti in hitrosti razvoja.

    Templejti nikakor niso logična evolucija uporabe PHP-ja, rad pa bi videl, po čem sklepaš da so. Sem izrazito logičen tip, tako da bom tvoj argument lahko razumel, če bo res temeljil na logiki. Programerji so leni, ampak to ni vzrok, oz. če je, je napačen, ker morajo programerji stremeti k preglednosti prej kot hitrosti razvoja. V končni fazi kodo napišeš samo 1x, vzdržuješ jo pa leta in leta.

    To, da “cel svet” uporablja templejte, nikakor ne drži. Če se prav spomnim, jih od prisotnih na konferenci uporablja samo okrog 1/3. Še nižji rezultat dobiš, če povprašaš po malo bolj razvitih in zavednih skupnostih. Torej nisem v manjšini in tvoja primerjava s pijancem ni na mestu. Tudi ZF in Symfony privzeto uporabljata PHP za templating, kar pomeni, da enako velja za večino njunih uporabnikov.

    Prav tako ni res, da sem evangelist. Prej bi rekel, da si to ti, ker si aktiven v promociji ideje. Jaz samo razumsko spodbijam tvoj pogled na podlagi argumentov. Po definiciji to ni evangelizem. Še bolj natančno: tudi če bi aktivno spodbijal templejte, ne bi bil evangelist. Na moje stališče so me pripeljale izključno izkušnje. Imam veliko kilometrine v templejting sistemih, še vedno jih uporabljam v legacy projektih in se mi zdijo popolnoma odveč. Ne dodajo nobene vrednosti k razvoju, samo otežijo vzdrževanje. To ne velja v splošnem za vse jezike, ampak PHP se pred ostalimi razlikuje točno v tem, da imaš ves čas na voljo zmogljiv templejting sistem.

    Še vedno pa čakam, da mi jasno poveš in argumentiraš katerokoli prednost templejtov. Sem sit ponavljanja, ker imam občutek, da propagiraš templejte brez neke jasne osnove.

  11. black Says:

    Ubistvu sem že dost povedal in tud praktično argumentiral zakaj je template sistem boljši. Ne vem pa od kje ti ideja, da preglednost kode pada z uporabo templatinga, ki ni PHP?

    Izpis spremenljivke v minitpl: {v} ali {$v}
    Izpis spremenljivke v PHP:
    Izpis spremenljivke v full PHP:

    Short tags itak veš, da je deprecated, ne? Prav tako je v template sistemih veliko olajšane sintakse za delo s tabelami, ipd. Kode je tako veliko manj, poleg tega, da je berljiva veliko bolje znotraj HTML/XML kode, kot pa PHP sam.

    Torej, enostavnejša sintaksa, povečana hitrost razvoja posledično bolj enostavna razdelitev med oblikovanjem in programiranjem. Več kot nazorno so to prednosti nad PHPjem, katere kontrargumentiraš na osnovnošolskem “ne pa ne, to ni res” nivoju.

    Imam kar veliko kompleksnih template datotek, ki bi postavile pod vprašaj tvojo trditev, da je “analogni” PHP manj obsežen, kar se tiče predpriprav in hkrati bolj berljiv. Pravtako se je tudi izkazalo v razvoju, da je treba CMS level HTML komponente (funkcije, če želiš), katere se je napisalo v PHPju in potem uporabljalo, večkrat spreminjat in da je na koncu bolje, če jih ni, ker ravno tiste največkrat podrejo koncept MVCja. Stvar discipline programerja je, kakšno kodo piše, če se ti ne da zbirat podatkov za uporabo v template sistemu, pol se ti jih tudi za PHP ne bo dal in bo koda daleč stran od pregledne ali optimalne. Ljudje bojo programiral tolk grdo kot so navajeni in tukaj te ne bo rešil ne PHP in ne template engine.

    Rekel sem, če nebi bilo prednosti v template sistemih, bi cel svet uporabljal tvoj “pure code” way in tudi tiste tretjine ljudi, ki uporablja template sisteme nebi bilo. Sploh ne bom spraševal kaj bi bila po tvoje bolj razvita in zavedna skupnost. PhpBB ima template engine ki ni php, wordpress ima template engine ki ni php, typo3 ima template engine, ki ni php in veliko projektov je takih, ki ima template engine, kater ni PHP. Kaj si moraš potem mislit o takih, ki uporabljajo xslt za template engine? Logično je xslt nastal zaradi popolnoma drugih potreb, ampak to še ne pomeni, da nima nobene prednosti.

    Naštel sem več argimentov, očitno jih pa samo nočeš priznat. Se mi tud odgovarjat ne da več, ker tole je že zdavnaj preraslo meje razuma. Raje razmisli zakaj se držiš pure php pristopa, ker od naštetih stvari nobena ni taka, da bi držala kaj vode, razen obremenitve sistema, katero si pa sam izključil. Največkrat sem se držal pure-phpja ravno tam, kjer so bile obremenitve prevelike, da bi bilo pragmatično zadaj imet template class, database class, itd.

    Template sistem men pomeni ravno obratno izkušnjo, ker mi pohitri razvoj in poenostavi vzdrževanje. Pa se ti znajd iz PHP kode, katero si pisal pred 5 ali več leti in ne veš več kako si zadeve sprogramiral. Če nebi uporabljal templatinga, bi zelo pogosto potreboval veliko več časa za odpravo morebitnih napak, ali pa nadgradnje, kot pa dejansko ga.

    P.s. če ne uporabljaš template sistema/ov, a je potem tudi to vprašanje na mestu: Ne uporabljam database classa? Raje pišeš mysql_query() namesto $db->query(), v katerem bi lahko poskrbel (kot drugi) za error checking, query logging, query benchmarking…

    Verjem da je primerjava na mestu, templating sistem velikokrat olajša razvoj, prav tako kot dobro zastavljen database class.

    Verjemi da, tko kot ti, mam za sabo veliko kilometrine na PHPju, pa pred tem tudi z drugimi jeziki. Najboljš da dava tiče na mizo pa vidva kdo ma daljšega, ker dosedaj sem slišal samo pametovanja, ne pa kakšno konkretno vprašanje, problem ali pa argumentiranje, zakaj bi bil template, kot praviš, nepotreben. Me zanima, kaj so ti tvoji omenjeni “izjemni” primeri, kjer si ugotovil, da je templating potreben.

  12. black Says:

    Očitno ma wordpress rad html input. Sam ponovim un del na začetku, kjer so se pojedl < in >

    Izpis spremenljivke v minitpl: {v} ali {$v}
    Izpis spremenljivke v PHP: <?= $v; ?>
    Izpis spremenljivke v full PHP: <?php echo $v; ?>

    EOT

  13. fett Says:

    Ne vem pa od kje ti ideja, da preglednost kode pada z uporabo templatinga, ki ni PHP?

    Tega nisem rekel. Rekel sem, da je preglednost pada s kompleksnostjo. Za razliko od PHP-ja, kjer imaš ves čas na voljo poln nabor programskega jezika in je preglednost odvisna samo od kompleksnosti podatkovnih struktur, je pri templejting sistemih drugače. Ker ne znajo vseh jezikovnih konstruktov, ki lahko večkrat pridejo prav, moraš v določenih primerih iti okoli riti v žep. Število teh primerov pa narašča s kompleksnostjo. Recimo, da želiš uporabiti switch. Smarty ga pred časom ni poznal (mogoče zdaj ga), torej si moral narediti switch v predpripravi. Torej cel switch blok in variable assignment, da se potem v templejtu nisi nič spraševal o nobeni vrednosti, da si naredil samo output. V tem primeru bi prihranil na količini kode in pridobil večjo preglednost, če bi switch postavil direktno v template.

    Druga, še bolj pomembna implikacija tega je, da imaš zdaj puščanje med C in V layerjema; ker v kontrolerju izvajaš kodo, ki je namenjena izključno oblikovanju prezentacije. Če bi bil purist, bi v bistvu moral razširiti View layer še na PHP, tako da kontroler ne bi komuniciral direktno s templejtom, temveč z vmesnim PHP View classom, ta pa potem s templejtom. Vse to samo zato, ker templating engine nečesa ne zna.

    Primer s switchem mogoče ni najboljši, vendar jasno pokaže problem. Take vrste težav niti niso rešljive z view helperji, ker gre za kontrolno kodo v view layerju, ne za transformacijske funkcije. In s kontrolno kodo v View layerju ni popolnoma nič narobe, če spada v prezentacijsko logiko. Lahko imaš 1 tono prezentacijske kode, če želiš. Cilj namreč ni ločiti kode od oblike (tega itak nič bolj ne dosežeš s templejti, ki so še vedno koda), temveč ločiti poslovno logiko od prezentacijske. Razilka med tema ciljema je ogromna.

    Torej, enostavnejša sintaksa, povečana hitrost razvoja posledično bolj enostavna razdelitev med oblikovanjem in programiranjem. Več kot nazorno so to prednosti nad PHPjem, katere kontrargumentiraš na osnovnošolskem “ne pa ne, to ni res” nivoju.

    Žaljiv ton lahko ohraniš zase. Osebno nimam nič proti tebi, sem samo nasprotnik templejtov, zato se prosim drži debate na strokovnem nivoju. Glede tvoje trditve pa: se strinjam, to bi res bile prednosti pred PHP-jem, če bi bilo res tako. Enostavnejša sintaksa? Ja, res je {$v} na prvo oko enostavnejše od PHP-jeve verzije. Če pa dobro pomisliš, pa ugotoviš, da to pride samo od tega, ker moraš pri php-ju dopisati še < ?php echo ?>. Gre le za marginalen overhead, ki je povrh vsega še konstanten (ne narašča s kompleksnostjo bloka, za en blok potrebuješ samo to in nič več). Templating sistem na tem prišpara, ampak ostala sintaksa ni prav nič enostavnejša.

    In kaj pa parametrizirani modifierji, variable assignment, looping, vgnezdeni klici funkcij? Eni so sicer bolj pregledno zastavljeni od drugih, ampak preglednost ni vrlina teh konstruktov. Primer (sintakse od Smartyja ne znam več):
    PHP: < ?php echo number_format($amount, 2, $locale->dec_point, $locale->tho_sep); ?>
    Smarty: {$amount|number_format:2:$locale->dec_point:$locale->tho_sep}
    Kaj je bolj pregledno in intuitivno programerju? In ja, ene stvari (tudi ta konkretni primer) lahko vržeš v helper oz. modifier, ampak isto lahko narediš v PHP-ju.

    Kompleksen templejt, kjer imaš gnezdene iteracije po seznamih objektov in izpisuješ spremenljivke ustrezno pripravljene (html escaping, casing, number formatting, …), vrednosti dobivaš iz objektov druge (ali večje) oddaljenosti (npr. echo $objekt->getParent()->getOwner()->getName()) in ki je po možnost še večjezičen z lokalizacijo, postane v templejting sistemih maintenance nightmare. Templejting sistemi pač niso na nivoju okretnosti in raztegljivosti PHP-ja, zato lahko kompleksno logiko dosegaš samo po stranskih poteh.

    Primer iz Smartyja pred letom ali dvema, ko še ni podpiral objektov večjih oddaljenosti (verjetno so glede tega že kaj uredili): iteracija po getterju objekta druge oddaljenosti.
    PHP:
    echo $objekt->getParent()->getName();
    foreach ($objekt->getParent()->getAllChildren() as $child)
    {

    }

    Smarty:
    {assign var=”parentName” value=$objekt->getParent()->getName()}
    {$parentName}
    {assign var=”children” value=$parent->getAllChildren()}
    {section name=”sec” loop=$parent->getAllChildren var=$child}

    {/section}

    Mislim, da je očitno, katera koda ima več šuma. PHP praktično nima niti znaka odveč, preglednost Smarty templejta pa pada z vsako vrstico. Dodaj zraven še html escaping in na Smartyjevi strani dobiš še prekrasne parametrizirane modifierje, ki so res zgled berljivosti. Potem začneš reševati probleme tako, da umikaš view logiko v helperje in v predpripravo, v templejtu pa se trudiš obdržati čim manj.

    To pa ima več posledic:
    – vzameš moč templejtu; ker template zahteva in prebavlja samo natanko določene in formatirane podatke, ne moreš spreminjati prezentacije samo v templejtu, temveč še na vsaj enem koncu.
    – php koda narašča in začne vsebovati vedno večji del prezentacijske logike, template pa samo še izpisuje spremenljivke in dela enostavnejše obdelave. Rezultat: view layer razdvojen v dva različna kosa view logike, kjer ene stvari počne php, druge pa template. Koda med tema dvema ni prenosljiva, torej ne moreš recimo premakniti neke vrstice iz templejta v predpripravo. Poleg tega je to še bonus za vzdrževanje: moraš popraviti nek izpis in moraš najprej sploh ugotoviti, ali je obdelava v predpripravi, ali v templejtu. V PHP templejtingu imaš samo 1 template in ta vsebuje prezentacijsko logiko.
    – narašča količina eksplicitno pripravljenih in prenesenih spremenljivk: templejtu od zunaj podaš $objekt->getParent()->getName() in $objekt->getParent()->getAllChildren(), po potrebi še $objekt. Lahko pa bi seveda podal samo $objekt, kar popolnoma zadošča v PHP templejtingu. To po nepotrebnem veča količino kode (assigni). Iz svojih izkušenj vem, da je za vsak malo kompleksnejši template potrebno opazno več kode, kot v PHP verziji, kljub temu, da imaš pri phpju overhead s PHP tagom (kar je res minimalen overhead, v vsem ostalem je PHP zelo direkten).

    Imam kar veliko kompleksnih template datotek, ki bi postavile pod vprašaj tvojo trditev, da je “analogni” PHP manj obsežen, kar se tiče predpriprav in hkrati bolj berljiv. Pravtako se je tudi izkazalo v razvoju, da je treba CMS level HTML komponente (funkcije, če želiš), katere se je napisalo v PHPju in potem uporabljalo, večkrat spreminjat in da je na koncu bolje, če jih ni, ker ravno tiste največkrat podrejo koncept MVCja. Stvar discipline programerja je, kakšno kodo piše, če se ti ne da zbirat podatkov za uporabo v template sistemu, pol se ti jih tudi za PHP ne bo dal in bo koda daleč stran od pregledne ali optimalne. Ljudje bojo programiral tolk grdo kot so navajeni in tukaj te ne bo rešil ne PHP in ne template engine.

    Jaz s PHPjem ne rešujem nikogar in ničesar. Seveda lahko v PHP-ju pišeš dobro in slabo kodo, ampak pomembna razlika je v tem, da te PHP ne omejuje pri pisanju dobre kode, kot te templating. V trenutku, ko ti neko kodo spišeš z namenom, da se izogneš neki omejitvi templating sistema (recimo že omenjen primer, ko moraš uporabiti assign pred loopom), je templating sistem v napoto. Niti za trenutek se programer ne sme spraševati, katere spremenljivke bo moral pred templejtom ustrezno pripraviti, ker templejting ne zmore potrebne logike, katere pa lahko poda direktno not. Edino, kar se mora programer glede podatkov vprašati, je to, kaj sodi v View layer in kaj ne. Torej; kakšne vrednosti so rezultat poslovne logike in kako se vrednosti spreminjajo zaradi prezentacijske logike. Če je rezultat izračuna 123, želeni output pa 123.00, potem je stvar jasna: poslovna logika mora vrniti 123, prezentacijska logika pa mora iz tega narediti 123.00. Ko je layer določen, je s tem določeno tudi to, kje bo koda. Če mora programer prilagajati kodo zaradi templating sistema, je to narobe.

    Naštel sem več argimentov, očitno jih pa samo nočeš priznat. Se mi tud odgovarjat ne da več, ker tole je že zdavnaj preraslo meje razuma. Raje razmisli zakaj se držiš pure php pristopa, ker od naštetih stvari nobena ni taka, da bi držala kaj vode, razen obremenitve sistema, katero si pa sam izključil. Največkrat sem se držal pure-phpja ravno tam, kjer so bile obremenitve prevelike, da bi bilo pragmatično zadaj imet template class, database class, itd.

    Vse tvoje argumente sem obdelal. PHP pristopa se držim, ker mi prvič templejting ne doda nobene vrednosti, samo komplikacije, in drugič, ker delam v glavnem stvari, kjer je performance zelo pomemben. Za en navaden site 20% upočasnitev sploh ni problem, kjer pa je, pa ne želim že a priori izbrati počasnejše variante.

    Template sistem men pomeni ravno obratno izkušnjo, ker mi pohitri razvoj in poenostavi vzdrževanje. Pa se ti znajd iz PHP kode, katero si pisal pred 5 ali več leti in ne veš več kako si zadeve sprogramiral. Če nebi uporabljal templatinga, bi zelo pogosto potreboval veliko več časa za odpravo morebitnih napak, ali pa nadgradnje, kot pa dejansko ga.

    Zakaj bi potreboval več časa za PHP? Boš trdil, da je vzrževanje težje zaradi < ?php echo ?> dodatka? Ker če to odšteješ, je kode v PHP-jevih templejtih kvečjem manj. Sicer pa template jezik pravzaprav ničesar ne poenostavi, samo problem linearno preslika v drug jezik. Še vedno imaš izpise in kontrolne strukture, torej poenostavitve ni. Skozi helperje sicer pridejo krajšnice, ampak to imaš itak tudi pri PHP-ju. Če kaj, potem je kvečjem težji za vdrževanje, ker imaš več kode za predpripravo spremenljivk, prezentacijsko logiko bolj razpršeno in še en software za vzdrževanje. Updejtaš templating sistem zaradi enega buga, se pojavijo drugi. Enako kot v vsakem softwareu, ampak zakaj bi hotel poleg vseh tistih še enega?

    P.s. če ne uporabljaš template sistema/ov, a je potem tudi to vprašanje na mestu: Ne uporabljam database classa? Raje pišeš mysql_query() namesto $db->query(), v katerem bi lahko poskrbel (kot drugi) za error checking, query logging, query benchmarking…

    Verjem da je primerjava na mestu, templating sistem velikokrat olajša razvoj, prav tako kot dobro zastavljen database class.

    Hja, ta primerjava nikakor ni na mestu in ne vem, zakaj se ti zdi, da je. Sem vešč v objektnem programiranju in so mi prednosti popolnoma jasne, samo ne vidim nobene vzporednice v danem primeru. Koncepti OOP nimajo vzporednice v PHP vs. templating system debati. Če si imel v mislih abstrakcijo, to ni to, ker s templejting sistemom ničesar ne abstrahiraš. Gre namreč za linearno preslikavo: podajanje podatkov v prezentacijo. Če namesto php-ja v templejtu uporabiš eno drugo kodo, si pač uporabil drugo kodo, princip je isti. O abstrakciji tukaj praktično ni govora. Edina možna raba besede abstrakcija v povezavi s templejti je ta, da lahko z language-independent templating sistemom templejte prenašaš med različnimi jeziki, česar pa verjetno ne počneš prav pogosto. Z argumentom “olajša razvoj” pa lahko potem primerjaš tudi templejting sistem in notepad proti kakšnemu IDE, ker IDE tudi olajša razvoj.

    Verjemi da, tko kot ti, mam za sabo veliko kilometrine na PHPju, pa pred tem tudi z drugimi jeziki. Najboljš da dava tiče na mizo pa vidva kdo ma daljšega, ker dosedaj sem slišal samo pametovanja, ne pa kakšno konkretno vprašanje, problem ali pa argumentiranje, zakaj bi bil template, kot praviš, nepotreben. Me zanima, kaj so ti tvoji omenjeni “izjemni” primeri, kjer si ugotovil, da je templating potreben.

    En primer je ta, da uporabiš templejte tam, kjer njihova največja slabost (omejevanje programerja) postane prednost. Če recimo gostiš aplikacijo in želiš uporabnikom dopustiti določeno mero kontrole nad izpisom (da si sami urejajo templejte na svojih podstraneh), nočeš pa tvegati, da bo nekdo izvajal škodljivo kodo. V tem primeru je templejting smiseln, ker so druge metode (izklapljanje funkcij v php-ju, sandboxing, …) težke, slabe, dražje za vzdrževanje in konec koncev tudi neučinkovite, ker se vedno najde kakšna luknja, ki je nisi predvidel. Ampak večina projektov pač ni takih, večina programerjev se s takimi aplikacijami ne sreča, torej gre po definiciji za “izjemen primer”.

    Skratka; smiselni primeri rabe templejtingov vsekakor obstajajo, ampak za tipičen razvoj spletnih strani so po mojem mnenju odveč.

  14. black Says:

    Kompleksen templejt, kjer imaš gnezdene iteracije po seznamih objektov in izpisuješ spremenljivke ustrezno pripravljene (html escaping, casing, number formatting, …), vrednosti dobivaš iz objektov druge (ali večje) oddaljenosti (npr. echo $objekt->getParent()->getOwner()->getName()) in ki je po možnost še večjezičen z lokalizacijo, postane v templejting sistemih maintenance nightmare. Templejting sistemi pač niso na nivoju okretnosti in raztegljivosti PHP-ja, zato lahko kompleksno logiko dosegaš samo po stranskih poteh.

    Ne vem na kaj točno tukaj ciljaš, ker bi moral bit pridobivanje podatkov PHP del, ki ni nič več ali manj kompleksen, če uporabljaš PHP template preko include()-a ali pa drug template engine? Vsaj nebi smel bit, če se držiš pravila, da podatke pridobiš na PHP nivoju, na template nivoju jih pa samo prikazuješ.

    Dost govoriš o raztegljivosti PHPja in teoretično imaš prav (glede number format, ipd), ampak razmisli tako:

    1. V osnovi kar rabiš je loope, izpis spremenljivk in escape za html, to pokrije vsaj 80-90% view kode
    2. number_format, kot primer, je bolj stvar lokalizacije in tako del poslovne logike in tako direktni klici nimajo kaj delat v templateu, lokalizacija bi morala bit rešena sistemsko, ker se gre za lokalizacijo podatkov (in bi moral bit template neodvisen od lokalizacije).

    Ne rečem, tud v templateih uporabljam {eval}, katermu podaš za njim clean php kodo, as-is. Ampak praktično so to tile:

    1. Izpis podatkov izven seznamov (1 novica, pa pol 4 novice, pa pol seznam 10 novic, na isti strani, ipd):

    {eval $row = $newsitems[0]; $newsitems = array_slice($newsitems,1);} itd.

    Kle je pač nesmiselno narest 3 data arraye, ker je razporeditev odvisna od oblike, dobit moraš samo tistih 15 novic.

    2. Barvanje vrstic pri kakšnih seznamih, vsaka vrstica drugačno barvo

    {eval $class = ($class==”odd”) ? “even” : “odd”}

    Smarty mislim, da ima tukaj nek shortcut za tole.

    3. Counter iteracije & setiranje vrednosti & math (iteracije bi lahko rešil to sistemsko v {foreach}u, da mi nebi bilo treba, smarty to dela)

    {eval $cc=1}
    {eval $cc++}
    {eval echo $cc+1}

    In tukaj se neha. Formatiranje datumov in številk je kot rečeno, bi moralo biti na višjem nivoju.

    Kar se tiče overheada za <?php echo ?> -
    na RTVju v templateu za branje novice se pojavi template tag 269x, kar pomeni da bi v PHPju napisal skoraj 3KB samo PHP tagov z echom, poleg tega da se koda še veča, ker imajo {foreach} komande ekstra kodo pri compileanju za !empty / else funkcionalnost, pa tudi {literal} in {block} tagi bi moral it v funkcije, itd.

    Če vzamem recimo paginator, pridem iz osnovnih 685b tpl na 1176b php, pa je samo par ifov, foreach pa izpis spremenljivk. Granted, PHP bi bil še manjši, če bi se znebil po 6b na vsako komando ($v[""] je za spremenljivke), ampak še vedno večji kot tpl. Glavna prednost PHPja pa itak ni v velikosti, ampak to da se znebiš overheada enga template classa in podvajanja spremenljivk v njem.

    Parametriziranih modifierjev nisem implementiral v minitpl-ju, sem mel pa implementirano stvar na prejšnjem internem template engineu. Tam sem mel tud implementiran klicanje funkcij čez {func_*} na isti način. To sta ble dve najbolj debilni stvari, katere je možno implementirat in uporabljat, na splošno se jih je zelo redko uporabljal in smo jih tud opustil.

    Lahko uporabljaš {eval}, sam temu pol ne rečt modifier :). Načeloma je tako, da je najbolj enostaven modifier npr: {var|ucfirst} in kot tak je uporaba skoraj idealna proti: <?php echo ucfirst($var); ?> Razlika je 13 znakov proti 28! Praktično bo povsod neka razlika zarad katere bo template krajši. Z PHP sintakso MiniTPLja je za razliko od Smartyja, tudi razumljiv.

    Primer iz Smartyja nekako ni na mestu (ne zadane žeblja na glavo), ker bi moral bit pridobivanje podatkov stvar poslovne logike, ne pa template logike, kar sem večkrat povdaril že tudi prej. Način kako pridet do podatkov ne spada v template engine, pa tudi če ti template engine to podpira. Uporabljaj assign/assign_by_ref znotraj PHPja, kot je mišljeno. ORM je pa glavni razlog, zakaj imaš oteženo delo tukaj. Template sistemi niso pisani zato, da bi bili objektni, pa že karkol objektnega podpirajo, je bolj tko-tko, slučajno. Minitpl bi bil glede ORMja mogoče bolj ustrezen, navsezadnje je PHP syntax, bi bilo za probat. Načeloma pretvorim vse spremenljivke na zelo pameten način direktno v PHP kodo, pa bi znal ORM način dela čist solidno laufat znotraj minitplja. Smarty mi itak sintaktično ni všeč, ker se preveč odstrani od PHPja, na kar sem tudi na konferenci opozarjal.

    Tvoje naštete posledice ne vem če so dejansko relevantne:

    - vzameš moč templejtu; ker template zahteva in prebavlja samo natanko določene in formatirane podatke, ne moreš spreminjati prezentacije samo v templejtu, temveč še na vsaj enem koncu.

    Praktično, bi moralo biti to isto tudi če uporabljaš PHP include() za template. Verjetno mešaš logiko za prikaz in logiko pridobivanja podatkov (ORM) in zato popravljaš samo en PHP file, ker si dal ORM in pripravo podatkov kar v template. Lahko se motim, ampak na Smarty primeru domnevam, da potem uporabljas ORM tudi znotraj template php datotek. Kot si izpostavil, gre se za točno določene podatke, in če imaš točno določene in formatirane podatke, potrebuješ spreminjat oba nivoja (php in template) samo v primeru ko se ti podatki spremenijo. Edin primer, ko spremeniš samo template ob spremembi podatkov, je če se s podatki ukvarjaš v templateu, kar pomeni da imaš poslovno logiko na napačnem mestu (tukaj predvsem ciljam na ORM, kjer verjetno potem pripravljaš podatke kar v templateu).

    Kako pa potem rešuješ linke? Jih imaš v template datotekah statično, ali jih vsaj gradiš preko kakšnih funkcij? Jih gradiš na php nivoju ali v template nivoju?

    - php koda narašča in začne vsebovati vedno večji del prezentacijske logike, template pa samo še izpisuje spremenljivke in dela enostavnejše obdelave. Rezultat: view layer razdvojen v dva različna kosa view logike, kjer ene stvari počne php, druge pa template. Koda med tema dvema ni prenosljiva, torej ne moreš recimo premakniti neke vrstice iz templejta v predpripravo. Poleg tega je to še bonus za vzdrževanje: moraš popraviti nek izpis in moraš najprej sploh ugotoviti, ali je obdelava v predpripravi, ali v templejtu. V PHP templejtingu imaš samo 1 template in ta vsebuje prezentacijsko logiko.

    To mislim, da so bolj začetniške težave. Ljudje, ki prvič vidijo template sistem in so navajeni PHP programiranja, ugotovijo, da template sistem podpira marsikaj in potem dajo ogromno logike znotraj template sistema. Praktično bi moralo biti, kot sem rekel, tako da template dobi podatke in ne dela nobene obdelave, ki ni specifična za prikaz. Se pravi, escaping za HTML / JSON, itd. se bi moral zgodit v templateu, PHP bi moral zagotovit samo kakšne standardne modifierje (modifierji, ki delajo na podatkih, ne modifierji, ki bi izpisovali HTML-XML-JSON, kar so tudi zlorabe, že glede na ime “modifier”). Nočem s tem rečt kej slabga, razen tega, da je to programerska težava, ker je razmišljanje še vedno na PHP nivoju. Template sistemi imajo nek learning curve, kater ti definira razmišljanje, kaj spada v template in kaj ne. Opažam, da je imel sodelavec, ko se je privajal na template, podobne težave kot ti, ker je praktično hotel prestavit vse kar je imel v PHPju kar direktno v template, z izjemo samo SQL queryjev :)… sem bil malo presenečen, da ni kar query result resource dal templateu in tam skrbel za fetch. So pač neke stvari, katere ni dobr počet, tud če to template omogoča.

    - narašča količina eksplicitno pripravljenih in prenesenih spremenljivk: templejtu od zunaj podaš $objekt->getParent()->getName() in $objekt->getParent()->getAllChildren(), po potrebi še $objekt. Lahko pa bi seveda podal samo $objekt, kar popolnoma zadošča v PHP templejtingu. To po nepotrebnem veča količino kode (assigni). Iz svojih izkušenj vem, da je za vsak malo kompleksnejši template potrebno opazno več kode, kot v PHP verziji, kljub temu, da imaš pri phpju overhead s PHP tagom (kar je res minimalen overhead, v vsem ostalem je PHP zelo direkten).

    Se strinjam, memory usage se poveča (ne preveč znatno z referencami, assign_by_ref()).

    ORM način dela bi moral (vsaj pri smartyju) ostat v PHPju tako in bi definitivno podvojil podatkovne strukture, sploh če rabiš dodajat ali spreminjat podatke, kar je običajna praksa. Drugače pa idealno templatei delajo na navadnih arrayih. MiniTPL je pomoje bolj prijazen, ko pride do ORMja pri loopih, itd in lahko probaš podat samo $objekt. Res pa da je foreach direktno čez result funkcije/metode PHP5 feature in zdele sam špekuliram, da bo koda pravilno prevedena. Morala bi bit, ampak testa nisem pa naredil še nobenega, ker se držim bolj PHP4 specifik :).

    Pravtako, lahko bi naredil eno abstrakcijo na template nivoju, kar se tiče tega PHP5 featureja, pa verjetno tudi drugih. {foreach $obj->method() as $k=>$v} nebi bilo problematično prevest v valid PHP4, tako kot PHP5 kodo.

    Za vsak template sistem, katerega poznam, je overhead glede na PHP verzijo ravno v spremenljivkah, ker se napaja iz objekta template enginea, se pravi se vse enkapsulira v en array. $this->_parsevals['v'] je kar divja ja. V minitplju je še vedno $v['v'], ker bi $v[] pomenil en extract() klic na podatkih in tako dodatno podvajanje vseh spremenljivk, za marginalno manjšo PHP kodo. Prevedena PHP koda ne bo nikol tolk pregledna, kot tista katero lahko napišeš sam.

    Če je rezultat izračuna 123, želeni output pa 123.00, potem je stvar jasna: poslovna logika mora vrniti 123, prezentacijska logika pa mora iz tega narediti 123.00.

    Ubistvu ne, to je ravno tisto kar sem povdaril prej. Ouput preko number_formata je stvar lokalizacije, slovenija ima 123,00 medtem ko ima usa/anglija 123.00 – lokalizacija je poslovna logika, vse kar si se pa sam odločil je pa to, da je number_format() kot ga kličeš stvar view logike, ker delaš samo za en specifičen trg / državo. Isto debato sem mel par tednov nazaj v službi, ko smo moral iz lokaliziranega mssqla (kater ima že sam po sebi lokalizacijo na datumih in številkah v bazi, največja neumnost na svetu) prikazovat number vrednosti v drugem formatu. V glavnem, lokalizacija ni stvar view logike, ampak obdelave podatkov s katerimi razpolagaš, da se jih pripravi za template.

    Ko je layer določen, je s tem določeno tudi to, kje bo koda. Če mora programer prilagajati kodo zaradi templating sistema, je to narobe.

    Nekje prideš vedno do odločitve zakaj je bilo nekaj narejeno na tak ali drugačen način. Tako kot tvoj number_format v templateu, je lahko kdo razmišljal korak naprej, naredil generalen modifier, kater glede na lokalizacijo kliče tudi korekten number_format glede na državo za katero je produkt lokaliziran. Ko boš ugotovil, da rabiš drug number format na drugih trgih ali kakorkoli, boš tudi sam naredil isto in boš moral spremenit tako PHP kot template nivo. To ni narobe, to je razvoj. Običajno bi lahk temu rekl tud porodni krči, ko se še učijo ljudje, kako pravilno uporabljat template engine. Tudi v PHPju samem, boš moral v takem primeru nekoč zamenjat vse number_format klice z neko funkcijo, ki ti bo vračala korekten number format za lokaliziran prikaz.

    Hja, ta primerjava nikakor ni na mestu in ne vem, zakaj se ti zdi, da je. Sem vešč v objektnem programiranju in so mi prednosti popolnoma jasne, samo ne vidim nobene vzporednice v danem primeru. Koncepti OOP nimajo vzporednice v PHP vs. templating system debati.

    Ni bila primerjava mišljena kot OOP, lahk tudi plain db_* funkcije. Primerjava je letela na to, da se v plain phpju brez pomožnih funkcij ali classov, obsojaš na dupliciran error handling vsakič in tako velikost kode raste in raste. Še bolj očitno večja koda je ko delaš še benchmarking, logging, itd. Če imaš db class / funkcije, narediš vse to samo enkrat, in potem to velja povsod kjer to uporabljaš. Praktično je minimalna povezava kar se tiče kode, ampak na ideološkem nivoju je princip isti. Zakaj bi vedno delal error checking, ce lahko napišeš funkcijo, ki bo imela isti format in ga bo počela namesto tebe. Zakaj bi vedno pisal <?php … Če lahko uporabiš template class, kater bo pretvoril {v} in druge komande v korektno php kodo.

    V Minitpl dokumentaciji je izpostavljenih par primerov, v katerih je php koda kar konkretno daljša od template kode ({foreach} {else} {/if}).

    Skratka; smiselni primeri rabe templejtingov vsekakor obstajajo, ampak za tipičen razvoj spletnih strani so po mojem mnenju odveč.

    Hm ja, vse je pol na definiciji tipičnosti strani. V 8 letih sem spravil že tolk PHP kode izpod prstov, tako da tipična spletna stran pri meni očitno ne pomeni ravno iste zadeve kot pri tebi :). Zadnja koda, ki sem jo spisal, je imela približno 3.5kb kode, 1kb DAO, pa 3.5KB template. V PHP kodi imam za template vsega skupaj 4 vrstice. Ven pride pa tole:

    http://www.rtvslo.si/oi2008/spored-dogodkov

    In še {include} funkcionalnost mi omogoča uporabo istega templatea, v kombinaciji z DAO objektom iz drugih modulov (praktično, če klikneš na športe v levem meniju, se uporablja DAO in isti template).

    Edini primeri, poleg hitrosti, da sem potreboval it na pure PHP, so bili izvozi in uvozi večje količine podatkov, v XML ali drugače, kateri niso dovoljevali, da bi jih hranil v spominu, glede na PHPjev memory_limit. Na srečo, so taki primeri zelo redki in specifični.

    Me veseli, da si končno bolj argumentiral zakaj se ti zdi template primeren in zakaj neprimeren. Zdaj veliko bolj razumem tvoje stališče, zakaj se ti zdijo neprimerni. Glaven razlog je pomoje ravno v tvojem ORM načinu dela, pa slabi podpori za OOP znotraj templateov, da bi lahko ostal na ORM skupaj s templatei. Drugi razlogi so bolj logične narave, za katere pa obstajajo tako plusi kot minusi v obe smeri. Upam, da vsaj kakšen test minitplja narediš, v povezavi z ORM, ker se mi zdi, kot da je to tista ključna točka, ki bi te lahko prevagala na templating “dark side” :)

  15. black Says:

    P.s. če bi uprašal na konferenci kolk ljudi uporablja ORM, se bojim da bi bil odgovor tak kot pri unit testingu, sam en tip bi dvignu roko :D