Ček, ti si se žalio da ti FW "generiše" neoptimizovane upite. Ja samo kažem da ništa FW "sam" ne generiše, već sam generišeš, samo korišćenjem FW-a kao jezika koji se manje više jednoznačno mapira na SQL. Nema tu magije, SQL je onoliko komplikovan koliko ga komplikovanim napišeš, bez obzira da li koristiš FW ili direktno SQL. Zato kažem da mislim da mistifikuješ celu priču oko FW-a, jer nisam siguran da znaš kako to tamo radi.

Govorim o onim "munjama" tipa belongsTo... hasOne... hasMany, pa razne schema, pa ti kao kreiraš relacije a onda ti "on" sam generiše querije. I ti tvrdiš da ne "ništa ne generiše sam"? Ko generiše mysql, ti ili fw?

^ ti baš ne voliš ORM :)

evo gledam nesto Kohanu, upit:
generise sql:
nije li to debilno? Sam poziv ORM metode je duzi od SQL-a koji bi trebalo otkucati, a generisani upit je pun nepotrebnih stvari, koje u opstem slucaju mogu itekako da pogode performanse, a potpuno su nevidljive korisniku, on nece imati pojma da je upit takav dok se baza negde ne zakuca. I onda pogledas slow query log u bazi da vidis zasto se koci, i nadjes ovaj select, i kako onda u kodu pronadjes sta generise taj select? Nikako, moras da logujes upit po upit dok ne vidis odakle dolazi...

E sad, daleko od toga da sam ja protiv stvari koje povecavaju produktivnost, samo ja na to gledam iz drugog ugla nekoga ko cesto odrzava i prepravlja tudji kod, a ne samo da gleda kako da za sto manje vremena i truda napravi nesto sto koliko-toliko fercera.. ako je efikasnost rada jako bitna, a lose performanse se resavaju kupovinom jaceg hardwera, onda je ORM pristup super..

^ baš to. A ja čak govorim o komplikovanijim situacijama.

ORM ne volim, komplikacija mi je kao i Smarty, koristim CI Active Record klasu.

u modelu funkcija za count npr:

ili get
Beneficije su automatsko eskejpovanje i mogucnost rada sa drugom bazom.

a uvek moze i pisan sql sa eskejp:

Eh, koliko puta sam čuo (pročitao) ovo... nake mi nađe neko jedan jedini slučaj kada je neko krenuo da radi u jednoj bazi i završio na drugoj. Ili nešto mnogo verovatnije, koliko ljudi uopšte koristi nešto drugo od onoga što najčešće koristi (u zavisnosti od firme u kojoj radi). Nemojte da se se zezamo više sa ovakvim argumentima, to je čisto teoretski tipa "a šta ako udari kometa?" a u praksi zakucani ste sa jednom bazom i tu ćete verovatno ostati do kraja profesionalne karijere u firmi.

Kada se radi razvoj aplikacije koja treba da ima mogucnost da radi na raznim bazama onda je ovo pristojno resenje. To da se prebacujes sa jedne baze na drugu u toku rada je nesto sto nisam rekao.
I ne znam sto si uopste umesao ORM u pricu o FW.

U praksi tip je razvijao vBulletin na mysql i onda odlucio da pruzi podrsku za pgsql, oracle itd.
Da li je napravio 4 izdanja ili je koristio db apstrakciju ?

^ mislim da ovde nije baš reč o DB apstrakciji .. a i sumnjam da nisu optimizovani upiti za svaki db tip posebno

@cvele: Opet pričamo o različitim stvarima. Ja pričam o određenom projektu a ti pričaš o izradi frameworka koji treba da daje razne mogućnosti.

@bokica: ja sam samo rekao da mi je svo ok sa FW osim te priče o "automatski generisanim querijima", ništa više od toga.

Aj sad pojasni sta si hteo da kazes :P

Ako si mislio da su pisali po dva+ querija za paginaciju u oracle, mysql etc grdno se varas, to je zesce gubljenje vremena.

Poenta je da za svaku bazu postoji "drajver" (kako ih zovu u adodb npr) koji kreira querije na osnovu pripremljenog (npr) objekta.

Hoću da kažem ako nisu napisali, onda su makar tesitrali svaku stvar na ostalim db serverima, ajde da vidim tog magijaša koji će da izbaci deploy verziju u odnosu na bilo koji adodb driver ili generisanu apstrakciju kroz ORM.

Jednostavno to nije automagicly, a sigurno nećeš da kada radiš iole nešto ozbiljno da bude plug & pray .

To zavisi od konkretnog slučaja, od konkretnog ORM-a i od jezika. Nikako ne može biti neki univerzalni argument za ili protiv.

Kojih? Ja vidim samo ORDER BY koji nisi eksplicitno zahtevao, a to se obično podešava na nivou modela. Svako ko ima imalo iskustva sa ORM-om znaće gde sve može da naglasi konkretan redosled.

Rails u development okruženju štampa sve upite koje šalje na bazu zajedno sa vremenom izvršavanja, trejsovanje stvarno nije neki veliki problem u realnom radu.

Tačno je da FW-ovi uvode dodatni nivo apstrakcije, i nekom to ne prija. Ja samo mislim da u većini slučajeva objektivno nemamo potrebe da brinemo o tome šta se tačno događa ispod, u suprotnom bismo svi još uvek pisali CGI aplikacije u C-u ili asembleru.

samo treba znati sta ti je cilj, pa odabrati alat za to. Ako neces menjati bazu, zasto bi onda koristio db apstrakciju koja svaki poslati upit prvo preparsira na sitne delove, prilagodi trenutnoj bazi, pa tek onda posalje. Em je sporo, em ume da bude uzasno ogranicavajuce..

Recimo dok sam radio na Vivvu sam imao milion puta probleme sa MDB2 klasom koja ne podrzava razne mysql ekstenzije standardnog sql-a. Pa onda, kad radis paginaciju, umesto da posaljes jedan upit koji ce ti odmah vratiti i koliko ima rezultata, ti moras da saljes 2 upita, kad kreiras tabele u instaleru, malo radis preko MDB2 , a malo moras rucno da pravis upite, jer neki tipovi podataka nisu podrzani, jer nisu standard...

A da povezem ovu pricu sa FW, moja glavna zamerka vecini koje sam video je sto idu presiroko i preambiciozno u smislu da budu sve za sve situacije. To naprosto (jako cesto) ne pije vodu, i onda umesto da nesto brzo odradis u 3 linije koda, moras da se rves sa samim sistemom, pises kontrolere, hookove, napravis 4 klase da bi uradio najprostiju stvar.

To naravno nije problem FW kao koncepta, nego konkretnih realizacija koje su na trzistu... nista dok ne napises sam svoj... with blackjack and hookers :)

Bravo! :1043: Ja trtljam vec 2 strane a ti objasnis u 2 recenice.

^
:):)
O tome ja tupim od prvog posta. Zato sam i pito jel ima neko konkretan primjer aplikacije koju je radio, jel zadovoljan itd...

Potpuno se slažem sa ovom izjavom (:1043:) iz razloga što koliko sam ja uspeo da primetim većina PHP framework sistema pokušava previše da se fokusira na abstrakciju konkretnih komponenti sistema (što je potpuno paradoksalno) i da ih učini što je moguće proširivim, umesto da se fokusira na proširivost jezgra sistema, tj. onoga što je u suštini najbitnije za osnovni layout aplikacije i njegovo brzo prilagođavanje potrebama razvoja. Posledica toga je veoma loše delegiranje odgovornosti osnovnih klasa koje jednostavno pokušavaju da budu previše generičke i da odrade što je moguće više iako realno većina funkcionalnosti koje nude nije neophodna u konkretnim projektima.

Da se vratim na osnovno pitanje, radm u CI i ZF.
Prednosti CI su ti naveli, a mane koje meni smetaju su:

• PHP4 kompatibilnost (nema auto loada i magic funkcija)
• nema gotove Authentication klase
• relativno spor razvoj
• relativno slaba striktnost u nazivima
• losa reseno pravljenja osnovnih klasa

Na CI se odlucio zbog togo sto mi je najvise licio na kod koji sam sam razvijao i upotrebio, ali na kraju sam digao ruke jer je logika bila da ce nekoliko hiljada ljudi pre naci gresku u nekom parcetu koda , nego sto cu ja videti to isto u svom. Ne slazem se sa bluesmanom do moram da znam kako funkcionise kod da bih ga koristio, jos manje me je interesovao Smarty. Bitno je da radi ono sto se od njega ocekuje i na nacin na koji se ocekuje.
Takodje smatram da je Smarty gubljenje vremena, i da je dovoljan cist php. Da se razumemo Smarty je dobro zamisljen ali po mom misljenju nepotreban, jer dosad niko dizajnera nije naucio da kodira, kao so ni jedan porgamer nije postao dobar dizajner, cak sta vise ne bih ga preporucio pocetnicima jer im je tesko da shvate kako to funkcionise.

Kohanu sam isprobavao ali me je razocarao njen View, koji ne funkcionise onako kako sam ocekivao. Mozda nisam dobro radio. Ostalo joj je ok, ima ACL, module i ORM.

Cela ova rasprava oko toga da li je ORM potreban ili nije zavisi od potreba i znanja korisnika. Onaj ko zna da napise dobar sql nece koristi orm, stvar izbora.

U firmi koristimo Zend, koji radi na sajtovima koji imaju 15M poseta mesecno. Ono sto mi se svidja kod Zenda je velika modularnost i mogucnost podesavanja. Ne svidja mi se sto svi tutorijali lose pokrivaju sam pocetak i podesavanje.

zasto svi smrtnici vole da govore da je nesto nemoguce samo zato sto oni to ne znaju.

Od kako radim sa Smarty-ijem, skoro uvek dizajner sredi templejtove. U krajnjem slucaju ja napravim genericke i dizajner ubaci html/css. A ljudi koji sada rade kod mene u firmi poznaju smarty fantasticno, a veze nemaju sa programiranje.

Drugo, ja sam smarty BUKVALNO kao pocetnik u programiranju i PHP-u poceo da koristim (na nagovor zombi-a) i kao osobi sa 2 meseca iskustva trebalo mi je pola sata da shvatim i pocnem da koristim smarty.

Ovde se ne radi da li je neki FM tezak ili lak za shvatanje. Meni nijedan nije tezak, samo su mi neki ocajni jer su pravljeni po ukusima programera koji su ih razvijali a ne po mojim ukusima.

Ja ne volim ORM i slicne principe. Jednostavno volim da vidim sql u kodu. A s'obzirom da jako retko radim neku aplikaciju od nule, i da su to samo aplikacije za moje potrebe (cms-ovi), klasican gotov FM meni licno nista ne znaci. Vec imam sve sto mi treba razvijeno, ili od mene licno ili na netu (swift, smarty, phpthumb..)

Rekoh da sam proveravao šta generiše jer mi je optimizacija bila jako važna, a to "kako radi" mi se vuče još od detinjstva kada nisam imao ni jednu igračku duže od par dana jer sam "morao" da je otvorim da vidim kako radi. To je samo običan moj "trip" :)

Da ne pričamo šta je smarty i čemu služi, ali činjenica je da on nije samo za dizajnere. Možda je to stvar navike, ali daleko mi je pregledniji smarty view nego neki php prepun <?php ?>, koliko god koristili skraćene tagove.

Kažeš "niko dizajnera nije naučio da kodira", možda je i to tačno, ali je zato "mulijarda" (keyword) dizajnera naučila da koristi smarty i lako razume šta je foreach, šta je if - else. Ne verujem da je iko imao planove da uči dizajnere da kodiraju, niti su dizajneri imali puno entuzijazma za učenje, ali su i jedni i drugi srećni što su se našli "negde između". Osim toga, daleko je lakše i dizajneru da koristi smarty tagove nego da mu daš neki "čist php" view da od pravi template. Takođe ne znam sa kakvim si početnicima ti radio, ali oni sa kojima sam ja imao posla su naučili lako smarty za par dana.

Osim toga i sam kažeš "Ne slazem se sa bluesmanom do moram da znam kako funkcionise kod da bih ga koristio", a u sledećoj rečenici kritikuješ smarty "...ne bih ga preporucio pocetnicima jer im je tesko da shvate kako to funkcionise", pa jel' onda važno ili nije važno da se zna kako to funkcioniše da bi mogao da koristiš? Mislim da smarty dizajneri znaju sasvim dovoljno, i više im nije ni potrebno osim ako nemaju neku izrazitu želju da vide "šta je unutra".

Ispadne da smo debili mi koji koristimo gotove FW-ke jer ne znamo da napisemo svoj i sto smo potrosili vreme u ucenje nekog suvise komplikovanog i nepotrebnog sistema.
A za Smarty jednostavno nema suvise mesta kada se koristi FW jer te FW tera da programiras pravilno tj PRE outputa.

To što ti tvrdiš da ispada da ste debili - to nije tačno da je bilo ko rekao. A i to za smarty takođe nije tačno - očigledno ne znaš šta je smarty i čemu služi.

Svako koristi to sto mu odgovara.
Respekt.

Ja priznajem da lično nisam neki preterani ljubitelj Smarty-ja ali mi se sviđa stepen kontrole parcijalnog keširanja stranice koji je u njemu implementiran. A kad smo već kod teme mešanje template i framework sistema interesantno je da CodeIgniter recimo ima sopstveno template rešenje koje ne funkcioniše tako loše iako sami developeri preporučuju da se zbog brzine parsiranja stranica koristi čista alternativna PHP sintaksa što je generalno i neka moja preporuka jer iskreno još uvek nisam sarađivao sa "čistim" web dizajnerima koji nisu bili u stanju da veoma brzo "prokljuve" alternativnu sintaksu.

Ako si probao Smarty onda znaš da se on razlikuje od većine ostalih template sistem u po tome što parsuje template samo jednom i generiše čist php, tako da se izvršava "čist" PHP. Ostali parsuju template svaki put kada se zahteva (što može i Smarty ako mu je uključeno force_copile, ali to je besmisleno).

Sve ovo pod uslovom da sam razumeo šta znači "čista alternativna PHP sintaksa". Nešto mi ne idu zajedno reči čista i alternativna. :)

i stvarno niko nije rekao da ste debili vi koji koristete FW-e. Svi, koji smo protiv, smo naglasili da smo protiv zbog licnih afiniteta. Jednostavno mi je cake odvratan na primer. ZF ima preterano velike interne zavisnosti za moj ukus, CI nisam gledao..

Bukvalno sam mislio na čistu alternativnu sintaksu (http://php.net/manual/en/control-str...ive-syntax.php) neizmešanu sa raznim tagovima specifičnim za klasične template sisteme pa i za samu CI template klasu. S obzirom da je alternativna sintaksa potpuno integrisana u jezgro PHPa njenim korišćenjem se po meni generalno eliminiše potreba za bilo kakvim parsiranjem template fajlova čisto da bi se dobio ponovo "čist" PHP kod pa makar on bio i keširan. Ono što mi se kod Smarty-ja svidelo je mogućnost parcijalnog keširanja stranice ukoliko je ona sastavljena iz podšablona (zaboravio sam već pravu terminologiju i nazive) tako da se u kompleksnijim slučajevima kada su stranice sastavljene iz dosta elemenata koji se ne menjaju često ovo može da bude poprilično interesantno za povećavanje performansi.

Doduše priznajem da nisam jako dugo radio sa Smarty-jem i da se dosta stvari u međuvremenu verovatno promenilo tako da moram da se ogradim od daljih komentara koji verovatno ne bi bili na mestu.

S obzirom na moje iskustvo sa symfony frameworkom nešto mi ova rečenica ne uliva preterano poverenja.

@holodoc: Smarty se nije menjao godinama, ako kažeš da nisi odavno probao to znači da nisi probao od početka jer se oduvek template "kompajlira" u čist PHP :) Sada se sprema smarty 3, koji je napisan za PHP5 i daje još bolje rezultate za izvršenje scripta (testirao sam).

Nisam znao da se to zove "čista alternativna PHP sintaksa", ali umesto da cepidlačim samo da samo hteo da ti kažem da Smarty baš tako "kompajlira" .tpl u PHP. Takođe u Smarty 3 imaš i novi builtin resource "php", pa možeš da koristiš čist PHP kao template, na primer ovako:

Ako to koristiš, onda se taj PHP ne kompajlira već direktno include-uje, što i jeste jedino razumno rešenje u ovom slučaju. Samim tim izbacuju se avi argumenti protiv Smarty sintakse jer sada ko želi može da koristi čist php kao template.

Znači, ja nisam protiv FW, i ja koristim (svoj) FW, ali sam protiv tih "all-purpose" stvari koje su otišle preširoko. Više mi se sviđa Wordpress kao framework jer je specijalizovan za jednu stvar (+- par stvari koje zavise od znanja i veštine developera) nego ti super-wide koji će sve da urade umesto tebe.

Možeš li da obrazložiš u par rečenica zašto? (Samo me interesuje šta ti se konkretno kod njega nije svidelo)

Ja sam počeo da ga koristim nedavno i mogu reći da sam prezadovoljan njime. Logika koju koriste je dosta slična mojoj i prilično mi "leži", ima svoj "bakery" koji je prilično moćna stvar. Pored generisanja modela, kontrolera i view-ova, ima par još jako dobrih stvari. Kod koji se izgeneriše se može jako lako promeniti, sam framework je pisan da završava neke stvari, a ne kao ZF koji je po meni pisan da bi se mogao proširiti pa tek onda završiti neke stvari, cake isto tako ima veliki comunity i mnoštvo već gotovih komponenti, a pored toga ima i svoje komponente koje prilično ubrzavaju stvari. Auth komponenta recimo sa 3 linije koda završava bazičnu autorizaciju korisnika (ovo je samo jedan od primera, kojih ima mnoštvo). Ima ugrađenu lokalizaciju koja radi odlično. Sve u svemu klasičan CMS od "nule" se može napraviti za jedan radni dan, a to je ono što je meni bitno.

PS. video sam negde i komponente koje povezuju Smarty, tako da se i Smarty može koristiti.


Pozdrav.

@bluesman
Hvala na iscrpnim informacijama ali ja nisam nigde ni sporio da se Smarty template fajlovi "kompajliraju" ;)

Ne volim sto se ovde ljudi olako etiketiraju kao neiskusni i obicni smrtnici. Nije prvi put. Skoro da mi je cast da pricam sa nekim neobicnim ;) Takodje mi smeta sto je tema otisla u Smarty je dobar / nije dobar. Bilo toliko puta pricano u raznim temama koje veze nisu imale sa istim na pocetku.

Dizajneri o kojima sam pricao su pravi dizajneri, ne ovi koji znaju da kodiraju i poznaju fotosop i kradu tudje tempalte i menjaju im boje i slike, pa sebe nazivaju dizajnerima. To sto sam rekao da neshvataju kako funkcionise odnosilo se na to da ljudi kad pocnu da rade sa smartijem obicno traze nacin kako da ubace malo php koda u smarty template, umesto da sve to pripreme pre samog ucitavanja templatea.

To sto neko kaze da je neki fw velik, a da ako radis sam sa svojim fw + smarty + gomila skripti za svasta nesto, neka ponovo razmisli sta je vece, i koliko je to nezavisno od promene koda prilikom updatea. Da li je lakse ispratiti jedan update za ceo fw ili za x skripti koje su inkludovane.

inace iza mene stoji oko 35+ freelance projekata, nekom mom cmsu i sve to pod smartijem. Teskom mukom sam odlucio da sve to napustim i probam neki fw, i onda skontao da je CI vrlo slican onome sto sam radio samo mnogo urdnije napisano.

Ako me sećanje ne vara upravo si ti okrenuo temu u smeru smarty je dobar / loš izjavom "Takodje smatram da je Smarty gubljenje vremena", drugi su samo spomenuli da je i Smarty u stvari FW.

Ako si odlučio da napustiš "neki tvoj cms i sve to pod smartijem" u korist nečega u čemu se osećaš bolje, onda je to super stvar, ali ne bih rekao da je Smarty kriv za to što si odlučio da sve to napustiš. Ostatak nisam baš razumeo šta želiš da kažeš, naročito drugi paragraf, samo bih prokomentarisao ovo:

Da, naravno da je "lakše ispratiti jedan update za ceo fw" kada ti očekuješ od drugih da to rade. Nadam se da nećeš pogrešno razumeti ovo jer ne mislim na tebe lično, ali po meni je tu razlika između "php programera" i "php korisnika". Ovi drugi liče na dizajnere koji koriste Photoshop i imaju instaliranu gomilu pluginova, glavna prednost im je što znaju sve filtere, uglavnom rade sa stock photos i clipart-ima ali imaju poteškoća kada treba da krenu od praznog canvas-a. Tako i "PHP korisnici" izaberu neki FW, nauče da ga koriste, submituju bug-ove, čekaju fix-ove, redovno rade update FW, kada im zatreba čak i neka sitnica -prvo će da potraže da li ima već nešto gotovo, neki plugin ili nešto slično, pa tek ako ne mogu da nađu ili im ne odgovara, razmišljaju o tome da pišu sami, a onda se i razni forumi pune temama "imam problem da ...". Kada nastane problem sa FW (neki exploit ili nešto) automatski su svi ranjivi, i što je poznatiji FW to je veća mogućnost da će neki da "iščačka" nešto.

Naglašavam da je i jedno i drugo legitimno i ja nemam nikakav problem sa tim, niti želim da kažem da je jedno dobro a drugo loše, samo volim da istaknem razliku. Ima ljudi koji prave čuda u wordpress-u i imaju jako dobre sajtove, a u PHP znaju da napišu tek one osnovne stvari. I to je super, ali da li onda pričamo o "programerima" ili "userima"? Ja mislim da i oni sami za sebe ne govore da su programeri. Oni su jako dobri "korisnici" jako dobrog FW, pa čak i ako "programeri" progunđaju kako je WP ovo-ono, svi ti kontra-argumenti padaju u vodu kada vidiš koliko su ljudi srećni sa WP.

Iz svega ovoga sledi zaključak, ako nekome (nekim čudom :) ) još uvek nije jasno šta ja mislim o ovome: Frameworks su super stvar, ali preferiram specijalizovane FW pre nego "all in one" rešenja koji će da rade sve umesto tebe. To naročito važi za velike projekte.

Što se tiče same teme vidim da većina ovde koristi CI.
Kako se snalazite za autentifikaciju/autorizaciju, layout, parcijalno keširanje view-a? Da li koristite eksterna rešenja za to?
Vidim da Zend ima sve tri nabrojane funkcionalnosti i još gomilu korisnih svtvari, ali ga u ovoj temi gotovo niko i ne pominje. Nailazio sam na primedme da je spor za high-load sajtove, međutim kako sam u zadnje vreme radio par srednjih(15-20.000 pageloada dnevno) nisam primetio nikakve probleme u performansama. Da li je neko od vas imao probleme sa performansama Zenda?

Kompletno mi deluje i Yiiframework, bar nakon proučavanja dokumentacije, mada mu je zajednica znatno manja nego kod CI i ZF. Nisam još stigao da ga isporbam.

vecinu zend fora mozes da koristis i bez zend FW, tako da ne postoji neki problem da na primer u Kohanu ukljucis nesto od zend modula

Super što si spomenio Kohanu. Ako većina ovde koristi CI, onda želim da ukažem na neke nedostatke CI fw.

Ci je "zakucan" za PHP4, i ne koristi brojne prednosti koje nudi PHP5 kao

- autoload klasa
- abstraktne klase (CI Stalno kreira objekte pro podizanju, da se srediti ali nije ovo jedini nedostatak)
- interfejsi
- CI ne koristi izuzetke, naravno vi možete da ih primenjujete niko ne brani, ali jednostavno nisu integrisani u sam fw.


Zato i želim da ukažen na Kohanu verzija 2 koja ima dosta sličnosti sa CI-jem,
i verzija 3 koja je praktično razvijena "od nule".

Umesto konstantnog prenošenja CI objekta koji je dostupan u svakom objektu, doduše preko refernce, u PHP-u 5 bi pandam tome bili singlton objekti.

Problem sa CI jem je i ako se javi potreba čuvanja ili serijalitacije objekata, koji za sobom "vuku" gomilu podtata vezanih za CI objekat a da oni zapravo nemaju nikakvu vezu sa tim objektom.

Počeo sam da radim sa Kohanom posle Ci-ja, i ima ove prednosti koje sam spomenuo. Voleo bih da čujem nekoga ko ima iskustva sa oba fw, njegovo mišljenje.

Opet malo sam bacio oko i na symphony a zbog admin generatora, ta ideja sa auto generatora si me dopada i malo sam se igrao sa nekima koji koriste yml fajlove za to, pa i o ovom asprektu u fw bi voleo da prodiskutujemo.

ja od decembra radim intezivno na odrzavanju jednog velikog sajta pisanog u kohani, i nemam neke velike zamerke, osim sto mislim da je pola fora i helpera nepotrebno.. ali anravno niko te ne tera da to koristis..

a inace postoji isti problem koji spominjes i u Kohani, uradis print_r() rezultata nekog DB upita i dobijes izlistan i kilometarski Database objekat, jer se cuva referenca.

Nisam znao da resultu čuvaju DB objekat, očekivao bih da sve ide preko instance metode. Mislim da bi to bilo ispravnije, ali da ne idemo suviše u detalje da ne odemo offtopic.

Višak helpera pa dobro to nije problem, glava ne boli.

Sada sam se setio da ima nešto što mi se i ne dopada previše kod kohana 3 verzije a to je sledeće.

Ako klasu smestmo u classes/dir1/dir2/drivers/klasa.php

moramo je imenovati ovako Dir1_Dir2_Driver_Klasa

sada da ne bismo koristili klase sa ovako glomaznim imenima, možemo da uradimo sledeće, napravim u classes folderu klasu Klasa
Klasa sa praznim telom je tu samo da skrati naziv. Jasno je da je ovo urađeno zbog auto loada, ali ovaj deo me nije oduševio.