Gde si nas'o smarty... ugh. No, tvoj licni izbor, ne petljam se u to :)

IndexController.php za default module ti izgleda:


a IndexController.php za admin module ti izgleda:


Verujem da ce ti to resiti problem. Sad, da li ce smarty redovno da vuce templejtove, to vec ne znam.

Edit: Prosetaj se po mom blogu, nacices tamo svasta nesto dobro za zf ;)

Čekaj, nemoj mi reći da postoje pravila dodeljivanja imena admin kontroleru... :S Au brate nikad to ne bi izvalio. Hvala ti puno!

Da, gledao sam tvoj blog, odličan je kao tutrorijal za ZF. Svaka čast. Tu sam i video tu "caku" za postizanje modularnosti u okviru ZF-a. I znao sam da ćeš mi ti prvi odgovoriti na ovaj problem, jer vidim da se već dosta dugo baviš ZF-om.

Nemoj da mi diraš Smarty. :P Šalim se, naravno, ukusi su različiti, ali meni on sasvim odgovara. Mada, u kombinaciji sa ZF-om, nekad ume da napravi problem, jer kad imaš više tih Index kontrolera, eto npr. u default i admin modulu, često zna da se desi da on iz onog njegovog keša (templates_c) dovuče pogrešnu stranicu iz keša, npr. zameni index stranicu default modula sa index stranicom admin panela, itd. A čini mi se da postoji samo jedno rešenje za taj problem, a to je da za svaki modul praviš poseban folder za kompajliranje (podfolderi u templates_c), i onda nema problema. Ja to radim tako što u init() f-jama kontrolera samo set-ujem taj compile dir Smarty-ju, preko ove Templater klase. Možda ti znaš neko elegantnije rešenje?

Sa tim Admin_ mu dodajes samo putanju. Klasa unutar IndexController.php u default modulu se zapravo treba zvati Default_IndexController, ali se moze izostaviti jer ce ZF sam tamo da potrazi. Jednostavno, za naziv klase moras prepend-ovati ime modula sa velikim pocetnim slovom.

Potrosi dan-dva na citanje ZF wikija http://framework.zend.com/wiki/display/ZFDEV/Home i coding standarda http://framework.zend.com/manual/en/coding-standard.html mnogo ces toga videti i pohvatati odatle.

Takodje predlazem da procitas i predlog za ZF strukturu fileova i foldera http://framework.zend.com/wiki...oject+Structure+-+Wil+Sinclair

Koristi Zend_View i Zend_Layout. Nije na odmet to sto znas smarty (znam ga i ja, uzalud potrosenih nekoliko dana xD), ali _View i _Layout u kombinaciji sa ostalim komponentama su jako mocni (_Form, _Cahce, pluginovi, helperi). Smarty ti dodje samo kao jos jedan sloj, koji je po meni nepotreban. Verujem da znas i sam da PHP ima svoju "template" sintaksu, ili kako se vec zove, tako da view scripte nisu nista manje citljive nego u slucaju kod smartyja. Ako znas kako da povezes smarty sa zf-om, ok, drago mi je, al moj savet je da radis sa _Viewom.

Aha, znači za sve admin kontrolere, pa i za sve ostale kontrolere specifičnih modula (koji nisu default) bih trebao da stavljam prefiks.
Čudan je taj Zend, al' mnogo je moćan. Mada može i te kako da "zakomplikuje život" na manjim projektima...

E što mi neko nije davao da čitam takvu "lektiru" u srednjoj školi...

Što, jer ova moja struktura loša? Ne, ali koliko sam shvatio, vidim da dosta varira ta struktura projekta, valjda svako ide onako kako mu odgovara, a i u zavisnosti od zahteva samog projekta. Ova moja mi se nekako činila logičnom... Barem za početak...

Ma da, ali ne znam kako bih ti rekao, meni je nekako ružno kad vidim to mešanje PHP-a i HTML-a. Zar nije bolje ovako: {$foo}, nego ovako: <?php echo $foo; ?>. Šta ja znam, opet kažem, to je sve subjektivna stvar. Ja sa nekako trudim da PHP, kao napredan jezik, NE koristim za ispis nečega, aj' tako da kažemo, "nenaprednog", kao što je (x)HTML, a je upravo ono što Smarty omogućava. Doduše, kompajlirana verzija je opet to mešanje PHP-a i HTML-a...

Struktura ti je ok...

Takodje glas za php short tagove.

Jer {$foo} i <?=$foo?> su prilicno slicni, plus ako ti nekad zatreba nesto da ispravis na brzinu uvek mozes da ubacis <?php ...?>

U bre, sad sam 1 prema 2. :) Dobro kad vi tako kažete...

Ne daj se Nikola, podrzimo smarty kao takav :)
Salim se, ali i ja ne volem nikako da vidim taj php unutar. Neznam kako bi se recimo {head}{/head} plugin uradio sa php tagovima?
Mislim, to mi sad jedino pada napamet ovako zarad diskusije, taj plugin se moze ubaciti i na kraju bilkog templejta, a smarty ga posle prebaci tik ispred </head> taga. To mu je lako jer parsira ceo doc trazeci delimitere, kako bi to recimo radilo sa php tagovima? I slicni primeri sa takvim pluginovima/blokovima koji koriste parsiranje sklopljenog dokumenta.
Korisno kada recimo u nekom modulu treba uvuci neki poseban css i/ili js u head tagu...

Aha, šta ćete sad?

Šalim se, (mnogo se ja šalim na ovoj temi ), ali eto kad smo kod head sekcije, ja za te svrhe ubacivanja dodatnih stilova i js-ova, ili samo promene title-a stranice koristim ovu moju malu klasu HeadGenerator. Npr. evo sad kad radim sa ZF-om, za sve kontrolere jednog modula imam jednu "međuklasu" (CommonController), iz koje se izvode ostali kontroleri, i ona samo služi za neko inicijalno set-ovanje kontrolera. Ta klasa je apstraktna i izvodi se iz Zend_Controller_Action, i ima samo jedan metod init(), u koji ja "natrpam" sve što je zajedničko za kontrolere, npr. podešavanje CSS stila, ovako:

Zatim set-ovanje onog Smarty-jevog compile foldera (za svaki modul mora poseban folder):

Pa onda recimo, konkretno, za ovaj primer što sad radim, pošto podatke u sidebar meniju vučem iz baze, onda ide komunikacija sa nekim modelom, koji će da vrati niz, i koji ja posle ispisujem u template-u, itd.

I sve to stoji u toj init() f-ji, i onda kad se neki kontroler izvede iz te klase, on samo u njegovom init-u pozove ovaj nadređeni metod i po potrebi odradi još nešto, npr.

I posle samo u nekoj akciji pošaljem Smarty-ju ono što Head Generator output-uje, a to je cela head sekcija:

A onda u template-u uvek prvo ispišem tu promenljivu koja sadrži head sekciju:

I onda već imam ispisan onaj deo počevši od DOCTYPE-a, pa do zatvaranja head-a (</head>).

U jeeee... Pogledajte ZF-ove view helpere, ima sve sto treba za te vase headove :P http://framework.zend.com/manual/en/zend.view.helpers.html

Nikola, sto ne drzis CSS fileove u public folderu, i onda mozes stilove pozvati sa, na primer: /css/default/style.css? Ovako ti kod svakog novog zahteva imas dodatne pozive, prvo za request pa posle za baseUrl. OK, super, CSS ti je tamo gde su i sabloni, ali opet... ZF je i ovako spor (procitaj ovo za optimizaciju http://www.survivethedeepend.c...or.zend.framework.applications), nemoj jos vise da ga usporavas :)

Inace, i ja tako radim da imam jednu "master" klasu, samo neki kazu (cuj neki, ljudi koji prave ZF :D) da je to losa praksa i da sve to treba odraditi preko pluginova i helpera. Nazalost, u poslednje vreme nikako da stignem da se poigram stim.

Zasto bi koristili neke dodatne komponente/klase/biblioteke kada sve to imate u ZF-u? Naravno, pod pretpostavkom da koristite ZF kao celinu, a ne samo neke njegove komponente.

Edit: Na vam smartijevci http://nosmarty.net/ :P

_{[Ovu poruku je menjao kazil dana 30.03.2009. u 12:36 GMT+1]}

Ma to sad samo zbog ovog projekta nešto isprobavam, jer hoću da omogućim da se iz admin panela jednim klikom menja cela tema sajta, pa mi je zato bolje da te CSS-ove vezujem za konkretnu temu, a u public/css bih držao samo neke custom CSS-ove, tipa za kontakt formu, itd. Jer recimo u tom folderu default/templates/themes bih držao nekoliko tema (tema1, tema2), i onda mi je nekako bolje da CSS određene teme bude u tom istom folderu...

@Nikola, kazil

Pristup koji koristite nikako nije dobar i narusava MVC, moze da stvori niz problema narocito na malcice vecim projektima. Jednostavno realna potreba za tim ne postoji...



Ako procitas ovo sto si napisao uocices da je uloga kontrolera u ovom slucaju minimalna ili je nema at all. Stoga sve ovo moze da ide u neki helper koji ce to da odradi za tebe i koji ces da pozoves u view-u.

Sta vam tacno radi head generator ili kako se vec zove nemam pojma ali je prilicno besmisleno jer ta klasa moze da se svede na par linija koda, pa je apsolutno logicno da to bude helper...

Uz duzno postovanje, ovo ti je apsolutno nepotrebno:




Postoje ali jednostavno neke stvari nisu dovoljno dobre tj, mogu biti bolje :P Recimo mnogo nas koristi doctrine neki propel jer imaju svoje prednosti. Ali nema potrebe da uvlacis recimo 3d party lib za openID kad ZF-ov je ok




Sa ovim se nikako ne slazem, jednostavno sasvim je razumljivo da ako lose projketujes app ma u cemu da ga pises ce raditi sporije nego sto bi trebalo. Takodje jasno je da stvari kao autoload usporavaju rad i taj racionalno da kesiras stvari ako za ti imas potrebu...
Danas su serveri prilicno mocni i ZF radi perfektno i savrseno brzo, poenta je samo kako se koristi!

Sa datom kolicinom znanja i pre svega iskustva, u datom vremenu, to mi se cinilo najboljim resenjem :) Pre nesto jace od godinu dana, mislio sam da je ZF (ili bilo koji fw) potpuno nepotrebno... A sad... Jbg, uce se ljudi :)

Ako ti nesto nije dovoljno dobro, a ti napisi kako bi trebalo pa ubaci u repository :P

Sa kojim se neslazes? Sa mojom tvrdnjom da je ZF spor ili sa savetima za optimizaciju? :) Lose sam se izrazio... Nije spor, ali moze biti brzi, zato ima tih saveta za optimizaciju. Ali ti saveti nisu usko vezani samo za ZF, vec i za sam php i apache.

Zasto kazes da autoload usporava? On je upravo tu da se izbegnu "milioni" require-a i include-a, koji najcesce imaju za rezultat gomilu ucitanih fileova, ali nikad iskoristenih. Ako ti je Zend_Loader previse spor, mozes iskoristiti i najobicniju __autoload() funkciju, ne? :)

Ovo je vec druga stvar, nisam se inicijalno slozio sa tvojom konstatacijom da je spor.



Mislio sam prvenstveno na Zend_Loader::registerAutoload(); ne na kompletan Zend_Loader ili autoload f-ju.



Haha, mislim da ubacivanje OR mappera kakav je doctrine ne dolazi u obzir za pocetak!

Ok, eto u tom cilju sam napravio dodatni plugin (f-ju) za onu SmartyTemplater klasu (ipak sam rešio da se držim Smarty-ja ), koji samo instancira taj moj glavni model, a ovaj zatim dohvata te elemente menija iz baze u vidu niza, koje ja posle ispisujem. Posle u template-u samo napišem {sidebar_items} (tako se zove ta f-ja, odnosno, plugin). Eto ja mislim da je to, na neki način, imitacija helper-a.

I ti sad kažeš da je bolje da na sličan način napravim i helper (plugin) za head sekciju... Aj probaću i to, mada ne vidim zašto je baš toliko loše koristiti i ovu moju pomoćnu klasu (HeadGenerator).

Nisam rekao da je bas toliko lose, al ajde :)

U svakom slucaju zasto je pametnije koristiti helper:

Nema potrebe da ga instanciras u svakom kontroleru, pozivas ga samo u templejtima ili delovima istih u kojima ti treba.
Istovremeno ga instanicaras i dobijas rezultat, pises manje koda...

Upravo sam uradio onako kako savetuju: nema "medjukontrolera", vec svaki kontroler nasledjuje direktno Zend_Controller_Action, a ono sto sam imao u "medjukontroleru" sam prebacio u Action Helper-e i osim sto mi je mnogo jasniji kod, dobio sam i oko 0.1 sekunde na svakom zahtevu. Nije nesto, al' je brze.

Super, plus mislim da je pametnije i za dokumentaciju :P



Sa cime (ili na koji nacin) testiras, meris!?

Hehe, sa najobicnijim starttime - endtime klasicom, microtime() :) mislim, znam da je daleko od merodavnog, al eto... Desavalo se da kad dodam nesto novo, izvrsenje skoci za 1-2 sekunde (LEFT JOIN bejbe!), pa malo optimizujem upit i kod i eto ga ponovo na "normali" :)

Planiram instalirati xdebug i snjim proveravati (cackao sam bio nesto to na windowsu, al mi je pucao apache zbog njega, sad radim na linuxu, mozda ce biti druga prica), a i nedavno je izasao ovaj http://jokke.dk/blog/2009/01/introducing_the_scienta_zf_debug_bar plugin za ZF, ispisuje vreme izvrsenja, broj kverija i tako neke sitnice.

Evo mene opet sa problemom... :) Ovog puta je baš bizaran. :S

Naime, već sam vam rekao da radim sa Smarty-jem, pa sam između ostalog napravio jedan helper, odnosno Smarty plugin, koji samo treba da mi output-uje ili login formu, ili link za logout, u zavisnosti da li je korisnik prijavljen ili ne. Kod izgleda ovako:

E i sve to radi super na dva kontrolera, ali na jednom trećem - nikako! Sad uopšte ne mogu da odem na taj kontroler, jer se uvek baci onaj izuzetak Invalid controller specifed (error), jer verovatno dolazi do neke greške, ali koje, pojma nemam.

Nekako sam otkrio da tom kontroleru "smeta" baš taj helper, jer kad obrišem poziv tog helpera u templejtu, sve je ok. Onda sam uzeo da brišem liniju po liniju iz tog helpera, da bih dobio malo konkretniji uvid u problem, i otkrio da problem pravi baš ta linija koda: Zend_Auth::getInstance()->hasIdentity(). Tačnije, poziv metoda hasIdentity(), jer kad njega obrišem, opet je sve ok, i templejt se lepo output-uje. :)

Neverovatno mi je to da je na ova druga dva kontrolera apsolutno sve ok, i uopšte im "ne smeta" taj helper (plugin).

Onda sam pokušao da konačno napravim i taj Error kontroler, da me ne bi smarao za taj izuzetak, i posle toga, kad sam pokušao da otvorim stranicu tog problematičnog kontrolera, dobio sam ovu poruku:
Cannot send headers; headers already sent in, itd. I da, znam da se ta greška u 99% slučajeva javlja zbog nekog "praznog znaka" pre <?php ili posle ?>, ali proveravao sam sve, nije do toga...

Stvarno ne znam šta mu je, već celo jutro se nerviram s tim...

Evo juče probao da uključim i ono bacanje izuzetaka na Front kontroleru, da bih dobio još malo konkretniji uvid u taj moj problem, i sad se baca ovaj izuzetak: Session must be started before any output has been sent to the browser; output started in, itd. I uporno mi govori da je output startovan na prvoj liniji tog mog kontrolera, a tamo stoji samo otvoren <?php tag! Neverovatno...

Probao sam namerno na Index kontroleru da stavim jedan prazan red ispred <?php, i stvarno, baci se taj izuzetak, ali proverao sam taj moj drugi kontroler, takvih praznina nema.

Ne znam, ovo mora da je neki bag, ili u ZF-u ili u Smarty-ju...

Hehe, tesko da je u ZF-u :P

Nadam se da nigde nemas closing tag ?> to zna ponekad da pravi probleme. I nadam se da ti editor nije podesen na UTF8 with BOM xD

Da nemas poziv helpera u templejtima!?

Jbt nećete mi verovati šta je bio problem, evo upravo sam provalio... :) Sad sam malo Google-ao na temu ovog mog problema i slučajno video da je neki lik spominjao encoding. I ja aj' da proverim koji je encoding postavljen na tom mom kontroleru, i vidim UTF-8. :S I ja odma' promenim u UTF-8 without BOM, lupim reload u Firefox-u, kad ono - radi! :D

Neverovatno, nikad mi to ne bi palo napamet...

Pa ja uvek pišem ?>, tako sam navikao.

I da vidiš, taj BOM je bio problem, moraću sad da pazim gde klikćem kad set-ujem encoding. :)

Jao koji blam, ne mogu da verujem da sam zbog toga pravio dramu na ovoj temi. U svakom slučaju, hvala obojici za angažovanje u vezi ovog problema... ;)

Najlakse za provaliti da li imas nesto pre bilo cega jeste da pogledas u source u browser-u.

Znam da si navikao da stavljas ?>, ali Teh Manual kaze http://framework.zend.com/manu...ndard.php-file-formatting.html :P

Edit: koji editor koristis?

Jao što volim te coding strandarde... :D Ja sam za ono što forsira XML - svaki tag mora biti zatvoren, i tačka! :P :) Šalim se, dobro, ali pazim ja na te "trailing white space-ove", odnosno, trudim da mi kod bude što uredniji, tako da ne verujem da bi mi ikad to napravilo problem.

NP++, što? :)

Heh mislio sam :) taj djavo je po defaultu podesen na UTF8+BOM :)

Ne, po default-u je podešen na ANSI... A i ne piše eksplicitno UTF-8 BOM, nego samo UTF-8, a za taj koji mi koristimo baš piše "without BOM". :)

Evo samo da kažem da sam ipak odustao od integracije Smarty-ja u Zend... :) Ali samo iz jednog jedinog razloga, a to je što jednostavno postoje određena ograničenja, koja nisam mogao da prevaziđem, a najveće je nemogućnost implementacije nečega što se zove Two-Step View. A i sad imam mogućnost korišćenja tih mnogih ugrađenih ViewHelper-a (doduše mnoge još ne znam da koristim :S). Ali svejedno, Smarty ću sigurno integrisati u ZF u situacijama kada se ne zahteva modularna aplikacija...

Sad kazil kaže: "Eto lepo sam ti ja govorio za Smarty!". :D

I da, poslušao sam savete Mister_rap-a, što se tiče onoga: "tanji" kontroler, "deblji" model, i oko izmeštanja zajedničkog koda u ActionHelper-e i FrontController plugin-ove, i svega što je vezano za izgled u custom ViewHelper-e. Kod je na taj način mnogo jasniji, "čistiji", logičniji...

Jeste da ne koristim smarty odavno ali ne vidim sto ti ovaj pattern predstavlja problem za integraciju!?
Meni kada je to potrebno u frontu, a treba mi cesto ja ne koristim nikakve helpere jer prosto mi je ovako preglednije i jednostavnije

Pa tako ja radim sa Smarty-jem, al' to mi je sad nekako glupo kad vidim šta se može sa Zend_Layout klasom... :) Sada u onim view script-ovima imam samo content, odnosno, taj sadržaj koji se menja, a ono što je fiksno je u layout-u. Smarty, koliko ja znam, ne podržava tako nešto...

A to što si ti napisao, i kako se radi u Smarty-ju, nije baš pravi Two-step View...

Two-step View nije nikakva filozofija od patterna...

Kako god, znam da ima onih koji zagovaraju Zend_Layout i bio sam u pocetku poceo sa njim ali po mom misljenju ima vise nedostataka nego prednosti. Nego to i nije previse bitno.

Ako ja tebe razumem ne vidim kako to smarty ne podrzava tako nesto, sta se pod tim misli!?
Svakako da realizacija nije bas takva ali mozes da izvanredno struktuiras jer i smarty ima includove recimo...

Tako da ako je ovo neki tvoj phtlm (bez paritiala, zf css-a, head i bla bla bla):



Nije mi jasno zasto to ne bi bilo moguce realizovati...
Meni je smarty-ev nedostatak sto on ne podrzava php a to mi je ujedno najveca prednost zf phtml.

Pa ne, to sam rekao samo zbog toga što u Smarty-ju u svakom onom tpl fajlu moraš da include-uješ ostale delove, npr.

Al' dobro, to i nije tol'ko veliki problem, slažem se...


U kom smislu "ne podrzava php"? Ti npr. u Smarty-ju možeš da koristiš standardan PHP kod u okviru if-ova, itd., npr. ovako:

Takođe, bilo koju PHP-ovu f-ju možeš da koristiš kao modifier, npr.:

Ja mislim da je to velika prednost... A naravno, tu je i onaj {php}{/php} tag za embed-ovanje PHP koda, kojeg ja inače izbegavam da koristim...

Odosmo u off totalni

Elem, rekoh da odavno ne koristim smarty ali {php}{/php} bi cini mi se bila jedina solucija za neku kubasicu poput ove:



Ps.
U svakom slucaju sam skapirao, sve sto si napisao

btw Sad naleteh na jedna problem sa ZF i modulima... Naime, pre par dana sam vršio tranziciju na ZF 1.8, pa sam između ostalog menjao ceo bootstrap proces, pravio onu Bootstrap klasu, menjao index.php, strukturu direktorijuma, itd. E sad, problem se javlja što nikako ne mogu da podesim autoload-ovanje resursa u modulima... Npr. kad pokušam da kreiram Admin_Form_NewCategory, izbaci mi onu grešku "Class Admin_Form_NewCategory not found". A po onome što sam čitao u dokumentaciji, ona klasa Zend_Application_Module_Autoloader bi automatski trebala da bude instancirana kad se koristi modularna organizacija, i ona bi trebala da bude odgovorna za učitavanje resursa (modela, formi, plugin-ova, itd.) u svakom modulu.

Imam ove tri linije u konfiguracionom fajlu:

A evo i dela koda iz Bootstrap.php:

Ovaj deo sa $default_loader promenljivom mi rešava problem učitavanja resursa na default modulu, ali ne i na ostalim...

Uspeo sam da prevaziđem taj problem ubacivanjem ovoga:

ispred $default_loader-a, ali nemojte mi reći da to moram da radim za svaki modul?

btw Ako vam to išta znači, struktura direktorijuma mi izgleda ovako:

Mislim da su tu nejmspejsovi problem, a i kod je mnogo pregledniji kad svaki modul dodas posebno u bootstrapu, tako da ne vidim sto ti je problem to da iskucas za 2-10-20-50 modula koliko ti applikacija koristi!?

Pa problem je što ja to radim za jedan CMS, pa neću znati koliko ima modula, jer će korisnik moći da ih dodaje... Pa sam mislio da može neki "one-liner" (dobro, ajde dve, tri linije ) da reši stvar. Ja sam u stvari mislio da postoji neka automatika kod toga kad koristiš modularnu organizaciju, tako nešto i piše u manual-u: "When using module bootstraps with Zend_Application, an instance of Zend_Application_Module_Autoloader will be created by default for each discrete module, allowing you to autoload module resources.". Evo ti i link do te stranice na kojoj to piše, možda ćeš ti bolje da skapiraš o čemu se radi: http://framework.zend.com/manu...oader.autoloader-resource.html. (poglavlje 30.3.2.)

Doduše, mogu ja i dinamički to da odradim, skeniram taj direktorijum sa modulima, dohvatim sve foldere u neki niz, i onda "protrčim" kroz sve njih i odradim to instanciranje Zend_Application_Module_Autoloader-a za svaki od njih. Samo tu onda treba da pazim na namespace, jer u stvari ne znam kakva je konvencija što se tiče dodele imena foldera nekom modulu... Npr. ako se taj folder zove foo_bar, kako će onda izgledati onaj prefiks? Možda FooBar... Ili da li sme da bude space-ova u tim imenima foldera... Nadam se da razumeš šta hoću da kažem...

Procitah ovo, i ja kapiram (jer je to tako) da ti moras registrovati namespace prvobitno pa tek onda mozes da pocnes sa koriscenjem...
Licno za svaki modul mozes da uvedes isti namespace sto znaci da pocinju sa NP_... (recimo).

Ne znam ovo za foo_bar ali ne vidim sto bi koristio takvo imenovanje foldera...
Po mom misljenju veci je problem izboriti se kvalitetno kod takve ZF aplikacije sa layoutima i templejtima za svaki modul ali sta znam :D

Da, al' to mi je nekako nepraktično rešenje, ne znam... Al' svejedno, svaki modul, što se tog autoloading-a tiče, mora da ima poseban basePath (logično), tako da ipak nema "skraćivanja" koda po tom pitanju.


Pa ne, al' kažem ne znam kakva su uopšte pravila što se tog imenovanja tiče. Jednom sam samo negde pročitao nešto vezano za to, odnosno, za ono kako ZF mapp-ira taj prefiks na osnovu imena foldera modula, al' pojma nemam gde. Mislim da je negde u manual-u...


Pa ja sam to u ovoj mojoj aplikaciji rešio sa jednim Controller Plugin-om:

Za default modul, layout-i su mi u direktorijumu sa temama (front-end/themes/), pošto sam namestio onu "foru" sa promenom teme iz admin panela, i mogućnošću da korisnik dodaje svoje teme...

I ipak se nisam odlučio za onu varijantu da imam public folder, u kome će biti i index.php, jer nekako, ovaj CMS ne pravim samo za sebe, koristiće ga (nadam se ), ili će ga bar isprobati, dosta ljudi, pa sam pomislio da možda većina ljudi neće znati da podesi da im startni folder bude taj public. Razumeš šta hoću da kažem... I onda sam ipak rešio da idem tako što će mi index.php i .htaccess biti u root-u samog projekta, o onda korisnik zna odakle se "kreće". A taj public sam zamenio za front-end, u kome se nalazi sve ono isto kao što bi bilo u public-u (img, css, js, themes, itd.), ali samo bez index i htaccess... Znam, to sad malo predstavlja bezbednosni propust, jer će neko moći da "gađa" app folder, u kome je i konfiguracioni fajl, al' šta ću, možda se na kraju ipak vratim na public...

Mislim da ti ovo nije bas najsjanije resenje, a i to za lib, to ces vec regulisati ima i drugih nacina da to zaobidjes

Kako god, tebi sada moduli o5 imaju samo jedan layout, sta ako hoces da imas drugacije layoute za module, jesi razmisljao o toj varijanti !?
I ne znam koliko jos poziva imas u preDispatch() ja recimo tu natrpam svasta nesto, sto mi je bitno za odredjni kontroler, ali mislim da za tvoju varijantu nije pametno da tu odredjujes koju temu koristis, ja imam znacajno drugaciju strukturu za to i dosta je solidna ali odluku o tome koji layout se koristi drzim u routeShutdown() sto je naravno smesteno u controller plugin...

Testiraj malo za koliko ti se generisu strane, bas me zanima...

Za koji sad "lib"?


Pa da, tad se stvar komplikuje, al' layout-i su u toj situaciji obično vezani za određene kontrolere ili akcije, pa može da se napravi neki namespace takvih layout-a u jednom modulu (neki prefiks, ili tako nešto), pa da na osnovu toga idu učitavanja, ne znam...


Ne razumem...


E pa hteo sam par puta da testiram peformanse, al' ne znam s čime je najbolje to da odradim, jel imaš ti neki predlog?

Pa Zend library i ostale koje koristis. Ta struktura aplikacije nije nista strasno, rekoh naci ces nacine da to regulises..



Rekoh da nije pametno (po mom misljenju) sto u kontroler pluginu logiku za odredjivanje "aktivnog" layouta drzis u preDispatch() metodi.
Da li inace u kontrolerima "trpas" nesto u preDispatch() ?



Ja koristim svasta nesto, uglavnom neka custom resenja, ali za manje stvari (pa i za velike) skroz je zadovoljavajuci zfdebug bar (scienta debug bar) se ranije zvao, pa potrazi...

Aha, to... Pored ZF-a, u ovom projektu koristim (za sada) još samo PEAR-ovu Text_CAPTCHA klasu i FCKEditor. Od celog ZF-a (minimal paket), ne verujem da ću koristiti pola toga, pa ću pod hitno morati da izbacujem određene klase iz ZF paketa, jer mi je ceo projekat već sada "težak" 11.6MB. :o Previše je to...


Misliš na ono što sam spominjao za index.php i public folder? Misliš da ipak može da prođe sa index-om u root-u, a ne u public-u?


A gde bi bilo bolje da držim taj deo?


Jok. U kontrolerima imam samo akcije... Imam samo jedan ActionHelper, al' on je "pasivan" (ako može tako da se kaže), odnosno, koristim ga po potrebi, nema preDispatch i postDispatch hook-ova... A pored tog plugin-a za layout, imam samo još jedan, koji radi onu klasičnu proveru da li je korisnik prijavljen, ako hoće da pristupi admin panelu...

A i kad smo već kod tih ActionHelper-a i Plugin-ova, nije mi baš najjasnija razlika između te dve stvari, odnosno, nije mi jasno da li je bolje za te neke inicijalizacije koristiti ActionHelper ili Plugin? Kapiram šta je osnovna ideja ActionHelper-a, ali i on sa onim svojim hook-ovima (preDispatch i postDispatch), može na neki način da odradi isto što i Plugin.

Ja o velicini ne vodim racuna :D



Radi, znaci prolazi. Deploy-ovao sam par projekata sa vrlo slicnom strukturom i sve radi u fullu uglavnom 1.5 zf



routeShutdown()



Plugin, helper za ajax stvarcice recimo, premda ih licno izbegavam :P

Da li imas ponavljanje koda u akcijama kontrolera ?

Ps.
Ako si se prebacio na zf 1.8 jesi li imao problema sa uklucivanjem FCK-a ? Skoro sam poceo da radim lagani upgrade jednog projekta koji ga koristi i nisam se previse cimao, ali sam imao problema sa prikazivanjem cini mi se i uploadom fajlova.

Nemam, jako su mi jednostavni kontroleri... Najkomplikovaniji je jedan koji prihvata dva parametra iz url-a, pa na osnovu njih modelom dohvatam određene podatke iz baze i šaljem ih view-u. U njemu imam ovako nešto:

Ova prva dva if-a su jednostavna, imaju 5-6 linija koda, a ovaj poslednji je najsloženiji (oko 100 linija koda), jer u njemu obrađujem i zahteve iz forme za unos komentara, itd. Ali nema ponavljanja koda... Ostali kontroleri su "tanki", par linija koda i to je sve...


Sa prikazom ne, upload još nisam isprobao... A šta te je zezalo kod prikazivanja?

Uh kako dugackeeeee linije

Ne secam se tacno, ali cini mi se da je bio problem sa invalid controller specified js, a imao sam problem sa uploadom kad sam to namestio ili tako nekako, morao bih opet da probam pa da javim, al me mrzi...
Inace sve je bilo ok u .htaccess (valjda)

Pa moralo je tako... :D

Nego kad si spomenuo ponavljanje koda u kontrolerima, sad bi s tim baš mogao da se susretnem u jednom kontroleru, u admin panelu, pa da se konsultujem s tobom kako bih to izbegao... Naime, imam taj kontroler koji je zadužen za unos nove kategorije i njenih item-a. E sad, forme za unos tih stvari su jako slične, gotovo indentične, jedina razilika je što u ovoj drugoj, za unos item-a, ima i combo box u kome se bira kategorija kojoj taj item pripada. I samim tim što su iste forme, kod za manipulaciju zahtevima iz tih formi u kontroleru se takođe skoro i ne razlikuje... Evo kako bi izgledao pseudo kod:

E sad, da li je bolje da u tom kontroleru imam dve akcije (npr. category i item), pa onda da imam jednu pomoćnu f-ju koja bi radila ceo ovaj posao, a njoj bi se prosleđivalao upravo to - category ili item, pa i ona na osnovu toga, dinamički pravila model forme za unos kategorije/item-a, i DBTable model za unos kategorije/item-a. Jedino je u tome razlika...

A drugi način je da imam samo jednu akciju (index), a njoj bih kao parametar prosleđivao opet ili category ili item, pa bi se onda odma' na osnovu tog parametra radio taj posao...

Nadam se da sam bio jasan sa ovim pitanjem... :)

btw Ti slobodno kaži ako te smaram sa svim ovim pitanjima, jer već nekoliko dana unazad "neprestano" pišemo na ovoj temi... :D


Otkud to? :S Jel imaš onu najnoviju verziju (2.6.4)?

Meni sad onaj glavni deo u .htaccess-u izgleda ovako:

To su kao preporučili kad se prelazilo na 1.8...

Malo je nezahvalno odgovoriti jer ne znam koliko akcija ima i sta inace radi taj kontroler i kolika je njegova kompleksnost.
Ja bih po ovome sto si napisao itemi, kategorije isao sa 2 kontrolera...

Ali ako ostajes pri jednom onda bih samo index akciji prosledjivao dodatni parametar.
Ponavaljanja se obicno desavaju i nisu prakticna kad nesto instanciras i kad nesto saljes view-u tako da to treba izbeci.
Ali ako si sa tim ok sam update/insert nije problematican.

Vezano za FCK: pa sigurno da nije ta verzija jer je projekat inicijalno uradjen sa zf 1.5 tako da je sigurno i fck bio neki stariji. Ne koristim fck inace nego tinyMCE ali tu je isao on, ni sam ne znam zasto.
Probacu cim nadjem malo vremena ili da to probam od nule pa da vidim jel sve ok, ili da probam direktno u taj app ali isti trazi dosta izmena da bi sve sljakalo sa zf 1.8

Pa taj kontroler ne radi ništa više od onoga što sam napisao pseudo kodom - prihvata submit iz forme, i onda se ti podaci upisuju u bazu...

E, kad si sad rekao da bi išao sa dodatnim parametrom, tu bih ja onda pravio i dodatnu rutu, da sakrijem taj parametar u url-u, da ne bude recimo write/action/item, nego write/item. Pa me sad zanima da li bi bilo dobro da tu novu rutu pravim u bootstrap-u, ili mogu i negde drugde, pa da se ona kreira samo kad to bude trebalo?

Pa ne moras da ides sa onim sto sam ti rekao ako ti to nesto komplikuje, neces tu osetiti nikakvu razliku u performansama :D
To za rutu, pa u bootstrap-u normalno ili da ako ih imas vise sve smestis u neki konfiguracioni fajl (pametnije).

Rutiranje ide odmah po requestu dakle pre dispatch-a.

E da te priupitam još nešto... Samo se plašim da ne odemo mnogo u off, a opet, meni nekako glupo da otvaram novu temu. Ti pošto si moderator, slobodno "interveniši" ako hoćeš, prebaci ovaj post u novu temu, itd. :P

Elem, da li je na manjim, pa i srednjim projektima, pametno, isplativo raditi ORM, odnosno to mapiranje tabela iz baze i njihovo predstavljanje u objektno-orijentisanom maniru. A s obzirom da je ova tema o ZF-u, zanima me kako bi to išlo u njemu, i da li je komplikovano recimo integrisati Doctrine u ZF ili tako nešto... Ili bi možda za početak bilo lakše da sam, ručno kreiram modele i mapp-ere. ZF, koliko ja znam, ne nudi takav neki sistem. Zend_Db_Table predstavlja samo običan gateway za pristup određenoj tabeli u bazi (select, insert, update, delete), nema nikakvog mapiranja, osim ako sam ne napraviš mapper koji koristi tu Zend_Db_Table instancu, a taj mapper se koristi od strane modela...

Video sam na jednom primeru kako je to odrađeno u ZF-u, tačnije ta implementacija Data Mapper pattern-a, ali meni to nekako malo deluje kao bespotrebno komplikovanje, ne znam. Otprilike to ide ovako: jedna klasa koja se izvodi iz Zend_Db_Table, mapper koji koristi tu klasu za insert, update, fetch, itd., i ova treća koja predstavlja taj glavni model i drži polja te tabele koja se mapira, i taj model se u stvari i koristi u aplikaciji kao in-memory objekat.

Al' nekako ne mogu da vidim benefite svega toga, ili su mi ti primeri bili suviše prosti i banalni za implementaciju takvog nečeg...

Da čujem tvoje mišljenje o svemu tome...

Ako koristis ZF_Table realno nemas nikakvu potrebu za tim na manjim projektima - to je moje misljenje.
Ja praktikujem da kad prepravljam neciji kod ili radim u specificnom timu da pravim servis koji u neku ruku lici na maper cime izbegavamo menjanja stvari u kontrolerima i cim se promeni nesto u modelu ako je servis ok projektovan i on ne trpi nikakve modifikacije a i testiranje je jednostavnije.

Naravno OR mapper je sjajna stvar i recimo bez hibernatea u javi ne bih mogao da zivim ali php je nesto drugo :D

Sutra, na poslu (vrlo moguce) ce ti biti nametnute neke stvari koje mogu biti "lose i dobre"...



Doctrine je super stvar, ali bi prvo trebao da ga malo izucis nezavisno od zf-a. Sto se tice same integracije - ne nije komplikovano.

A sećaš se ono kad sam te pitao za autoloading resursa u svakom modulu, pa se ispostavilo da je jedino rešenje da za svaki modul pravim instancu onog Zend_Application_Module_Autoloader-a... E pa to nije jedino rešenje, a nikako ne bi trebalo da uopšte i bude rešenje...

Slučajno sam u manual-u pročitao da se preporučuje da svaki modul ima svoj Bootstrap.php, što je donekle i logično, a meni to nikad nije palo napamet. Ali taj boostrap mora da se izvodi iz Zend_Application_Module_Bootstrap, a i takođe, resurs za module - Zend_Application_Resource_Modules, mora biti inicijalizovan. To se obično radi tako što se u config fajlu, doda ova linija koda:

I onda sve ide automatski, load-ovanjem tog resursa izvršavaju se i boostrap-ovi u svakom modulu, a pošto se te klase izvode iz Zend_Application_Module_Bootstrap, automatski se se inicijalizuje i resourceLoader (to je ono što sam ja radio ručno za svaki modul ). Na taj način, mnogo je bolje što npr. sve što je vezano za određeni modul, možeš da prebaciš u Bootstrap za taj modul. Ja sam sad recimo definisanje nekih ruta i dodavanje custom plugin-ova, prebacio iz onog glavnog (default) Bootstrap-a, u Bootstrap u admin modulu.

I to sve opet ide u prilog onoj jasnoći koda, i odvajanju celina za svaki modul posebno...

Samo sad ne znam, da li je pametno da i svaki modul ima svoj configs folder, pa da u njega idu neka custom podešavanja za taj modul, ili je bolje da se jednostavno kreiraju podfolderi u onom glavnom configs folderu (app/configs), koji bi definisali svaki modul, i držali ta podešavanja... Npr. app/configs/admin, app/configs/foo, itd.

Jeap citao sam i ja relativno skoro za bootstrap kod modula ali ga nisam primenio (hocu nekad sigurno) i dalje se drzim:





Sa aspekta rejuzabilitija i pregldenosti svakako da da!


Ps.
Izvalio sam skroz slucajno da i bez dodavanja linija poput onih gore ovakvo parcence koda radi u controller plugin-u:

Misliš isti se efekat postiže kao sa onim linijama gore, ili samo jednostavno ne javlja grešku? Čudno...

Yeap isti efekat kao i da sam ga dodao u bootstrap fajl!
Dakle redirektuje ga bez problema na taj module, i u okviru njega sve sljaka perfektno...

U svakom slucaju prelazak na 1.8 u mom slucaju nije bio bas bezbolan tako da se nadam da novije verzije nece zahtevati neko extra cimanje :P

E upravo to, ogromna je razlika između 1.8 i prethodnih verzija, u svim aspektima. Baš sam se iscimao dok sam sve prebacio na najnoviju verziju. Nadam se da će ZF 1.8 sad biti neka osnova, koju neće tako drastično menjati u narednim verzijama...

btw Kad smo kod autoloading-a, jel' ti koristiš onaj podrazumevani autoloader callback (Zend_Loader::loadClass), ili možda definišeš neku svoju f-ju za autoloading, npr. onu čuvenu kombinaciju:

Pitam čisto zbog performansi, jer ima dosta polemika oko toga po net-u... I da li je tu f-ju bolje "spakovati" u bootstrap klasu, ili je jednostavno definisati tamo negde u index.php?

Ja koristim podrazumevani autoloader, znam da ljudi imaju razlicita misljenja ali ja nemam problema sa performansama tako da...

Evo danas naiđoh na jedan zanimljiv članak na Devzone-u, koji prikazuje ceo dispatch tok Zend Framework, i to izgleda ovako:


Ili u PDF varijanti:http://nethands.de/download/zenddispatch_en.pdf. Takođe, vredi pogledati i ovo: http://s3.amazonaws.com/ppt-download/zendframeworkdispatchworkflow-090508180623-phpapp02.pdf.

Evo da malo ozivim temu

Dakle pisem nesto sada i naidjem na jedan za mene cudan problem...
Modifikujem jednu aplikaciju koja je bazirana na ZF-u 1.5 i koju sam pisao poprilicno davno tako da necu uvoziti neki or mapper samo treba neke sitne prepravke da uradim.

Postoje tabele koje imaju ista imena kolona, recimo svaka tabela ima kolonu koja se zove id.
Napisem upit koji jelte radi ok.



nakon iteracije dobijem podatke koji nisu korektni (za moja ocekivanja)



Dakle fale polja model id i model name, prikaze samo manufacturer podatke.
Ako u bazi izmenim imena polja sve radi ok...

Malo sam vozio google i naisao da je ovaj bug prijavljen ranije:
http://framework.zend.com/issues/browse/ZFINC-42 i pise da je ispravljen ali u 1.92 ocito da nije.

Jel neko ima ideju, kako da ovo prodje sto je moguce bezbolnije jer preimenovanje kolona naravno ne dolazi u obzir :P

Jesi li probao:

Nisam, ali ce tako svakako da prodje... :D
Nije mi palo na pamet da modifikujem query nego sam drugacije razmisljao, u pravcu modifikacije ZF klasa...

Ja ne radim sa ZF tako da u tom pravcu ne mogu da ti pomognem

Jeap, nije ni bitno, ostavio sam ovako resenje koje si napisao pa cemo u nekoj narednoj verziji mozda da ispravimo

Pa ja ne bih rekao da je to bug, jer ako malo pogledaš u kod neke od onih Statement klasa, ne znam koji adapter koristiš, al' evo recimo za Mysqli, jedan deo one fetch() f-je izgleda ovako:

Cilj mi je bio da obratiš pažnju koju PHP f-ju ovaj metod utilizuje - array_combine()! A poznato je da ta da f-ja briše duplikate, i upravo je tu odgovor na to tvoje pitanje, zašto ne dobijaš sve podatke.

Tako da, jedino i pravo rešenje bi bilo ovo što je Nemanja predložio - korišćenje alijasa...

Ne bih se bas slozio da je ovo ok nacin za resavanje problema jer ako mi tabele imaju 15 istoimenih kolona to ce biti bas kobaja od upita.
Stoga je po mom misljenju za ocekivati da zf za "normalan upit" izvrsi organizaciju u kojoj cu imati sve podakte...

Zanima me kako je to reseno, posto na onom issue trackeru pise da je to reseno.

A čekaj, jel ti taj problem imaš baš sa tom Zend_Entity komponentom, pošto na tom issue tracker-u piše da je problem vezan za tu komponentu?

Nismo se bas skapirali zato sto je moj prvi post za problem totalno nejasan i daj drugi deo za issue je pogresan (my bad sorry for that).
Ne nemam problem sa Zend_Entity to ne koristim mada kazu da bi od 1.10.nesto trebalo da bude uveden.

Ako te zanima imas:
http://www.beberlei.de/zendentity/

Moj problem je sto uglavnom radim sa or maperrima i nisam detaljno procitao dokumentaciju ali si upravu da je ono jedini nacin prema onome sto pise za zend select. U najkracem kazu da treba koristiti alias...

Evo opet ja...

Pokušavam da kreiram rutu koja bi "pokrila" URL-ove tipa:

www.test.com/parent1/parent2/parent3/item
www.test.com/parent1/parent2/parent3/parent4/item1

Pritom, broj tih parent-a nije određen, i oni bi trebali da služe čisto izgleda radi, odnosno, radi stvaranja utiska te hijerarhije u url-u. Sadržaj na stranici se ispisuje samo na osnovu tog poslednjeg (jedinog) parametra - item.

E sad, cenim da je jedini način da tako nešto realizujem sa Route_Regex adapterom, pa sam ja u tom cilju pokušavao ovako nešto:

To sam danas nešto samo sastavljao iz glave, al' nisam puno testirao, jer ne znam dal' sam uopšte na dobrom putu. Nemam ideju kako bi uopšte trebao da izgleda taj regex, i kako uopšte router-u da kažem da je taj prvi parametar (path) opcion...

Dobro bi mi došao neki savet oko toga kako da realizujem takvu neku rutu. Dakle, ta putanja (parent1, parent2, itd.) je samo "šminke" radi, a glavni parametar je taj konkretan item.

Hm,

Nisam previse razmisljao o ovome ali ono sto je bezbolno a prvo mi je palo na pamet je da ti url izgleda ovako:

www.test.com/item/parent1/parent2/parent3/...

ili

www.test.com/parent1-parent2-parent3/item


Ovako bi bilo krajnje jednostavno napisati, nesto ovako recimo:



A za drugu varijantu je samo da bitno da sa nekim helperom ili kako vec buildujes parent1-parent2-parent3-itakodalje

Tebe sam čekao...

Elem, nije meni problem da dovučem to parent1, parent2, itd. Imam jednu tabelu, koja implementira Nested set, i onda u jednom modelu koji dohvata sve item-e (sa sve depth-om), koje potom pretvaram u niz pogodan za render-ovanje pomoću Zend-ovog Navigation view helper-a. Taj niz izgleda ovako nekako:

Dakle, standardna priča... E sad, ja imam tu rutu koja je krajnje jednostavna i koju koristim samo da bih "maskirao" taj parametar item, tačnije, da umesto ovoga: www.test.com/item/test, imam ovo: www.test.com/test. I to sve radi super. Ali ja sad samo hoću da stvorim taj utisak hijerarhije i u URL-ovima, odnosno, da ako je neki item duboko u hijerarhiji da njegov url ne bude samo www.test.com/test3, već upravo to: www.test.com/test2/test3. Sve to pre poslednjeg parametra item, treba da je običan string, i to bih takođe trebao da u definiciji stranica u ovom nizu, da dodam kao još jedan parametar u svakom tom nizu "params". To sigurno mora da se reši Regex Route-om... Ja mislim da sam blizu sa onim kodom kojeg sam napisao u mom prethodnom post-u.

I da, ne dolazi u obzir varijanta da umesto slash-a ('/') imam dash ('-').

Pozdrav,

Ja pisem kod malo drgacije od tebe, al nece ti biti problem da skapiras .
A plus mi nije jasno zasto ce ti ovakva struktura? Zivo me zanima koji su benefiti...

Kako god, natjerao si me da probam da napisem ovo, i brzo sam dosao do tog resenja koje radi u mom slucaju, tako da ne vidim sto ne bi radilo i kod tebe :P



Kao sto vidis ja saljem neki broj na kraju ali ako ti je item string to nije nikakav problem jelte...



Javi jel to to

Pa ja konfiguracije ruta obično držim u .ini fajlovima, tako mi je nekako preglednije, ako si na tu razliku u pisanju mislio.

E sad, možda sam te zbunio sa tim što sam malo pisao "item", a malo "test". To test bi u stvari bio neki kontroler, a na njega može da se šalje zahtev za određen item. E sad ja samo hoću da pre tog parametra item, utisnem i taj neki string, koji bi predstavljao putanju do tog item-a, čisto izgleda radi, ništa više.

Ovo što si ti poslao bi radilo u slučaju da ja uvek imam url-ove sa tom strukturom, jer si koristio taj modifikator "+" u regex-u. A ja treba da "pokrijem" i one slučajeve kad imam samo ovo: www.test.com/test - to bi bio poziv samo tog kontrolera "test", ili ovo www.test.com/test/item - poziv nekog item-a na prvom hijerarhijskom nivou (neki root item), dakle bez prethodne putanje, što će reći da taj prvi parametar treba da bude opcioni. A naravno, ta ruta treba da pokriva i sve ono za šta sam već davao primere: www.test.com/test/item1/item2, www.test.com/test/item1/item3, www.test.com/test/item1/item3/item4 - odosno item-i koji imaju svoje parent-e. I sad recimo za taj poslednji primer: konkretan item je item4, a taj prethodni parametar u regex-u (string) bi bio ovo: item1/item3.

Nadam se da je sad jasno šta hoću da postignem. Opet kažem, nije problem ako nema rešenja za ovo, jer sad trenutno koristim tu prostu rutu, koja je uvek u ovom obliku: www.test.com/test/item, bez obzira gde se taj item nalazi u hijerarhiji, al' eto samo sam malo hteo da unapredim izgled url-ova.

Koliko sam pohvatao ove tvoje itemove, tebi treba regex koji ce da uhvati sledece:
pocinje sa test - sledi 0 ili vise necega - neki identifikator

Ovo "0 ili vise necega" ne treba da se stavlja izmedju ( i ) jer te to ne zanima, zanima te samo ID (dodajem .htm na kraj da bi se lakse matchovao poslednji deo koji ti treba):



Hmmm... Deluje mi prejednostavno za tvoje komplikovane zahteve :D

Mada, iskreno, ne vidim razlog za sve ovo...

Ovo je jedino sto me buni u neku ruku trenutno, da li je to jedan kontroller ili vise njih to jeste neki broj X?

Enivej sve jedno nije uopste komplikovano da napises to sto ti treba jelte...
Samo treba da dodas sve rute a ne da ides sa jednom :D




Dakle ovo sam napisao prethodno i to ce pokriti sve slucajeve tipa: test/parent1/parent2/parentX/item



Pokrili cmo jelte slucajve test/item



I samo jelte poziv kontrolera test.

Trebas da vidis da li imas neke konflikte sa ostalim rutama.
Sto se tice resenja sa jednom rutom trebalo bi da moze sa regexom i recimo koriscenjem url view helpera pa da onda disejblujes taj prvi parametar.
Nisam probao jer ne radim na taj nacin, ali sam prilicno siguran da moze...

Ne, ne, samo jedan kontroler je u pitanju.

Ok, ići ću sa ovim tvojim rešenjem sa više ruta, a u međuvremenu ću pokušavati da sve to zbudžim u jednu regex rutu. Hvala na trudu!

Nisam nasao zgodniju temu. Ovde je pominjan smarty, zend, tako da - to je to. :)

Moje pitanje je kako da spojim zend framework i smarty, tj. umesto view da koristim smarty. Nasao sam neka resenja ali vecinom su vezana za starije verzije zenda, a po tome sto je jedno izuzetno kratko, drugo jako dugo, trece... kontam da je kroz verzije zf-a bilo promena pa necu da se vrtim u krug i pokusavam svasta.
Ako neko ima link, ili moze ukratko da objasni, bio bih zahvalan. :)
Kontam da je smarty bolji od zendovog view pa posto sam skoro krenuo sa zendom (a nesto malo pre toga sa OOP) hteo bih da od pocetka radim ispravno i na laksi nacin. Ako je ovaj nacin takav?

I jos nesto. Procitao sam tih nekoliko objasnjenja o zend-smarty, onako povrsno. Nisam siguran da se u nekim potpuno eliminise view, sto bi znacilo da view i dalje radi ali bez potrebe jer se koristi smarty. Jel tako ili smarty potpuno zameni view?

Zend Framework primenjuje ono najbolje (best practice) iz objektnog PHP-a, što njegove komponente čini jako pogodnim za izvođenje i proširivanje (custom-izovanje) njihovih funkcionalnosti. To upravo važi i za Zend-ovu komponentu Zend_View. Klasa Zend_View_Interface definiše koje sve uslove neki "sistem" mora da ispuni da bi se ponašao kao slovo "V" u celoj toj MVC arhitekturi. Da bi napravio wrapper za Smarty ili bilo koji drugi template engine, treba samo da kreiraš klasu koja će implementirati pomenuti interfejs. Ta klasa bi, u slučaju Smarty-ja, trebala da ima instancu Smarty-ja kao člana klasa, a njega bi inicijalizovao npr. u konstruktoru. I onda, svaka od tih metoda koje moraš da redefinišeš, kako bi implementirao Zend_View_Interface, bi sadržala odgovarajuće funkcionalnosty Smarty-ja, npr. getEngine() bi samo vraćao tu instancu Smarty-ja (npr. return $this->_smarty;), __set() bi radio assign ($this->_smarty->assign($key, $val);), itd. U manual-u imaš primer jedne takve implementacije.

I naravno, posle samo treba da "kažeš" Zend-u da hoćeš da koristiš taj novokreirani View, najčešće negde u tvom bootstrap-u:


E sad, ja lično mislim da se ne isplati ta integracija nekog 3rd party template engine, jer jednostavno ostaješ uskraćen za sve blagodeti koje pružaju ti built-in view helper-i. :)

Hm.. sad se kolebam.
Tvoj webfolio koliko sam razumeo nema smarty a nemas problema sa templajtima i zadovoljan si sa view? Pa onda necu ni ja da se tripujem... :)

btw svaka cast za webfolio. Vidim da je naisao na pozitvne kritike. Zahtevan projekat za jednu osobu. Kontam da cu ga koristiti za dodatno proucavanje zenda. Necu nista da kopiram samo da vidim kako zend radi tj. neki napredniji nivo koriscenja.
Jednom kada napravim nesto konkretnije (od ovog proceduralnog sto je kao nesto:)) iskoristicu webfolio za prezentaciju.

Hvala na odgovoru. ;)

Pozzz

Kao sto rece Nikola, izgubio bi puno a dobio malo (nista?). Licno, u ZF-u nikad nisam menjao V deo, a i ne vidim razloga da bih menjao - jednostavno, komponenta je prejaka. A i ne moras da "switch"ujes razmisljanje izmedju smarty i php sintakse :)

Ok, necu petljati sa smarty posto mi i sam zend postaje konfuzan. Naime procitah par tutova i sad pojma nemam gde sam. :) Izgleda da svi imaju neki svoj princip, menjaju standardan raspored foldera... ja krenem tako kontajuci (a i izgleda) da je jednostavnije.. i na kraju vidim da nije.
Uglavnom jasno mi je ono osnovno. Napravio sam par akcija za citanje, prikaz, editovanje i upis (prateci ovo - pdf). Radi fino i logicno, samo sto je objekat nenormalno veliki (bar meni tako izgleda) i treba prilicno vremena za jednostavne operacije. Valjda ce se ispeglati kasnije sa kesiranjem...

Nego, treba da imam admin panel, dakle kako kontam dva modula. Public (default) i admin. Krenuo sam prema ovom tutorialu ali kako god ja da dodam novi modul, kreiram sve isto kao kod postojeceg sa nekim razlikama... nece! Greska - ne moze da nadje potreban kontroler. Znam gde treba da ga trazi i stvarno se tamo nalazi, ali ipak nece.
Moguce da sam prevideo nesto, mozda ga ne pozivam kako treba, a mozda ni tut nije dobar.

Ako neko od iskusnih moze da baci pogled na pomenuti tut (part1, part2) cisto da vidi jel ok nacin kako se radi, ako nije ili to moze bolje da me uputi... neki link, smernica.. Ako je ovo dobro, onda da se patim dok ne pronadjem gde je caka.

Tnx i pozz. :)

Whoa, ovi ga bas promenise. Zasto bi neko menjao defaultnu strukturu, tj. onu koju kao preporucuju, ne'am pojma. Pogotovo sto ovi primeri unutar APP_PATH-a imaju 2 foldera library. Osudjeno na konfuziju do kraja zivota :)

Uglavnom, ja se drzim one osnovne strukture foldera, i za mene je ona sasvim OK.

Eo "moje" strukture za sa modulima.



E sad, ako radis sa modulima, u app.ini-ju moras reci koji je defaultni modul (recimo imas public i admin, public je default):



Vodi racuna da klase koje *nisu* u default modulu, moraju da budu prefiksirane sa nazivom modula. Npr, IndexController u admin modulu:



Nadam se da sam smanjio konfuziju ;)

Takođe, pošto će tvoji dodatni moduli verovatno imati svoje Bootstrap klase, a i one moraju da budu izvršene u bootstrap procesu, u tvom konfiguracionom fajlu bi trebao da "kažeš" da hoćeš da se pri bootstrap procesu izvršava i resurs za bootstrap-ovanje dodantnih modula. Taj app resurs se zove "Modules" (logično ), i da bi ga uključio u bootstrap proces, dovoljno je da dodaš ovu liniju koda u tvoj konfiguracioni fajl:

Pored ovoga što je Robert spomenuo, u vezi set-ovanja default modula, a što inače treba da radiš samo u slučaju da ti se podrazumevani modul NE zove "default", trebao bi i da podesiš putanje do direktorijuma u kojima se nalaze kontroleri. U zavisnosti od toga da li si se odlučio za strukturu direktorijuma u kome se resursi (kontroleri, modeli, view-ovi, itd.) default modula nalaze unutar samog "app" foldera, i u kome se onda nalazi i direktorijum "modules", ili su svi moduli unutar pomenutog "modules" foldera, u tvom konfiguracionom fajlu bi treba da imaš ove linije koda:
Za prvi slučaj:

A za drugi slučaj:

Ovo cini mi se treba da bude

A što? Doduše, ja obično taj glavni konfiguracioni fajl čuvam u .php formatu, ne koristim .ini, i onda je notacija ona klasična PHP-ovska, pa tako taj deo sa definisanjem app resursa izgleda npr. ovako:

Zato sam i napisao samo resources.modules, misleći da je u slučaju .ini fajlova slična notacija. A i ako pogledaš u kod klase Zend_Application_Bootstrap_BootstrapAbstract, pa pri dnu metoda setOptions(), videćeš da kad stigne do tog dela za registrovanje resursa, odnosno kad stigne do tog elementa konfiguracionog niza sa indeksom 'resources' - elseif ('resources' == $key), u toj petlji ispod će da "oblilazi" sve resurse u formi ime resursa i njegove opcije. Ta dva parametra će se prosleđivati registerPluginResource() funkciji, a ona kao prvi argument prihvata ili string ili Zend_Application_Resource_Resource. E ja sad stvarno ne znam kako će izgledati taj niz nakon parsiranja .ini fajla, tačnije, kakav bi efekat imalo to "[]" pored "modules". A i za app resurs "Modules" ne postoje nikakve dodatne opcije, i zato u toj notaciji u konfiguracionom fajlu stoji prazan string (resources.modules = '').

Hm, ocigledno sam ja nesto pobrkao. Znam da je jedno vreme zahtevalo da bude [] na kraju da autoloader za module radi kako treba, ali to je mozda jos iz doba 1.8 verzije, a meni je ostalo ovako u glavi. Anyways, radi i ovako i onako :)

*posle 10 minuta guglanja*

A-ha! Odavde mi to sa uglastim zagradama: http://akrabat.com/zend-framew...otstrapping-modules-in-zf-1-8/
Al izgleda da je to da se model iz jednog modula moze instancirati u drugom modulu. Eto, mystery solved :) kazem ja da je vezano za 1.8 :)

Pa da, minut-dva koliko mi je trebalo da kreiram foldere i izmenim ini, kontroler.. i to je to. Radi super! :)
Kontao sam da to nije toliko komplikovano kako izgleda u onih par tutova. Zasto li ljudi zakomplikuju kada moze jednostavnije...

Odlicno ste objasnili. Hvala puno. :)

Nego, za sada nemam nista u bootstrap, a nista nisam imao od samog pocetka... pa nisam siguran sto posto cemu to tacno sluzi - za sta i kada se koristi? Mislim na bootstrap u folderu application jer sad tog fajla nema u folderima "admin", "public" i "modules" (tako nesto) kao sto je bilo prema onom tutu iznad.

Bootstraping je proces inicijalizovanja sistema - on se prvo izvrsava. U application folderu je on neophodan. Taj bootstrap inicijalizuje neke stvari koje su vezane za sve delove aplikacije. Bootstrap na nivou modula nije neophodan. Tu mozes da izvrsis inicijalizaciju odredjenog modula, nakon sto se inicijalizuje ceo sistem.

To sto je tebi trenutno bootstrap prazan, to ne znaci da on ne radi nista, ili da ce stalno ostati prazan.

Postoje neki ugradjeni resursi koje ZF automatski bootstrapuje, kao sto je FrontController ili sesija. Ostali najcesci su baza i layout.

Ja licno najcesce sam bootstrapujem dodatne stavke za autoloader i neka podesavanja za Zend_View.

Stvari koje zelimo da sami inicijalizujemo se definisu kao metode unutar tih Bootstrap klasa. Svaka metoda koja pocinje sa _init bice izvrsena automatski. Redosled izvrsavanja je sledeci:
- prvo se izvrsavaju nase custom _init metode, top to bottom, tj. onim redom kojim se nalaze u Bootstrap klasi, iduci od pocetka klase prema kraju.
- na kraju se izvrsavaju te automagicne ugradjene metode.

Evo jedan primer inicijalizovanja Z_V-a:



Na ovaj nacin smo dobili da ce na celom sajtu (ako ne pregazimo negde dalje, jel), doctype biti XHTML1 strict, uvek cemo imati content-type podesen, kao i neki glavni naslov sajta...

Ja sam ovu funkciju nazvao _initViewHelpers - bitno je samo da pocinje sa _init, sto se tice ZF-a, moglo je biti i _initSkuvajMiKafu - pocinje sa _init, skuvace mi kafu :)

Na kraju: bootstrap je mocan i moze puno toga da odradi, ima dosta delova sa kojima ni ja jos nisam nacisto. Pretumbaj dokumentaciju za detaljnije :)

Obrati paznju da tokom bootstrapovanja, ti jos ne mozes znati recimo koji je modul ili koja akcija kog kontrolera pozvana - u toku inicijalizovanja sistema, ZF to jos nije odredio.

Edit: malo razumljivije u return-ovanju resursa (lakse mi je preko koda nego recima :D):



Znaci, resurs dobija ime tako sto se _init odbaci, sve posle toga se prebaci u lowercase, a vrednost tog resursa je to sto ta metoda vraca.

_{[Ovu poruku je menjao kazil dana 15.06.2010. u 19:25 GMT+1]}

Pa zavisi... Preporuka je da, u slučaju modularne aplikacije, pored pomenute linije za load-ovanje "Modules" app resursa u konfiguracionom fajlu, svaki modul ima svoj bootstrap fajl, tačnije klasu koja će se izvoditi iz Zend_Application_Module_Bootstrap, budući da ta klasa obavlja neke jako korisne stvari. Najveća prednost ovakve implementacije Zend_Application_Module_Bootstrap svakako je to što će automatski biti obezbeđen autloading resursa određenog modula (modela, mapper-a, viewhelper-a, plugin-ova, servisa, itd.), što proizilazi iz činjenice da se pomenuta klasa izvodi iz Zend_Application_Bootstrap_Bootstrap, koja takođe radi istu stvar kroz metod getResourceLoader(). Zend_Application_Module_Bootstrap samo utilizira pomenuti metod, ali prednost je to što automatski set-uje odgovarajući namespace, a to je u stvari ime modula, kojeg dobija iz samog imena bootstrap klase.

Još jedna dobra stvar kod ovakve implementacije je i to što je moguće da u onom glavnom konfiguracionom fajlu, app.ini ili kako god, postoje postavke karakteristične za određeni modul, u obliku npr.:

... pri čemu je "foo" naravno ime modula.

Na taj način, svaki modul može da ima neku svoju, custom konfiguraciju, pa je tako npr., kao što se vidi iz prethodnog primera, moguće definisati rute koje dodaje neki modul, ili je kroz "Translate" resurs moguće dodati putanje do fajlova sa prevodima koji se nalaze u nekom modulu, i slično. Ovako nešto je moguće iz razloga što Zend_Application_Module_Bootstrap u konstruktoru proverava da li aplikacija (Zend_Application ili bootstrap klasa default modula) sadrži i opcije čiji key (indeks) odgovara imenu modula, pa onda dodaje svu tu custom konfiguraciju na stack opcija, kako bi i one bile izvršene u bootstrap procesu.

Kod mene je u layout bio meta charset. Znaci takve stvari koje vaze za ceo sajt idu u bootstrap koji je u application folderu. Ili ako se nesto definise u svakom kontroleru, tj. zajednicko je za sve akcije/kontrolere - na nivou sajta. A verovatno je ok uraditi tako i ako je za vecinu jer moze da se pregazi posle.
Ok to mi je sad jasno. :)

Nego Nikola pomenuo si lang fajlove. O tome sam bas razmisljao kako se radi. Ali sad me zbunilo to sa app.ini. Skoro da nista nisam petljao tamo, pa nisam siguran sta sve moze da se definise u app.ini.
Problem je sto sam zf u startu skontao nekako olako, jos i to sto ga u prekidima proucavam pa i zaboravim sta sam skapirao pre dva-tri dana. :)
Mislim da cu ovih dana probati ozbiljnije da ga savladam. Moguce da cu vam dosaditi sa pitanjima :) ali trudicu se da pre toga iscrpim sve druge izvore. :)

U svakom slucaju tnx ljudi. ;)

btw

Kod cesto kao i slika govori vise nego hiljadu reci. :D

Vidim ja da ce ovde biti zavrzlama.

U public/index.php (root sajta) sam na kraju upisao print_r($application) i dobio negde oko 11k linija. WTF?!
To isto sam uradio u toku isprobavanja add, edit, delete iz baze onih muzickih albuma iz gore pomenutog pdf tuta. Ajd reko da bacim pogled sta ima tamo. Dobio sam oko 100 linija. I to mi je bilo puno, a ovo... da se slogiras!

Sta sam mogao da zeznem? Za sada postoji par kontrolera, nema veze sa bazom, unosom, obradom bilo cega. phtml fajl je samo par reci signalizacije radi. Tek sam poceo da pripremam strukturu, malo pre uz kafu.

Hteo sam da kreiram jedan form i taj php fajl koji je u folderu public/forms (public je ime modula) nece da nadje. Zato sam i uradio print_r da vidim gde ga trazi. Trazi ga u application/forms. A ja imam u svakom modulu pa jedan folder forms. Kontam da bi trebalo u app.ini da se definise druga putanja, ali ne mogu da nadjem kako...

Uopste ne kapiram zasto je ovako veliki objekat. Sledio sam tacno ono sto ste gore pisali. Mislim da nisam imao gde napraviti gresku jer ukupno ako ima 15-20 linija koda.. a kako me krenulo, ko zna... :)

Pa ne znam šta ti je tu čudno... Pogledaj u kod klase Zend_Application i videćeš da ona sama po sebi ima oko 400 linija čistog koda. Ali kad radiš print_r instance te klase, dobićeš i ispis svih tih objekata koje ona ima kao članove klase - $_autoloader, $_bootstrap. Na broj linija neće uticati samo ti objekti, jer nakon bootstrap-ovanja, biće mnogo elemenata i u tom nizu $_options (u njega se smeštaju sve one opcije iz app.ini), koji je takođe član klase Zend_Application.


A kako si nazvao tu formu? Tačnnije, klasu i fajl u kome se ona nalazi? U slučaju da ti se modul zove public, klasa te forme bi trebala da ima naziv, npr. Public_Form_Foo, a fajl bi trebao da se zove Foo.php. Doduše, ako je taj tvoj public modul označen kao default, onda je prefiks "Public" u nazivu klase suvišan.

U public modulu sam pisao bez prefiksa a u admin sa prefiksom (Admin_). Pronalazi ga samo u "application/forms". To vazi za sve module. Ali hteo sam za svaki modul posebno folder forms. Problem je sto nista osim view i controlers nece da skonta u modulu. Da napomenem, bootstrap u application folderu je jos uvek prazan i u application/configs/app.ini sam upisao samo ono sto ste gore naveli.
Sada mi je forms, models, configs i layout u application folderu a hteo bih da ih smestim u foldere odgovarajucih modula (ajd configs mozda i ne mora).

Nego kako bre normalno 11 000 linija?! Evo kopiracu ti ono sto bas upada u oci da se ponavlja:

To isto se nalazi na 14 mesta u objektu. I sve ostalo je toliko puta ponovljeno. Mislim da je greska kod mene, posto kao sto rekoh sa onim muzickim albumima (tut u pdf-u) je bilo oko 100 linija, a ova sada aplikacija je daleko manja (ako se uopste moze tako nazvati jer nema skoro nista).
Nemam pojma koliko memorije zauzima objekat, gledam to kroz linije... sirovog teksta ima skoro megabajt. Ako je ovo normalno onda uopste nije dobro i pitam se kako radi neka aplikacija radjena u zendu pri poseti od nekoliko hiljada korisnika.
Ako je greska i objekat 14 puta manji, to je ok.. u protivnom bolje da cepam moje klase, pa i proceduralno po malo nego da sve sto napravim smori server i dzaba mi sto je ultra mega giga opsno kada jedva radi. :)

btw

To sam bas i hteo, da vidim sta sve drzi u memoriji od pocetka do kraja. Plus trebala mi je putanja koju koristi za trazenje forms.

Da li imaš bootstrap klase u okviru admin modula, i da li se ta klasa izvodi iz Zend_Application_Module_Bootstrap? A verovatno imaš, pošto kažeš da si dodao resources.modules = '' u app.ini, a taj resurs bi bacio izuzetak u slučaju da neki modul kojeg pokušava da bootstrap-uje nema svoju bootstrap klasu.


Da, 11000 je stvarno malo neoubičajena cifra. Verovatno onda negde kod tebe u kodu dolazi do bespotrebnog izvršavanja app resursa po više puta...

btw Za taj ponavljajući kod kojeg si poslao, baci pogled na source konstruktora klase Zend_View_Helper_Doctype, tu nastaje taj ArrayObject objekat. I kao što vidiš taj helper poseduje upravo tu promenljivu $_registry. Verovatno nekim čudom po više puta izvršavaš resurs za inicijalizovanje View-a (Zend_Application_Resource_View), i pritom mu prosleđujući opciju za doctype, nakon čega taj resurs poziva pomenuti view helper, koji tu informaciju o doctype-u upisuje u registry, kako bi ista mogla da se reuse-uje u toku jednog zahteva.

Vidi, obrisao sam sve iz index kontrolera. Znaci indexAction - nista.

Dve reci u index.phtml
layout.phtml par html tagova i <?php echo $this -> layout () -> content; ?>
application/bootstrap.php prazan (samo jedan imam)

/public/index.php (root sajta)


Kada unesem print_r($application) posle run(); dobijem ovaj objekat 22 puta ponovljen (a source strane je 11k linija):


Dosta objekata i nizova je puno puta ponovljeno. Ja uopste nemam ideju zasto bi trebalo ovako? Ako se nesto pojavljuje/potrazuje na vise mesta, napise se na jednom i poziva sa jednom-dve linije. Ovo sad je cista suprotnost. Ne trazi se na vise mesta vec samo jednom - a pise se 22 puta.
A nemam ideju ni gde je greska jer sam sve uklonio, skoro da nista nije ostalo osim onog minimuma cisto da se vidi da radi.

<sub>[Ovu poruku je menjao masinac_1 dana 16.06.2010. u 20:07 GMT+1]

[Ovu poruku je menjao masinac_1 dana 16.06.2010. u 23:50 GMT+1]</sub>

Nije greska, tako je uvek (delimicno i zbog toga se govori za ZF da je bloated). Samo naprimer, svi resursi iz bootstrapa (i custom i oni ugradjeni) se nakon bootstrapping-a ubacuju (inject) u front controller, kako bi resursi bili dostupni tokom celog zivota aplikacije.

Ali zar to nije malo van svake pameti?! Kako to da vam ne smeta?
Imamo nap. jedan niz. Njega koriste 4 metode. Pa necemo za svaku metodu praviti objekat u objektu i u taj drugi unositi potreban niz. Napravicemo glavni objekat i niz uglaviti negde pa pozivati kada je potreban.
Ja uopste ne razumem logiku po kojoj je dobro i potrebno duplirati neki niz/objekat 20+ puta.
Ovo moze da rezultuje visetruko vecim opterecenjem servera. Jos puta broj korisnika. Vise nisam pametan... da li uopste da ucim zend ili sam da pisem klase. Kapiram da su serveri jaki, ali nije resenje kupiti/zakupiti zver ako moze u kodu da se smanji potrosnja resursa.

Jeste li vi stvarno 100% sigurni da je u redu imati na 20-ak mesta jedan isti niz/objekat ponovljen. I tako 90% podataka u velikom objektu, koji onda postaje opasno veci. Na kraju se dobije skoro megabajt svega toga iako jos uvek aplikacija nista ne radi.

Stvarno... dzaba sve pogodnosti, ako je ovo normalno - jako los framework. Nadam se da gresim...

_{[Ovu poruku je menjao masinac_1 dana 16.06.2010. u 23:51 GMT+1]}

To što ti nakon print_r-a dobijaš neki objekat ispisan 20+ puta ne znači da je instanca tog objekta zaista napravljena toliko puta. Objekti se prenose po referenci, i u ZF-u je česta pojava da se jedan objekat koristi na nekoliko mesta u toku jednog zahteva, npr. request objekat. Tako da, ne možeš da sudiš samo na osnovu tog jednog print_r-a, jer ta funkcija jednostavno ne može da bude merilo. Primena te funkcije nad nekim objektom daće ispis svih njegovih članova, a to opet mogu biti objekti, pa onda ispis članova tog pod-objekta, itd., pri čemu to može da ide jako daleko u dubinu. Uzmi bilo koji drugi framework, i probaj da odradiš print_r tako nekog glavnog objekta i opet ćeš dobiti jako dugačak output.

Hm.. nisam siguran da te razumem.

Ovde nema dupliranja. Za print_r prvog objekta dobije se sadrzaj svakog od objekata bez ponavljanja. Drugi i treci postoje kao clanovi prvog i sva tri bez ponavljanja se nalaze u memoriji.



Ovde je dupliran treci objekat. Kada se uradi print_r prvog objekata videce se sadrzaj svakog od objekata.
Jel hoces da mi kazes da ce ovaj treci biti ispisan dva puta kao da su dva razlicita objekta, a u memoriji ce postojati samo jedan tj. jednom? Takoreci na drugom mestu gde je clan nekog objekata bice kao shortcut? Ili se sadrzaj treceg dva puta pojavljuje i u memoriji isto kao i kada se uradi print_r?

Tako je, samo to naravno nisu dva različita objekta, već jedan te isti, pa ćeš dobiti dupliran ispis. Funkciju print_r ne zanima to koliko je puta neki objekat instanciran, ona samo ide redom i ispisuje sve što joj se nađe na putu.

E vidis to me raduje. :D
Kad mi je Robert rekao "to je normalno, nema tu greske" (u stvari i jeste tako, samo sam ja drugacije povezao) za malo da odustanem :), ali kontam nije moguce da je tako ozbiljan problem a ljudi ipak koriste zend. Ocigledno je sve ovo posledica mog nepoznavanja print_r i dobrim delom toga sto sam tek od skora poceo pisati objektno. :)
Super. ;)

Ajd da te zamolim kada nadjes vremena (ili neko drugi, svejedno) da napises koji red o tome kako si postavio modele i forms u odgovarajuci folder modula. Hteo bih jos i layout da imam posebno za svaki model. Kontam da ima veze sa app.ini i bootstrap-om koji ja imam samo u application (nema ga u modulima).
Ili neki fin link gde je objasnjeno o ini i bootstrap. Citao sam manual ali meni to sve nekako konfuzno, kao da izostave pojedine stvari kontajuci da se podrazumevaju, a meni se ne podrazumevaju jer tek je nekoliko dana od kada proucavam zf (efektivno samo sinoc i danas). Takvih muka nikada nisam imao sa php manual. Samo par puta sam zaglavio i trazio pomoc na forumu.

Konfuzna mi je i veza sa bazom, konkretno select, nikako da ubodem kako valja. :) Treba mi samo jedan primer koji radi, ono sto sam nasao kopiram i dobijem application error.
Ajd jos samo ovo, kako da poboljsam javljanje gresaka, da mi preciznije kaze u cemu je problem?

http://framework.zend.com/manu...g.quickstart.create-model.html

Za index akciju u guestbook kontroleru se poziva fetchAll() iz guestbook mapera. Pa onda on izvrti dve svoje metode getDbTable() i setDbTable($dbTable) (?!). Ime jedva nadje u DbTable_Guestbook pa onda preko Model_Guestbook slaze ono sto je pokupio iz baze.
Moze li ovo prostije?
Bilo je prostije o onom pdf tutu, ali kad ukombinujem dva tuta dobijem katastrofu. Odlepicu! Prvi put da se ovako patim sa php-om, a napravio sam par aplikacijica prvo proceduralno a poslednju objektno. Nije nesto, jos ucim, ali relativno brzo sam napredovao i nemam problema da razumem kad ima smisla. Ovo sa zendom skoro pa kao drugi programski jezik.

Kako da zatrazim iz baze nesto tipa

Necu sve kao sa fetchAll, samo ono sto mi treba.

Pa ja mislim da smo tu priču već evaluirali sa onim resources.modules[] = '' u app.ini i Zend_Application_Module_Bootstrap klasom...


E pa za tako nešto ćeš ipak trebati malo da se pomučiš... Najpre treba da kažeš ZF-u da u svojoj aplikaciji želiš da koristiš Zend_Layout komponentu. To možeš da uradiš na više načina, a najlogičniji bi bio da iskoristiš app resurs za inicijalizovanje layout-a (Zend_Application_Resource_Layout):

... ili da ručno u tvojoj glavnoj Bootstrap klasi dodaš metod koji će da radi praktično istu stvar, npr.:

Nadam se da znaš kakva bi trebala da bude struktura tog layout.phtml fajla, a i uostalom, sve lepo piše u manual-u.

E sad, da bi neki od dodatnih modula mogao da koristi svoj layout za ispis, rešenje nikako nije da ovo isto uradiš u Bootstrap klasi tog nekog modula, jer bi tako samo overwrite-ova ovo što si uradio u default modulu, i taj layout bi onda bio "na snazi". To switch-ovanje layout-a moraš da uradiš u odnosu na zahtev (request), tačnije, kada je request set-ovan na taj neki dodatni modul. Najbolji način za realizaciju ovoga je koristeći Front Controller Plugin-ove. Oni ti omogućavaju da "slušaš" određene doagđaje koji se izvršavaju u jednom ciklusu Front Controller-a, odnosno tog celog dispatch cikluca. Postoji nekoliko tih tkz. kuka (hooks), i to: routeStartup, routeShutdown, dispatchLoopStartup, preDispatch, postDispatch i dispatchLoopShutdown. Ono što ti treba da uradiš je da napraviš svoj plugin, koji će se izvoditi iz Zend_Controller_Plugin_Abstract klase, u kojoj imaš sve ove hook-ove u vidu metoda spremnih za redefinisanje. Primetićeš da ta klasa kao članove ima $_request i $_response objekte (to je ona priča o korišćenju jednog objekta na više mesta ), a i svi ti hook metodi kao argument dobijaju instancu Zend_Controller_Request_Abstract klase. Ti ćeš u tvom plugin-u iskoristiti taj objekat, kako bi ispitao da li je trenutno zahtevan taj tvoj modul sa custom layout-om, i ako jeste promenićeš putanju layout foldera. Taj plugin bi izgledao npr. ovako:

Kao što, vidiš jako jednostavno...


Kad god u tvojoj aplikaciji dođe do nekog izuzetka, ZF će to po default-u pokušati da forward-uje na kontroler sa nazivom "Error" i njegovu akciju koja se zove "error". Ti taj kontroler (verovatno) nemaš, pa ćeš možda često dobijati poruku "Invalid controller specified 'erro'r", ili tako nešto. Rešenje - napravi taj kontroler i u njemu handle-uj izuzetke. Više o svemu tome imaš ovde:
http://framework.zend.com/manu...end.controller.exceptions.html
http://codeutopia.net/blog/200...ling-errors-in-zend-framework/


Gledaj, nije poenta da ti radiš sve kako "oni" kažu. Oni su u tom tutorijalu pokušali da simuliraju ORM, ali to ne znači da i ti u svom projektu moraš da radiš na taj način. Zend_Db_Table klasa je sama po sebi jako moćna stvar. Izvedi neku tvoju klasu iz nje, redefiniši promenljivu $_name (ime tvoje tabele u bazi), i imaš potpuno funkcionalan Table Gateway ka tvojoj db tabeli, kroz metode find(), insert(), update(), delete(), fetchAll(), fetchRow().

A i druga stvar, niko te ne prisiljava da ti koristiš npr. Zend_Db_Select, jer ti tvoje upite možeš da izvršavaš tako što ćeš string upita proslediti direktno npr. fetchAll() metodu tvog db adaptera (instanca Zend_Db_Adapter klase). Zbog svega toga, Zend je jako fleksibilan i moćan framework.

Ma imao sam error kontorler, ali je ostao od nekog levog tuta pa nije sadrzao sve sto treba - samo nekoliko linija. Sad je u redu.
Nego skinuo sam zend server i zend studio da probam. Izgubio dosta vremena i zivaca dok nisam skapirao da mysql server fali zato sto je instalacija detektovala onaj od xampp-a, plus sto sto godina vuce sa neta u toku instalacije. Nisam odmah shvatio o cemu se radi jer sam cekirao mysql i logicno ocekujem da se pojavi nakon istalacije. E tu kao sto rekoh ode dosta vremena a i zivaca sto je veci problem, plus sto sam odlepio svakako i resih da batalim, odmorim malo.
Sad sam skinuo zend in action, detaljno citam manual i ide lagano.
Zend kes i optimizacija opasna stvar na z. serveru. :) Sa 20-ak na 30-40 zahteva po sekundi a nista nisam radio.
Lagano uvidjam prednosti, to sto kazes niko me ne tera do koristim neku klasu od zenda ako mislim da ce moja bolje da uradi to (specificno) sto mi treba. Elastican je i fleksibilan. Kul. :) A sa druge strane malo pises mnogo uradis.

Tnx za iscripan odgovor. :)

Pozz

To je deo jednog od modela. Uprostio sam i uklonio generisanje za $sql i par linija za $data.

Da li je to dobar nacin za pisanje custom sql select upita? Ili je bolje ovako nesto:

Kako sam razumeo ovaj drugi nacin je pogodan ako se menja baza? Ima li jos neka znacajna razlika?

I klasa Zend_Db_Table_Abstract ima svoj fetchAll() metod. Nema potrebe da koristiš db handler, jer će to pomenuti metod uraditi za tebe. Pogledaj kod tog metoda i videćeš na koje sve načine možeš da ga iskoristiš.

Ali meni treba samo id i nesto1, a sa fetchAll() dobijem sve.
Jel mislis na ovo:


Ako te nisam dobro razumeo, a moguce da nisam :) ajd molim te napisi samo za tu metodu kako da se uradi taj query.

Da, nisi me dobro razumeo, a izgleda da nisi ni bacio pogled na kôd metoda fetchAll(). Pogledaj šta piše u docblock-u za prvi parametar: @param string|array|Zend_Db_Table_Select. Kao što vidiš, za $where možeš da mu proslediš i objekat Zend_Db_Table_Select klase. Ali poenta priče je da u tom tvom custom metodu nema potrebe da pozivaš metod query(), bilo db handler-a, bilo Zend_Db_Table_Select instance, jer to umesto tebe radi metod _fetch(), a upravo taj metod se koristi od strane fetchRow() i fetchAll() metoda.

Pa kako bre nisam pogledao? :) Rekao si Zend_Db_Table_Abstract. Kopirao sam metodu fetchAll() da budem siguran da na nju mislis posto tamo nema da se bira sta da selektuje.
Sad si pomenuo Zend_Db_Table_Select, a to sa bas koristio drugoj situaciju iznad i bas u WHERE sam uglavio sta i gde da selektuje i trazi.

edit: mislim da kontam sta hoces da kazes, pogledacu detaljnije ujutro i probati.. sad sam bas pogubljen nesto. :)

Pozdrav,

pokusavam da uradim proveru dal je polje retype_password dobro prekucano ,i za to sam upotrebio Zend_Validate_Identical validator.

Problem je u tome sto ne mogu da u okviru forme lepo prosledim vrednost u Zend_Validate_Identical konstruktor...

Pokusao sam sa $this->getElement('password')->getValue() i ovo ne radi.

Inace ako prosledim $_POST['password'] radi normalno, al verovatno ima ispravan nacin za ovo..

U cemu gresim ovde ?

Pa naravno da ne možeš, jer u trenutku instanciranja, odnosno, unutar konstruktora, vrednost tog tvog password polja još uvek nije set-ovana. Rešenje je da redefinišeš isValid() metod, i da tek u njemu "zakačiš" Identical validator, budući da tom metodu prosleđuješ podatke iz forme ($_POST), a unutar njih je i vrednost password polja. Npr.:

U ovom mom primeru, to tvoje polje za potvrdu password-a se zove "retype_password".

Za proveru lozinke je najlakse "sklepati" custom validator, koji se nakaci na "retype_password" element:



$value nosi vrednost retype_password polja, a $context ostalih polja iz te forme (zato provera za $context['password'])

@Nikola,

Da, u pravu si, napravio sam gresku, jer sam pokusao u init() forme sve to. tnx! Izveo sam to redefinisanjem ove isValid() metode u okviru forme.

@Kazil
Video sam ovaj custom validator(u ZF dokumentaciji ga navode kao preporuku za ovaj problem), al nekako je krace - slajde
Sto bih pisao kompletnu klasu za poredjenje dva string-a Jednom je to neko lepo rekao (mislim bas Nikola),
Zend lako resava kompleksne probleme, i komplikuje izvodjenje lakih zadatka..

..Nego evo vec imam jos jedno pitanje:

Mislio sam dal slucajno nekako moze da se zaobidje ovo rucno prevodjenje bar ovih poruka o greskama iz Zend_Validate klasa:

i da se to nekako izvede automatski samo biranjem jezika ?

Evo sam sebi da odgovorim,

nasao sam u folderu resources/languages/sr sve prevode gresaka za Zend_Validate klase (dostupno ako se skine full ZF paket)

Opet ja sa novim problemom

Evo php koda iz layout.phtml fajla:

Evo i jquery koda iz layout.phtml:

Problem je u tome sto iako lepo izrenderuje tabove(stilovi ucitani) fali sadrzaj ovog contentUrl u href attr.
Inace juce je sve radilo dobro, sad ne kontam sto ne radi, ne vidim gresku..

I jedno pod pitanje , jel ove ajax handlere treba drzati negde u nekom posebnom folderu za to,
ili se moze taj sadrzaj pribavljati u nekom kontroleru pa ga slati sa $this->_helper->json() ?

Za glavno pitanje nemam odgovor, posto nisam koristio tabove (jos (vidis, u sledecem projektu ce mi mozda bas oni trebati)), a sto se tice podpitanja, da, ja bih definitivno isao preko kontrolera/akcije (cemu sam dizao onda ceo stack, kad cu da pozovem tamo neki obican ajax.php). Samo pazi da ugasis layout, mada cini mi se da json action helper ugasi sam.

Ja sam iz tog ZendX paketa koristio samo datePicker, i to kroz ZendX_JQuery_Form_Element_DatePicker, ali evo sad sam bacio pogled na kôd tabContainer view helper-a, i ovako na prvi pogled, čini mi se da si na pogrešnom mestu prosledio taj argument sa opcijama za druga dva tab-a. Parametar sa opcijama je, koliko vidim, četvrti po redu, a ti si ga prosledio kao treći, što znači da će to automatski da ode kao $content. Mislim da bi to trebao da napišeš ovako:

btw Nadam se da ti ne ispisuješ ručno taj JS kôd, već da koristiš echo $this->jQuery(); negde u head sekciji tvog layout-a, koji će sav potreban JS ispisati za tebe.

A što se tiče drugog pitanja, pa može i tako, samo je možda malo nepraktično da zbog nekog prostog output-a koji bi bio rezultat tog AJAX zahteva prolaziš kroz ceo bootstrap proces. U principu, svejedno je kojim ćeš načinom to realizovati, jer i kad bi ti taj ajax handler bio u nekom zasebnom skriptu, opet bi morao da bootstrap-uješ bar neke resurse, npr. Autoloading, ali je možda prednost takve realizacije to što nema, u te svrhe, nepotrebnog dispatch-ovanja.

Heh, tnx, bilo mi logicno to u okviru akcije sa json(), al rekoh da proverim(u pravu si, disable-uje layout, kaze dokumentacija )..

Uf izvinjavam se za ovo glavno , nepaznja, desava se. Ja sam gledao definiciju metode:

tabPane($id, $content, $options) umesto za
addPane($id, $label, $content, $options) i tu je doslo do greske pri prosledjivanju parametara.



EDIT: Pretece me Nikola, da to je bila greska tnx!

Hmmm, pa ispisao sam ga rucno. Imam u head sekciji ovo:

I nakon toga echo $this->jQuery() al mi to generise samo link tag do stila, i script tagove do potrebnih jquery biblioteka, tako da sam uneo rucno recimo ("#tab").tabs() da bi to radilo.

Sad sam probao da obrisem .tabs() metodu, al ne radi. Nije valjda da moze bez toga ?

Nema potrebe da radiš to enable() i uiEnable(), jer to će da radi svaki taj view helper kojeg budeš koristio u zavisnosti od potrebe. renderMode je po default-u podešen na RENDER_ALL, tako da bi morao da ti ispiše sve, uključujući i sve što je dodato na $_onLoadActions stek. Za to je zadužen metod _renderExtras() u klasi ZendX_JQuery_View_Helper_JQuery_Container.

Probaj čisto testiranja radi da mu napišeš da hoćeš da render-uješ isključivo onLoad kôd, pa vidi šta će da ti ispiše:

Ne ispise nista kad stavim RENDER_JQUERY_ON_LOAD.

A kad uklonim enable() i uiEnable() i ostavim default render mod ne ispise cak ni one linkove i skript tagove u head sekciji.

E al' čekaj onda, kad kažeš u head sekciji, da li pod tim podrazumevaš head sekciju u nekom layout skriptu, ako koristiš Zend_Layout, ili je to head sekcija tog konkretnog view script-a u kome ispisuješ te tab-ove?

Ti kad ispišeš echo $this->jQuery(), to će render-ovati sve što je do tada "prikupljeno", a kako se to dešava pre nego što ti pozoveš tabContainer(), taj helper još uvek nije dodao njegov onload JS niti je odradio enable() i uiEnable(), tako da je sasvim logično što ne dobijaš nikakav ispis. Kada bi koristio Zend_Layout, koji je inače implementacija Two step layout pattern-a, tvoji view script-ovi bi imali samo sadržaj karakterističan za tu neku akciju, a sve što je zajedničko za ceo tvoj sajt/aplikaciju, npr. header, footer, bi se nalazilo u layout skriptovima. I sad, Two step layout radi na način da se prvo "pokupi" output tvog view script-a (u tvom slučaju prvo bi se izvršio tabContainer() koji će dodati svoj onLoad JS), pa se tek onda taj output integriše u layout (tek sada se izvršava npr. echo $this->jQuery() u head sekciji layout-a).

Nadam se da razumeš u čemu je problem. Ako hoćeš da koristiš ZendX jQuery view helper-e, i da ti pritom ZF ispisuje i JS kôd, a sve to unutar jednog view script-a sa kompletnim HTML kôdom, najbolje je da npr. uradiš sledeće... Najpre pozoveš tabContainer(), koji će da odradi svoj posao, a onda njegov output smestiš u neku promenljivu. Tek posle toga izvršiš:

A onda naravno onaj output kojeg je vratio tabContainer() ispišeš na određenom mestu.

Sad generise sve kako treba, kad sam pozvao tabContainer() pre ostalih metoda.. Hvala!!!

Da, koristim Zend_Layout i radi se o head sekciji layout.phtml, tu je ono zajednicko za sve stranice sto si naveo, header, footer,
a u body stoji echo $this->layout()->content, i tu se nalazi onaj sadrzaj karakteristican za odredjenu akciju (koji dolazi iz odredjenog view skripta) , ako ne gresim ?

Tabovi su mi zajednicki za sve stranice za default modul, pa sam mislio da bih trebao da ih generisem u layout.phtml, zar ne ?

Pa da, tako je, ali kažem ti, ja sam mislio da je taj deo sa tabContainer-om karakterističan za određenu akciju, pa mi je logičnije da njega pozivaš u nekom konkretnom view script-u, nisam iz prve shvatio da je tebi i taj deo u layout-u.

Potrebno mi je da neke parametre koje zadam u ini fajlu koristim u view (.phtml). Ovi parametri bi bili potpuno odvojeni od sadrzaja pocetnog ini fajla.

Za sada sam uspeo iz bootstrap-a (glavnog - ima ih tri zbog dva modula) pozvati plugin koji ce ucitati novi ini fajl i objekat koji napravi poslati u view:


Iz layout.phtml mogu da pristupim, ali meni treba i u kontroleru i u view. U kontroleru i kada izvucem view slicno kao u plugin-u, opet nece.

Kako to da izvedem i ako moze ukratko objasnjenje zasto ovako nece? Izgleda mi da sam nesto propustio a tice se funkcionisanja zenda. Izgubio sam se malo u manual-u...

Hvala. :)

FC plugine koristi kada trebas uraditi nesto nad akcijom/kontrolerom/modulom. Za view koristi view helpere http://framework.zend.com/manual/en/zend.view.helpers.html

Čim imaš potrebu za takvim nečim, onda tu nešto ne valja u samoj koncepciji tvoje aplikacije, ali ako baš mora tako, ovo je jedan od načina za dohvatanje one glavne konfiguracije, koju prosleđuješ Zend_Application-u, bilo gde u kôdu:

U tom nizu $config sad imaš pristup svim konfiguracionim parametrima.

Pa mozda nije najsrecniji nacin, ali to mi je prvo palo na pamet. Evo da pojasnim.

Parametar koliko ce necega (slika, pesama...) biti na pocetnoj strani je potreban u kontroleru tj. modelu za limit (query).
Onda iz admin panela ukljuciti ili iskljuciti neki element (obican div sa nekim sitnicama unutra) na nekoj strani. Taj parametar je potreban u view.

Sve to treba da bude pregledno i lako editovano preko nekog formulara. Ini odogovara ali pozeljno je da bude odvojen od onog pocetnog. Samo je pitanje kako je najbolje da parametri stugnu u kontroler i view.

Mozda postoji neko bolje resenje za ovo?

Nisam baš najbolje razumeo taj deo sa admin panelom, ali uglavnom, ti tu tvoju custom ini konfiguraciju možeš da wrap-uješ u Zend_Config_Ini objekat, i onda taj objekat da ubaciš u Zend_Registry. Sve to bi radio u nekom metodu tvoje bootstrap klase, npr.:

I onda posle bilo gde u kôdu (kontroler, view script) imaš:

Odlicno, izgleda da je to to. :) Tnx.

A to za admin, pa pojasnicu ako mozda postoji neko drugo resenje, mada sam i sa ovom zadovoljan. Dakle, form u admin panelu u koji se unosi recimo koliko ce komentara da bude prikazano za neku pesmu/sliku (sta god..), zatim koliko rezultata u pretrazi da se prikazuje i jos neke korisnije stvari. Znaci neki parametri za koje je pozeljna mogucnost lake izmene, a neophodni su na vise lokacija u aplikaciji.

Ali, kao sto rekoh i ovo je dovoljno dobro za mene osim ako se neka druga metoda primenjuje bas po standardima zend-a?

A gde ti upisuješ podešavanja iz te fome u admin panelu? U bazu ili direktno u taj .ini fajl? Ako ih upisuješ u .ini, onda je ovo što sam predložio sasvim dobro rešenje.

Sta mislis, sta je bolje?
Prvo je bilo u bazi, ali cini mi se da ce malo brze pristupati ako je ini. Nekada je konekcija ka bazi uzasno spora, a uz to vec imam dosta upita, tesko da se tu nesto moze optimizovati.

Ovako kako je sad, upisuje se direktno u ini a moguce da ce postojati jedna tabela pa kesirati i osvezavati svaki put kada se nesto promeni.

Pa ne znam, u principu je svejedno. Meni je nekako logičnije da se podešavanja drže u bazi, mada što da ne, može i .ini fajl da se korisiti u te svrhe. Ako te brinu performanse, ti ćeš i u slučaju da su podešavanja u bazi raditi istu onu priču sa Zend_Registry-jem, odnosno, samo jednom u okviru zahteva (npr. u bootstrap-u) ćeš se obraćati bazi kako bi dohvatio sva podešavanja, a onda bi taj rezultujući niz sa podešavanjima smestio u registry.

Da to definitvno. Nisam mislio svaki put da pitam bazu. :)
Kontao sam da je dohvatanje tih podatak mozda brze ako je u fajlu nego u bazi. Ali to je tu i tamo relativno jer zavisi od servera i od toga sto treba parsirati ini. Verovatno cu ako me ne bude mrzelo napraviti tabelu i srediti kesiranje pa da cita iz fajla a iz baze samo jednom kada bude promena pa da osvezi kes.

Jedno,dva pitanja oko onoga "Skinny Controller, Fat Model"

Recimo da imamo kontroler gde treba da se uradi par upita(INSERT, REPLACE INTO..)
Koji je razlog da kontroler ne bude "Fat",(sta je kriterijum kad kontroler postaje "Fat" ?), a model "Skinny"(a mozda i da ga uopste nema), jer sve moze ovako da se zavrsi:


Koja je prednost toga da napravim model koji ce da prosiri Zend_Db_Table pa da radi to isto, samo pre toga umesto da dovucem def. db. adapeter, napravim novi
objekat konkretnog modela. Prednosti koje vidim su te da bih sklonio sebi sa ociju iz kontrolera ovaj ruzni REPLACE INTO upit od nekoliko linija koda u model, tj. da napravim metodu,u kojoj bi se on izvrsavao, pa bih u kontroleru imao samo poziv te metode sa jednim parametrom. I jos eto mogao bih da uradim Caching Table Metadata mada ni to ne znam jel se dobija nesto sa tim u odnosu na rad samo ovako sa Zend_Db_Table na nacin koji sam naveo?

U teoriji, u modelu treba da se sadrzi "bussiness logic" a ne samo interfejs ka DB sloju, a kontroler je tu da odabere koja logika treba da se primeni za konkretan request. U praksi ljudi obicno drze samo DB u modelu.

Ja se trudim da mi kontroler bude samo "raskrsnica" koja ce ispitati request i pozvati odgovarajucu logiku iz modela.
Na stranu sto je kratak kontroler brz za ucitavanje i parsiranje pa ne davim CPU viskom koda.
Na taj nacin mi je kontroler jednostavan za pracenje, a model ako postane previse 'fat' onda ga rasteretim tako sto izvucem krupnije metode u zasebne datoteke a u metode stavim samo jedno 'include'.

Primer prednosti ovakvog rada je kad se pojavi potreba da listu reg. clanova sa sajta exportujem u xml jednostavno copy/paste-ujem metod model koji to vec prikazuje na formi (a to mogu jer je u 'fat' modelu dovoljno izolovan od kontrolera) i dodam u kontroler poziv ka tom novom metodu. Poenta je u kolicini programerskog posla jer nemas potrebe da analiziras okolinu, sva potrebna logika je na jednom mestu, i gotovo za 1 minut.

Termin 'fat model' upravo to i oznacava - spajanje logike sa interfejsom ka DB sloju.

Pa ta paradigma je svakako nešto čime bi trebao da se vodiš, jer business logici jeste mesto u modelu, ali ne moraš po svaku cenu, zbog neke stvari za koju npr. znaš da je nećeš reuse-ovati nigde drugde osim u tom kontroleru, da praviš klasu koja bi čuvala samo taj jedan metod. E sad, ako je to neki insert nad jednom tabelom, onda je pametnije da, bar zbog sebe, za svaku tabelu u tvojoj aplikaciji imaš i table gateway modele (klase koje se izvode iz Zend_Db_Table), pa da ih onda po potrebi iskoristiš za tako neki insert, update, fetch, itd.

A to metadata keširanje koje si spomenuo nema nikakve veze sa prethodnim delom tvoga post-a. To keširanje je i te kako preporučljivo, ja bih čak svrstao u obavezne stvari, jer to i te kako utiče na performanse. U pozitivnom smislu, naravno. U suprotnom, svaki put kad praviš instancu nekog table gateway-a, i pri pokušaju npr. insert-ovanja podataka, biće izvršen _setupMetadata() metod (pogledaj kôd tog metoda), koji će u slučaju da metadata nije inicijalizovan ili ako se podaci za njega ne nalaze u cache, raditi "naporan" DESCRIBE upit, kako bi pokupio informaciju o kolonama u određenoj tabeli. Najbolja varijanta, naravno bolja i od keširanja, jeste da hardcode-uješ metadata te neke tvoje tabele, tako što ćeš u tvom izvedenom modelu redefinisati $_metadata promenljivu (u njoj se nalaze ti podaci o kolonama) i ručno uneti definiciju tvoje tabele, npr.:

@Miroslav

Heh, bas zato pitam jer u tom doticnom kontroleru i nema toga sto se naziva "bussiness logic", bar mislim da nema(kao na drugim mestima gde sam imao potrebu da pravim po koju dodatnu proveru i sl. unutar modela) Evo sta se jedino desava u tom kontroleru(RateController):

- prikupe se podaci (contentid,ip,grade)
- uradi se validacija (contentid se kastuje u int, ip se proveri dal je stvarno ip, grade se proveri jel izmedju 1 i 5 i to je to)
- ako su podaci dosli preko AJAX-a radi se insert, i select(da bi vratio JSON objekat sa novim vrednostima)
- ako su podaci dosli standardno radi se insert i redirect na stranu odakle je glasano

I ovaj kod koristim samo na tom mestu i nigde vishe.
Ne kazem da sam pomislio da treba praviti debele kontrolere, citao sam ja ovaj odlican clanak Model ali posto je ceo kontroler sa dve akcije stao u 70 linija , a nema biznis logike koja bi se ticala samog modela, pomislio sam sta da uradim


@Nikola
..Ovo za kesiranje se nisam izrazio izgleda dobro.. Al nema veze , napisao si to sto me je interesovalo, i odlucilo da radim tako za prakticno sve tabele

Dal mozete da kazete sta mislite o ovoj logici za kontroler, kad sam ga vec pomenuo.
Naime imam vise sadrzaja koje se mogu ocenjivati, sa vise razlicitih stranica,
pa sam sa one dve poslednje stavke to resio, interesuje me misljenje za onaj redirect ?

Ja mislim da je bolja ideja to ocenjivanje radiš samo AJAX-om, pošto cenim da je u pitanju neki rating sistem kojeg ćeš imati na više stranica tvog sajta. Verovatno imaš neki view helper kojim ispisuješ taj neki rating widget i kojeg reuse-uješ na stranicama tog tvog sajta, a onda samo na to treba da "nakačiš" neki JS/AJAX.

Ako nećeš da ideš sa AJAX-om, druga ideja bi bila da napraviš action helper, koji bi u nekom od hook-ova (npr. preDispatch) obavljao ceo taj proces glasanja, ako "primeti" da je POST-ovano nešto od onih podataka za koje je zadužen, npr.:

Njega naravno moraš da dodaš helper broker-u.

Izvinjavam se sto prekidam. :)
Da li je neko imao problema sa set_include_path na linux-u? Ubuntu 10.04, apache 2.2, php 5.3.2 ako to nesto znaci..
Pitanje bas i nema veze sa zend-om (sry) osim sto je u njemu radjena aplikacija.. :)

Kad sam vec prekinuo, da napisem i nesto vezano za trenutnu diskusiju.
Po meni dve opcije:
-kontroler prihvata podatke i takve kakvi su salje modelu na proveru i izvrsenje
-ajax svuda (manje piskaranja u kontroleru), kontroler proveri i model odradi

Generalno mislim da nije strasno da kontroler obavi po koju proveru/ispravku ali ono sto ima veze sa bazom ide u model. Trebalo bi sve u model.. ali to je na onome ko pise, ako misli da nije strasno 2-3 linije i da mu kasnije nece predstavljati problem - onda ok.

Problem je kod setovanja ogovarajuceg layout-a. Postoje dva modula i potrebno je promeniti putanju do layout-a uz pomoc front controller plugin-a. Evo ovako je to izvedeno.

.....application\modules\admin\Bootstrap.php



.....application\modules\admin\plugins\LayoutInit.php


application.ini



Ovo savrseno radi na windows-u, ali na linux-u nece. Za sada je ovo jedini problem jer klase iz zendove biblioteke pronalazi, modele koji imaju ili nemaju veze sa bazom isto pronalazi. Samo za ovo izbaci error da plugin (pa ime) nije pronadjen i ime fajla sa rednim brojem linije gde se poziva. Sad sam u win-u, nisam kopirao.. ali mislim da je jasno sta pise.

Ima li neko ideju sta je u pitanju?

Koju ti tačno grešku izbaci? Da nije pronađena ta klasa Admin_Plugin_LayoutInit ili nešto drugo? Napiši šta tačno izbacuje kao grešku...

Evo:


Ovo je include path ehovan na isto mestu gde se plugin poziva:


A ovo napise za require_once:


Guglao sam i naso na jos par mesta slican problem, ali nema resenja.

A jesi Google-ao nešto tipa "require_once permission denied"? Ta greška koju ti izbacuje nije do ZF-a. Ja nisam neki Linux guru, ali proveri prava pristupa fajlova koje imaš u tom application/modules/admin/plugins folderu.

To sam i ja pomislio i onda sam aktivirao root nalog i ista prica. A imao sam problema sa instalacijom servera jer nisam ni ja linux guru, pa sam uradio potpuno svezu instalaciju ubuntu-a i sa root nalogom instalirao mysql, phpmyadmin i zend server sto ce reci svi folderi i fajlovi pripadaju root-u i dok sam logovan kao root istu gresku prijavljuje.
Aplikacija koju sam radio pod win-om nije bas mala pa mi je bilo lakse da rekonstruisem pocetne korake kroz novu aplikaciju nego da trazim gde bi bio problem u postojecoj. Tako sam za par minuta dosao do greske da ne moze da pronadje klasu. Isto to na win-u radi normalno.
Kontam da ima veze sa include path ili dozvolama... ali i jedno i drugo je u redu.. pojma nemam.

Ovo vec nije za ZF, al ajd :)

To sto si ti ulogovan kao root, ne znaci da je i web server root. Na debian based sistemima web server trci pod korisnikom www-data, koji pripada www-data grupi. Najverovatnije da i zato ne moze da setuje include path i da ti ucita potrebni file.

Idi na /path/to/app i uradi jedan ls -l. Fileovi moraju biti 644 (rw-r--r--) a direktorijumi 755 (rwxr-xr-x). Korisnik i grupa da budu ili tvoj licni nalog (kod mene na test masinama tako drzim, na produkcionom je drugacije - www/www-data) ili poseban korisnik za web stvari. Nikako ne sme da bude root. Nikako nikad ne smes nista da radis kao root. Ako ti trepaju vece privilegije za nesto, koristi sudo.

Probaj sledece:



Gde ces pera zameniti sa svojim korisnickim imenom i grupom (prvo pera je ime, drugo pera je grupa). Ovo bi trebalo da iznamesta permisije.

E to care, svaka cast. Hvala ti puno, ustedeo si mi mnogo zivaca. :)
Znam za to da se ne sme nista raditi kao root, trazeci kako da ga aktiviram procitao sam na njihovom sajtu da se ne preporucuje, a i postoji sudo pa nije ni potreban. Ali kad nisam znao sta vise da probam...
Ja kontao "root" i nema vise privilegija za ovo pa za ono.. moze sve. :)

Uglavnom radi korektno. Za bazu sam morao da promenim resources.db.adapter = "Mysqli" i resources.db.isdefaulttableadapter = true a bilo je PDO_MYSQL. To sam iskopao na google.
Jedino sto za index za lucene search koji je napravljen pod win-om prijavljuje application error (samo to). A na winu radi normalno. I ti fajlovi su pretrcani sa onim sto si napisao gore (nalaze se u istom diru gde i ostatak aplikacije). Include path sam echovao i u redu je skroz.
Da nemas mozda ideju sta je u pitanju?

Jos jedno pitanje i onda definitivno zavrsavam o linuxu :). Particija kreirana na winu, D particija, kada se mountuje u linuxu - koja je adresa nekog foldera sa te particije. Mislim da cu raditi malo na winu malo na linuxu bar u pocetku dok se skroz ne naviknem pa da ne bih stalno copy/paste sa particije na particiju mislio sam da isti folder koristim na oba sistema.
Evo recimo ovako neki folder: "D:\www\test.com\public". Na linuxu pise da je to "/media/ime_particije(D)/www/test.com/public" ali kad to unesem u site-available/test.com nece da radi.

Jos jednom sry za off i veliko hvala. :)

Sta ti znaci: "....ali kad to unesem u site-available/test.com nece da radi...."?
Kako mislis "nece da radi" ?

Jesi li u 'httpd.conf' dodao pravu putanju '/media/{disk}/www' ?

Moguce da je problem to sto ti nije "mount-ovana" ta WIN particija, posto se pri paljenju Linux-a, to ne radi automatski - potrebne su root privilegije...

Za lucene... bem li ga, probaj nad tim fileovima da postavis www-data:www-data korisnika/grupu, isto sa chown -R (-R je da odradi rekurzivno).

A za ovo drugo, zamolio bih te da probas u recimo Linux/Unix serveri i servisi forumu ;) em ces tamo dobiti tacno resenje, a i ova tema ce ostati cistija. Hvala na razumevanju :)

Ok, sry, jasno mi je. Nisam znao da su u pitanju dozvole ili nesto slicno do linuxa... u protivnom bih odmah otvorio temu na linux serveri forumu.
Ovo za lucene si isto resio, hvala na pomoci i na strpljenju. :) Necu vise o linuxu ovde. :)

Pozz

OK, nije problem ;) drago mi je da je reseno. Ovo za linux forume sam rekao cisto da ne odemo previse offtopic ;)

happy hackin' :)

U bazi sam neke kolone nazvao "nesto_nesto", jer mi je tako bilo lakse. Praktikujem da to uglavnom bude "nestoNesto", ali kada je to pocelo od baze bilo je logicno da u $insertData['nesto_nesto'] stigne $nesto_nesto. I na drugim mestima gde se pojavljuje $nesto_nesto definitivno je jasno gde to ide ili odakle dolazi (sql).

Da li oni savetuju samo slova i brojeve jer u protivnom moze doci do zavrzlame (iako donja crta nije na pocetku imena - to je jasno gde se koristi) ili samo zato sto izgleda lepse? Da li da menjam ili ne?

Pitao bih vas i ovo:



nece


hoce


To getDefaultAdapter() sam stavio u init pa $this->_db = $db.. nisam siguran da li se to drugacije radi?

Jos nesto. Jel moze neki kratak, jednostavan primer kako vi saljete error i kako saljete obavestenje u view. Recimo neka greska koju nece sam prijaviti ali je bitna za normalno prikazivanje strane i obavestenje da se nesto uspesno obavilo ili sl.

_{[Ovu poruku je menjao strutter.poison dana 07.08.2010. u 07:15 GMT+1]}

Ovo za variable names se moras pridrzavati jedino ako radis na nekoj ZF komponenti. Ako ti je u tvom kodu lakse da imas underscore, koristi. Tvoj kod, tvoja odluka :)

Hoce ;)


Za obavestenja koristim flashMessenger action/view helpere.

Otimam malo thread :P

Zend Framework 2.0.0dev1 pusten u "divljinu"! \o/ http://devzone.zend.com/articl...t-Milestone-of-ZF-2.0-Released

Svidja mi se kako i u kom pravcu napreduju. Prosli vikend sam fork-ova na github-u source i jedan projekt prebacio da koristi zf2... I radi :D ok, neke bitne razlike nema, ali jednog dana ce biti. sav sam nestrpljiv da vidim koliko ce dobiti na performansama kada se odradi rewrite nekih stvari :)

E super, to radi. Mnogo je lepse i prakticnije tako. Tnx. :)

Na brzinu sam pregledao kôd par komponenti (Zend\Form, Zend\Validate, Zend\Application, Zend\Controller\Front, Zend\View, itd.), i vidim da za sada uopšte nema promena u koncepciji tih komponenti. Cilj ovog release-a je bio da sve kompletno prebaci na namespace-ove, što je i učinjeno.

Priča se da će u ZF 2 biti integrisan Doctrine, a to će onda biti ubojit tandem.

Otkud to za Doctrine? o.O gde si to cuo/procitao? To sto znam je da ce Zend\Db dobiti mozda najveci overhaul od svih komponenti, ali za Doctrine nisam nista cuo.

Zend\Session je potpuno prepisan od nule, ubacen je Zend\StdLib i Zend\SignalSlot.

E stvarno ne mogu da se setim gde sam čitao o tome, dal' na devzone-u, ili tako nešto, a više se ni ne sećam dal' je to bila samo nečija želja ili je to pomenuo neko od core developer-a...

Da, Zend\Db će biti potpuno refaktorisan, ima jedan lep članak u kome su opisano planovi za Zend Db 2.0: http://www.phparch.com/2010/06/25/zend-db-2-0-kicks-off/.

Eto, Session komponentu još nisam stigao da proučim. Sad tek vidim da su tu SessionManager, SessionStorage, itd.

Ja iskreno sumnjam da ce biti Doctrine-a u zf2. Nema zasta da ga ubacuju, kad vec i ovako moze lepo da se uklopi (koliko sam citao o tome, nikad nisam radio sa Doctrine-om). Sto se tice Zend\Db ovo je tekst o njemu.

Jos jedna novina koja se planira za zf2 je Wibble, biblioteka za ciscenje html-a (nesto poput HTMLPurifier-a, samo radi sa DOM objektima, a ne sa regularnim izrazima; btw. HTMLPurifier je trenutno najbolji out there za taj posao). Da li ce na kraju biti skroz ubacen u zf2 ili ce biti 3rd party lib, ne znam (bilo bi lepo da udje skroz, a i iskreno sumnjam da ce Pádraic ostaviti da bude 3rd party lib).

Ono sto mi se posebno svidja jeste da su razvoj prebacili sa svn-a na git, kontribucija je mnogo laksa ovako.

U poslednje vreme se skupilo dosta stvari koje mi nisu jasne u vezi ZF-a. Za vecinu sam nasao odgovor na google i zf manual.. Ostalo mi je ovo ispod, pa ako neko moze da mi pomogne.

-Kako da u kontroleru dobijem samo url parametre? getRequest()->getParams() daje i form/post i url, pa sam napravio jednu metodicu da uradi unset svih getPost() iz getParams(). Jel postoji neko elegantnije resenje?

-Da li zf ima neku podrsku za exec()? Kako da generisem komandu za premestanje/brisanje/menjanje imena veceg broja fajlova a da to radi pod razlicitim sistemima? Mislim, znam koje su komande, interesuje me da li postoji nesto kao sto je za bazu ili moram peske?

-Kako sam shvatio zf radi escape za upite koji se kreiraju uz pomoc njihovih metoda/funkcija. Kako uraditi escape (recimo mysql_real_escape_string) za neke custom upite? Ovde je neko savetovao da se u glavnom index.php uradi escape za session, coockie, get i post, ali posto je za mysql_real_escape_string potrebna konekcija sa bazom.. da li zf ima resenje za to ili.. kako uopste vi to radite?
Nisam siguran da se moze ubaciti injection u lucene... i jeste da korisnik ne inicira nikakve radnje sa bazom preko lucene ali svakako me zanima i za to neki escape ako ima potrebe. To su neke od funckija kojima korisnik zadaje parametre za izvrsenje, pa su po mom misljenju od kljucnog znacaja za sigurnost.

-Da li zf ima nesto sto ce utvrditi da li je upload-ovani fajl slika ili ne? Guglao sam ali nista nisam nasao, pa kontam da verovatno nema tako da je moje pitanje u stvari koje korake da preduzmem da bih se zastitio? Ovde: http://ha.ckers.org/blog/20070...ious-php-through-getimagesize/ pise da getimagesize() nije dovoljno. Sta vi savetujete?

Hvala. :)

1. baci pogled na getQuery() metodu (nad request objektom). Ona vraca sve iz $_GET-a.

2. nope, sam si.

3. errr... postoji ona quoteInto() metoda nad database adapterom. Ti ovo pitas za lucene? Za to ne znam da li uopste treba nesto da se escepuje prilikom upisa. Ovo bolje nek neko odgovori ko je radio sa lucen-om.

4. Zend_Validate ima validatore za ekstenzije, velicine, slike... Zend_Validate_File_*.

3. pitam i za lucene, a i za bazu. Kontam i ja da za lucene verovatno nema potrebe.. al' ajd da proverim ipak. Verovantno sam malo opterecen sa funkcijama na koje mogu da "uticu" korisnici.

4. Hm, izgleda da sam koristio to preko addValidator, ali samo za size i extension.. ako je to to. :) Bacicu pogled na taj validator.

Ok, hvala puno, izgleda da je uptavo to sto mi treba. :)

Evo pola dana sam izgubio sledeci nekoliko objasnjenja o ZF (Zend Studio) i PHPUnit i kod svakog mi pukne film posle nekog vremena jer mi izbacuje kojekave greske... glava me zabole. Nagore sto sam jedan video odgledao ceo a traje 40 minuta. Sve lepo objasnjeno, ali sipak! Kako tek od skoro koristim linux lose se snalazim i nisam mogao da namestim da to radim iz terminala (a zend studio se zabada i brljavi). Vidim da je za zf 1.8 ali osim putanje za phpunit mislim da taj tests deo nema razlike... slicno i sam zend studio generise (ali ni to nece da mi radi).

Na kraju sam tu malu test aplikaciju obrisao i sad cu vas moliti za neki link sa kog ste vi skapirali kako se to radi. Ili kako da sredim to za terminal kao sto je kod tog lika na pocetku videa (prvih 1-2 min.)

E da, getQuery()... kod mene je bilo ovako nesto "/param1/value1/param2/value2". Tako se, ako se nevaram, negde jos na pocetku formirala adresa sa parametrima (paginacija ili nesto slicno).. i ja sam to ostavio (na nekim mestima sam korigovao sa addRoute). Nisam koristio ?foo=bar na mestima gde mi trebaju samo parametri iz url bez form, tako da mi u ovom slucaju getQuery() nije resenje. Ali... mozda bi moglo da bude ako bih krenuo da menjam u ?foo=bar. Ima li nekog pravila sta je bolje? Sta se vise praktikuje u zf? Ovako radi.. da ne zeznem nesto? :)
Meni lepo izgleda kada se sa sredi addRoute ..../:action/:param1/:param2.... ali to sa getQuery ne mogu da dohvatim.

Probaj sa getParam().

A sto se tice phpunit-a... Nisam nista specificno radio, pratio neke blog postove i to je to... Instalirao phpunit i radi. Nisam radio nikakva podesavanja. Radi i iz terminala i iz netbeans-a (jedino sam primetio da ako radim testove iz netbeans-a da uspori, ne jako, ali osetim, tako da se drzim terminala).

Za getParam() treba da navedem koji parametar. Meni trebaju svi iz url-a.
Imam form sa brdom podataka recimo, ako hocu da nakon unosa posljem korisnika na adresu sa koje je stigao zajedno sa parametrima plus jos neki novi.. morao bih sve parametre zajedno sa form-om da saljem uz novi zahtev. Kako sam razumeo nakon te redirekcije se ponovo bootstrapuje aplikacija? Ako form tezi koliko sve klase koje se ucitavaju zajedno.. to je duplo. Ajd i ako nije sa pogleda memorije strasno.. opet mi bez veze da ga setam tamo-ovamo.

Reci mi, molim te, jos nesto. Imas taj folder tests ili kako god da ga zoves i priblizno neke fajlove kao sto je u onom primeru gore (ili ovom ispod)? Jel na isti nacin iz terminala pokreces test? Nesto slicno ovom:
cd tests
phpunit --configuration phpunit.xml --verbose

Inace onaj video je napravljen prema ovom tekstu koji je prilicno sazet i svidja mi se, ali nije mi jasno to za phpunit komandu u terminalu.

Tebe niko ne prisiljava da u svom kôdu striktno koristiš request objekat kao izvor parametara. Možeš slobodno da se služiš $_GET, $_POST, $_REQUEST, itd. A i druga stvar, što malo ne pogledaš kôd Zend_Controller_Request_Http klase... Pored metoda getParam(), tu je i metod getParams(), koji će ti vratiti $_GET + $_POST.


A zašto bi to radio? Ako sam dobro razumeo, ti samo hoćeš o da nakon submit-ovanja forme, ponovo prikažeš te podatke koje je korisnik uneo. Zašto bi redirektovao korisnika na istu stranu kada je on već tu? Dovoljno je samo da view-u daš $myForm->getValues(), pri čemu je $myForm ta neka tvoja forma, kojoj pri validaciji daješ $this->_request->getPost() ili getParams() u zavisnosti od metode kojom je forma submit-ovana. A ako koristiš sloj za dekoraciju kojeg nudi Zend_Form komponenta, tačnije, ako i samu instancu forme predaješ view-u kako bi je posle output-ovao, onda uopšte ne moraš misliš na to, jer će vrednosti polja u formi automatski biti postavljene nakon validacije forme, odnosno nakon što isValid() metodi proslediš $_POST/$_GET.

A što se unit testova tiče, ovde imaš jedan dobar članak o pripremi testing environment-a u okviru neke ZF-based aplikacije.

Nikola, poznato mi je sve to sto si napisao. Malo se mucim sa zendom ali php generalno poznajem koliko toliko. :)
Listao sam klase vezane za Zend_Controller_Action i nisam nasao tacno ono sto sam trazio. Dohvatanje forma ($_POST) i dohvatanje parametara sa formom je ok. Ali, /param1/value1/param2/value2 ili value1/value2 nisu u $_GET.
Kao sto rekoh negde na pocetku je jedna od klasa kreirala takve url-ove i ja se nisam cimao oko toga, samo sam ih ulepsao sa route. Sad, ako hocu da ih vucem iz $_GET moram da stavim ?param1=value1&param2=value2 ili da pokupim sve parametre zajedno sa $_POST i da filtriram tj. uzmem samo post i iz niza gde su svi unset ovih iz post.

Stranica na koju saljem korisnika nece sadrzati $_POST vec samo parametre iz url plus mozda jos 1-2 dodatnih, a setanje gomile teksta iz $_POST mi nekako bez veze.. Pitao sam se da li moze nekako da se pokupi samo ono /param1/value1/param2/value2 bez dodatnog komplikovanja... nisam nasao metodu koja to radi...

Naleteo sam na taj link za phpunit, ali ako cenis da je dobar clanak sad cu ga prostudirati.. valjda cu danas uspeti da se resim glavobolje. Ccccc kako jednostavne stvari znaju da se iskomplikuju.. cudo jedno. :)

_{[Ovu poruku je menjao strutter.poison dana 12.09.2010. u 23:28 GMT+1]}

Hm cudno... Sigurno se moze pristupiti tim podacima. Probaj sa getUserParam('param'); odnosno getUserParams();

getUserParams()

E to je to. Svaka cast. Sa ovom se dohvataju samo parametri iz url-a. Respect!

Tnx. ;)

_{[Ovu poruku je menjao strutter.poison dana 12.09.2010. u 23:25 GMT+1]}

Ali čudno je da sa getParams() nisi dobio te parametre iz url-a pošto je taj metod proširenje onoga što vraća getUserParams(). Evo komentara iz docblock-a metoda getParams():

A i još je jasnije ako se uporedi kôd tih metoda:

Metod getParams() vraća $this->_params plus još $_GET i $_POST.

Iz tog niza koji vraca getParams() sam uklanjao form da bih dobio samo parametre iz url-a. Kontas... trebaju mi samo url parametri. Metoda koju je Robert nasao getUserParams() radi tacno to sto mi treba.

Evo napravio sam na brzinu login (u konkretnom slucaju nije login ali posluzice da se docara sustina) kontroler bez adaptera/provere i ostalih zavrzlama.. samo da testiram:

/login/index/foo/bar?foo1=bar1

print_r($this->getRequest()->getParams());

print_r($this->_getAllParams());

print_r($_GET);

print_r($this->getRequest()->getUserParams());


E sad, posto bih mozda dodao negde ?foo=bar gde su parametri formulisani /foo/bar necu ih dohvatiti sa getUserParams(). Lici mozda da nije bitno jer sam vec poceo sa /foo/bar ali mozda bi bilo bolje da sada vec udesim tako da akcija reaguje i na /foo/bar i na ?foo=bar ... mozda ce da zatreba, posto je to ista grupa parametra.
Sta mi savetujete? Sve /foo/bar ili ?foo=bar ili da prilagodim dohvatanje parametara i za jedno i za drugo (ali bez $_POST)?

Ovo ispod (tacno tako) sam instalirao pre mesec-dva i do sada nisam imao vecih problema osim nekih mojih previda.
sudo apt-get install mysql-server
sudo apt-get install phpmyadmin
Onda sam instalirao zend server uz pomoc skripte: ./install_zs.sh 5.3
Zatim Zend Studio (.bin fajl je bio).

Onaj zip fajl u kom je par kontorlera i modela samo da se demonstrira phpunit i zf sam ubacio u novi virtual host i iz browsera radi normalno.

Kada instaliram phpunit isto sa apt-get i ukucam "phpunit" dobijem: /usr/bin/env: php: No such file or directory.
Kada odem na onaj folder tests i ukucam phpunit --configuration phpunit.xml --verbose opet dobijem /usr/bin/env: php: No such file or directory.

Da li ja gresim negde, da li nemam sve sto mi je potrebno...?
Ako ne znate u cemu je problem, ajd bar napisite tih nekoliko linija za terminal (ne znam koje su, a da opet ne srljam po guglu i gubim vreme) pa cu na svezu intalaciju na drugoj particiji da instaliram php, apache, mysql ili lamp sta god da predlazete... nemam pojma sta vise da pokusavam.


Roberte, izvini sto mozda odstupam od teme, slobodno prebaci gde mislis da treba. Postavio bih je ja negde ali nemam pojma jel problem do neke klase kod zenda ili mozda zend studio.. ili (sto je lako verovatno) ja zapetljam negde... samo gde i kako kada sam gotov primer skinuo i probao.
btw skinuo sam i netbeans (znam da program nije od kljucnog znacaja, ali ja u ZS jednostavno ne znam kako da ga nateram da radi phpunit) pa ako ti je blize baci link gde ima objasnjeno netbeans i phpunit sa zendom.. pa cu nastaviti da pokusavam.

Aha, izvini, nisam pažljivo pročitao i onda nisam shvatio da tebi trebaju samo parametri iz url-a.


Metod getParams() bi treba da hvata i ?foo=bar, a ako hoćeš da dohvataš samo $_GET, onda pre poziva getParams() metoda uradi setParamSources(array(_GET).

btw Jako je ružno da URL bude u toj formi, odnosno da se vidi naziv parametra. Ako znaš da koliko parametara očekuješ za neki url koji kreiraš, napravi novu rutu koja će da ti mapira taj url. Npr. da umesto ovog: /news/year/2010/month/01/day/24/id/22
imaš ovo: /news/2010/01/24/22


Ako će ti to biti od pomoći (mada čisto sumnjam), mogu na brzinu da ti opišem šta sam ja radio da bih osposobio PHPUnit kod mene u okviru Windows/XAMPP okruženja. Windows verzija XAMPP-a, nakon intalacije PHPUnit-a preko pear-a, pored toga što PHPUnit biblioteku smešta u folder xampp/php/PEAR, u folder xampp/php dodaje bat fajl sa nazivom phpunit. To je ta komanda koju ti pokušavaš da pozoveš iz terminala na Linux-u, a koja se na isti način poziva iz Command prompt-a na Windows-u. E sad, kad hoću da pišem unit testove za neki projekat koji se nalazi u okviru xampp/htdocs, ja u tests folder tog projekta (obično tako imenujem taj folder sa testovima) kopiram xampp/php/phpunit.bat. Taj fajl u sebi ima apsolutnu putanju do xampp\php\php.exe, upisanu u promenljivu sa imenom PHPBIN, tako da možeš da ga izvršavaš sa bilo kog mesta.

E sad, ono što je možda za tebe bitno, vidim da si spomenuo /usr/bin/env, a pandam tome u Windows-u su one Environment Variables putanje. To napominjem zato što je još jedan od načina za omogućavanje phpunit, a svih sličnih komandi, npr. pear, itd. upravo dodavanjem putanje do php foldera na te Environment putanje. Pretpostavljam da bi nešto slično trebao da uradiš i kod tebe na Linux-u.

Nikola hvala puno. Sry sto kasno odgovaram, nisam stigao ranije. Stiglo je i ovo na red, uspeo sam nekako... instalirao sam lamp umesto zend servera i kao sto Robert rece... istalirao phpunit i radi. :S Nemam pojma.. Uglavnom, nema veze sa zf, a ja opet idem u off kao da je ovo jedina tema na kojoj smem da pisem. Sry. :(

EDIT: Hm... zanimljivo. Imam form (na zalost malo veci) koji sam sad prelistao nakoliko puta i uzduz i popreko jer dobijem error (samo error) kada odem na stranicu na kojoj se isti pojavljuje. Pre toga sam eliminisao sve ostalo jedno po jedno. Na kraju mi zapadne za oko putanja do temp foldera gde privremeno smesta okaceni fajl... i prodje mi kroz glavu da sam radio restore jednog backup-a i da sam ja vlasnik foldera. I tacno to je bilo sporno. Taj folder nije bio u vlasnistvu www-data i isti nema dozvolu za upis.
To bih verovatno odma pomislio da nije uspeo submit, ali pri ucitavanju stranice sa formularom... hmm

Na neki nacin za sve je kriv error controller koji nesto odbija saradnju (ako uopste prikazuje ovakvu gresku). Da nije problem sto su dva modula? Ovaj backup je malo star i ne mogu da se setim sta sam tacno i kako podesavao i kako treba, ali eror kontroler mi radi normalno u jednoj drugoj aplikaciji koja ima samo jedan modul..

Sta vi mislite? Treba li nesto da se navede u ini kao za module i slicno..?

_{[Ovu poruku je menjao strutter.poison dana 19.09.2010. u 05:34 GMT+1]}

Nisam siguran da sam baš najbolje razumeo ovo tvoje pitanje... Za error controller ne treba ništa specijalno da podešavaš u slučaju da je njegov naziv ErrorController i da u okviru njega imaš tu akciju koja se zove errorAction.

Evo pokušaću da ti opišem kako ide taj postupak dispatch-ovanja zahteva na ErrorController u slučaju nekog izuzetka... Naravno, "magija" se odvija u dispatch() metodu Front kontrolera, koji taj proces dispatch-ovanja wrap-uje u jedan try/catch blok. U slučaju bilo kakvog izuzetka, i u slučaju da nisi podesio da Front controller nastavlja da ih baca ($_throwExceptions flag), isti će biti dodat na exceptions stack response objekta. Front controller pre dispatch-ovanja registruje Zend_Controller_Plugin_ErrorHandler, i upravo taj plugin je odgovoran za pozivanje tvog Error kontrolera. On koristi routeShutdown i postDispatch kuke, kako bi proverio da li postoji neki izuzetak (da li response objekat ima neki izuzetak), i u slučaju da postoji, zahtev forward-uje na error controller, pritom prosleđujući "error_handler" parametar koji sadrži informacije o grešci. Podrazumevane vrednosti odredišta na koji će zahtev biti forward-ovan su: modul - default, kontroler - error, akcija - error. Zato sam ti i rekao da tu nema ništa posebno da se podešava, ako si na taj način imenovao tvoj Error kontroler i ako se on nalazi u okviru default modula.

Jeste, u svakom modulu postoji po jedan gde i ostali kontroleri. Izgleda da za nesto radi a za nesto napise samo application error. Nije mi jasno zasto? Jel za ocekivati da nekada prijavi samo application error bez bilo kakvog podatak jos? Recimo za ono iznad sto sam napisao za nedostatak dozvola nad folderom u koji treba da se smesti upload-ovani fajl?
Mislim, ako je to ok.. da ne gubim vreme sad nego kada budem dokon prelistam to sto si opisao.

A šta će ti u svakom modulu po jedan ErrorController? Ok, ti možeš sa nekim svojim plugin-om da u zavisnosti od zahteva podesiš $_errorModule Zend_Controller_Plugin_ErrorHandler-a, kako bi dinamički menjao te tvoje ErrorController-e u zavisnosti od modula, ali ja mislim da je nekako logičnije da imaš samo jedan ErrorController, koji će biti zadužen za ispis grešaka.


ErrorController je zadužen samo za izuzetke, a ne i za npr. fatal error-e i slično. To što kažeš da ti napiše samo "Application error" je zbog toga što si ti svoj ErrorController kreirao na način da view-u prosleđuje taj string u slučaju određenog tipa greške. Kažem, u tom parametru koji će biti set-ovan od strane Zend_Controller_Plugin_ErrorHandler-a će biti i Exception objekat, a iz njega možeš da izvučeš dosta korisnih informacija o izuzetku koji se desio, npr. getTraceAsString, tako da je na tebi da odlučiš šta ćeš da ispišeš od tog brda podataka koje dobijaš.

Pojma nemam zasto je u svakom modulu po jedan. Verovatno sam kopirao ceo modul da ne pravim svaki folder posebno. Sescu za koji dan i prouciti malo.

Dva pitanja, ako moze. :)

U lucene indeksu je sacuvan id, ime i opis iz baze. Da li moze da se uradi brisanje prema id?
Pretraga se vrsi prema imenu i opisu. Ime i id su sacuvani, a opis samo indeksiran. Mogu da pretrazujem po imenu pa da poredi da li id od tog dokumentu iz indexa odgovara onom iz baze. Ako odgovara onda brisem. Moze li jednostavnije ili se ovo stvarno mora ovako raditi?

Moze li nekako da se izvede za rutu /:foo/:bar, ako foo sadrzi html bude tretiran kao bar, tj. da se koristi druga ruta /:bar?
site.com/fooParam/barParam.html == site.com/barParam.html

Za prvo pitanje stvarno ne mogu ništa da ti kažem, jer nikad nisam koristio Lucene.

Što se drugog pitanja tiče, naravno da je tako nešto moguće, ali to je, koliko ja znam, izvodljivo jedino uz pomoć Regex rute, npr.:

To bi bio primer definicije takve rute u okviru ini fajla, a posle naravno bi u bootstrap-u morao da dodaš ovu konfiguraciju ruteru:

Naravno, ovakvu definiciju možeš da dodaš i direktno u tvoj app config, pri čemu bi samo ispred svake stavke dodao resources.router, kako bi naglasio da inicijalizuješ Router app resurs. Ja nekako više volim da rute držim u odvojenom config fajlu.

Primetićeš da u tom prvom subpattern-u "prolazi" i znak "/", a to je upravo iz razloga što je zahtev te tvoje rute takav da je prvi deo opcion, pa nikako ne smeš kosu crtu (url separator) da imaš između ta dva parametra foo i bar, već će parametar foo, ako ga ima, pri assemble-ovanju te rute dodavati kosu crtu na kraj njegove vrednosti. To znači da ćeš pri dohvatanju vrednosti tih parametara, u okviru foo-a imati i tu dodatnu kosu crtu na kraju, a ako ti to smeta, onda istu tu rutu možeš da definišeš i ovako:

Nadam se da ti sintaksa regularnih izraza nije strana, pa ti je verovatno jasno zašto sam stavio ?: na početku tog prvog segmenta kojeg sam označio kao opcionog. U slučaju takve rute, reverse ruta (ona koja se koristi za assemble-ovanje) bi trebala da izgleda ovako: routes.foobar.reverse = %s/%s.

btw Sve ovo pišem iz glave, tako da mi se možda potkrala neka sintaksna/logička greška.

Zaboravi na ovu rečenicu. U slučaju takve reverse rute, nikad ne bi mogao da dobiješ url tipa site.com/barParam.html, već ovako nešto site.com//barParam.html, zbog te kose crte. Za ovaj drugi način koji sam predložio, morao bi ručno da dodaješ url separator (kosu crtu) na taj foo parametar (u slučaju da ga koristiš), pri generisanju url-a bilo view ili action Url helper-om.

Ok, kapiram. Mislim da cu se snaci.
Samo ovo treba da prepakujem u bootstrap jer sam tamo poceo da pisem rute.

Hvala. ;)

Evo mene opet. :)
Stigoh do kesiranja konacno.. veoma mocno. Sa nekih 150 sam smanjio na 80-100ms kesirajuci neke expensive queries i obradu nekih podataka. To je sve super, ali nikako da ga nateram da u kontroleru uz pomoc helpera kesira celu stranu. Procitao sam u manuel-u sve vezano za Zend_Cache, guglao prilicno i nadjoh ovaj tekst - jedan od konkretnijih: http://www.brandonsavage.net/c...fficiency-with-zend-framework/ .
Medjutim, kreira mi prazan fajl. Jendom sam izostavio zarez i prijavio je gresku - cudno, to sam nasao u cache fajlu, ali kad je sve ok prazan je.

Ini:

Index kontroler - init() :

.htaccess


Vidim da nisam jedini koji ima ovaj problem i svuda kao resenje navode da se iskljuci output buffering. Ali od pocetka u .ini fajlu stoji ta linija.. Zaglavio sam, moze pomoc? Sta moze da bude problem?

Zna li neko kako najjednostavnije da promenim putanju do view fajlova ali negde u bootstrapu ili preko plugin-a (pa da ga reg. u bootrstrapu) ? Iz kontrolera nije opcija (to sam uspeo) jer ih ima puno, lakse je i prakticnije to uraditi na jednom mestu.

Hteo bih da imam ovako nesto:


Dakle da se isti helperi koriste i za jedan i za drugi template, samo da se folder sa .pthml menja.

Probao sam neke varijante sa setScriptPath() u bootstrap-u, ali izgleda da ja to ne radim kako valja... ili to menja putanju do view foldera a samim tim iste helpere moram imati na dva mesta ili i za njih posebno podesavati path... sto mi izgleda kao nepotrebno komplikovanje. Moglo bi mozda jednostavnije kao za layout path, kako ste predlozili u nekim od ranijih postova?

Pozzz

Nisi napomenuo da li bootstrap-uješ View app resurs, ali pošto je to verovatno slučaj, onda će ViewRenderer biti dodat na stack action helper-a, što znači da je on taj koji je odgovoran za render-ovanje view script-ova. E sad, ako sam dobro razumeo, ti treba da dodaš putanju do nekih view script-ova kako bi mogao da ih koristiš, a ne da je promeniš. To znači da bi trebao da dodaš vrednost na stek putanja u oviru samog View objekta, kojeg ViewRenderer ima kao javnog člana. Tako da, rešenje bi bilo da dodaš neki custom metod u Bootstrap klasu koji će da radi sledeće:

E sad ja ne znam da li je to ono što tebi odgovara, jer tako će i pre samog dispatch procesa, view već biti napunjen sa tom dodatnom putanjom. Odakle uopšte potreba za takvom strukturom direktorijuma, scripts1, scripts2, itd.?

Pa script1 predstavlja jedan template (temu) a script2 drugu. Tako sam zamislio, da na jendom mestu u zavisnosti od toga sta je korisnik izabrao promenim (ne da dodam nego bas promenim) folder gde ce biti trazeni .phtml fajlovi. Helperi se traze i dalje na istom mestu. Tu negde bih ukljucio i layout isto kao i ove .phtml iz scripts, samo nisam hteo komplikovati jer to znam kako da izvedem.
Jos jedan razlog je sto bi mogla postojati potreba za ispisom veceg teksta na razlicitim jezicima sto u ovakvom slucaju kakav je predvidjam nije prikladno za zendovo resenje sa prevodjenjem. Ovo nije primarni razlog jer su male sanse da se desi, ali ipak postoje. Zapravo, sve je ovo probanje i predvidjanje svega i svacega kako bi se bolje upoznao frejmvork. :) Ali potreba za templajtima je realna.

Uglavnom, probao sam sa view rendererom ali sa setScriptPath i kada posle u kontroleru uradim getScriptPath dobijem onaj standardni i renderuje se .phtml iz onog pocetnog scripts foldera. Znaci nisam uspeo da promenim path.

Kontas sta hocu? Dva ili vise templajt foldera koji ce deliti isti helper folder. Ali da to podesim tamo gde sam podesio i layout jer od istih faktora zavisi koji ce path biti (sta je korisnik izabrao i koji je modul u tom zahtevu).

Aha, a pa što teme držiš u scripts folderima? Za to se obično koristi app/layouts folder. I u njemu onda ide neka ovakva struktura: app/layouts/tema1, app/layouts/tema2, itd., a svaka od tih tema ima onaj layout.phtml, ili neki custom naziv tog glavnog skripta, u zavisnoti od načina na koji si implementirao Zend_Layout komponentu.


Pojasni malo to "šta je korisnik izabrao"... "Izabrao" u smislu podesio, pa je to podešavanje sačuvano npr. u bazi, ili "izabrao" u smislu odlaska na neku stranicu, odnosno na neki modul/kontroler/akciju?

Ako je u pitanju ovo prvo, onda to možeš da završiš nekim custom metodom u bootstrap-u:

A ako temu ipak treba da menjaš u odnosu na trenutni zahtev, na primer u odnosu na trenutni modul, onda je u te svrhe najbolje napraviti controller plugin.



Ovaj deo ne kapiram... Šta je za tebe "templejt folder"? Možda grešim, ali čini mi se da loše povezuješ neke stvari. Tema, odnosno, layout, pa ni view script-ovi, nemaju nikakve veze sa view helper-ima, u smislu tog nekog "deljenja" koje ti spominješ. Ti sve svoje view helper-e možeš da smestiš na neko totalno drugo mesto, npr. u library folder, al' onda je samo bitno da view-u saopštiš tu putanju na kojoj će on da ih traži.

Pozdrav narode. Imam problem pa ako je neko voljan za pomoc
Naime, imam dva projekta koja razvijam. I u jednom i u drugom koristim Zend_Acl za kontrolu pristupa, tj. imam u folderu library/CSM fajl Acl.php koji u sebi ima sledece:






u application.ini mi je podeseno:
resources.frontController.plugins.acl = "CMS_Controller_Plugin_Acl"


Ono sto je problem jeste da kad se ulogujem na jednu aplikaciju preslikava se na drugu(koristi iste korisnike). Tabele u kojima se cuvaju korisnici se nalaze u razlicitim bazama

Probao sam svasta, ali ne ide

Promena layout-a nije problem, to je vec objasnjeno na ovoj temi. (mislim da si bas ti objasnio)
Ali, .phtml fajlovi iz view/scripts generisu dobar deo html koda koji se mora promeniti kada se promeni tema. U dosta situacija to sto akcija generise nije poznato layout-u tako da mora u view/scripts.
Po meni deljenje tog V iz MVC na layout i view/scripts na ovakav nacin nije dobro zato sto ogranicava kasniju promenu tema i moze potpuno da onemoguci da budu aktivne dve skroz razlicite teme i da kroisnik uradi switch sa jedne na drugu sa dva-tri klika.
Da se ja pitam uradio bih ovako:


Samo helperi ostaju zajednicki za sve teme, dok se layout menja zajendo sa promenom view path-a.
Mislio sam da se promenom view path-a menja i path za helpere jer se sa setBasePath upravo to dobija. Dok setScriptPath i addScriptPath menjaju samo script path. Zato sam istakao odvajanje helpera, mada oni uopste nisu bitni u ovoj prici i nemaju veze sa scripts i layout kao sto kazes.
Nego lepo sto si pomenuo to da se mogu staviti na neko totalno drugo mesto npr. u library. :) E, daj da vidimo kako se to moze izvesti za view/scripts.

Procitao sam ovu diskusiju: http://www.mail-archive.com/[email protected]/msg11411.html Prepricacu ti ukratko da nemoras da citas.
Lik pokusava isto sto i ja. Setuje path za scripts ali se .phtml trazi u onom defalut folderu. Cuveni Matthew Weier O'Phinney tvrdi da se prilikom addScriptPath poslednji dodat prvi proverava. Medjutim prvi je uvek onaj default i redosled o kom on govori vazi za drugi, treci itd. U nizu sa key 0 ostaje view/scripts. Lik sa kojim je Metthew diskutovao je na kraju zapakovao aplikaciju kako bi se ovaj uverio. Medjutim vise nisu pisali... E da, kaze da kada obise ili promeni ime od view foldera bude renderovan odgovarajuci .phtml iz onog drugog. Ali ni to kod mene nece.. sto nije neki problem jer mi brisanje svakako nije opcija vec normalna promena path-a tako da on bude prvi ili jedini koji se proverava.
To je bilo za zf 1.5 ali isti problem sam i ja uocio malo pre.
Verujem da ima neko drugo resenje, ali cova iz zenda to nije objasnio..

Idem da izguglam jos neko resenje i da probam. Garant je nesto banalno kao sto obicno biva.. :) Ako stignes i ako znas, bilo bi super da mi ustedis malo vremena. :)



_{[Ovu poruku je menjao strutter.poison dana 23.11.2010. u 01:34 GMT+1]}

Evo u cemu je caka.
Poslednji dodat se prvi proverava. Cika Metju je upravu. Samo sto se nakon sto ja dodam u bootstrap-u dodaje ponovo. logicno... :) cim je nesto drugo na mestu 0. I onda se gubi smisao podesavanja u bootstrapu.
Koristeci debug_backtrace() sam uhvatio ko mi se mesa u posao. Zend_Controller_Action_Helper_ViewRenderer. Posto tu stoji provera da li je vec setovan taj path koji pokusava da setuje pa ako nije setuje ga, samo sam u bootstrap-u dodao taj standardni path prvi a drugi ovaj moj. Tako nije bilo novog setovanja i koristen je moj path. :)
Verovatno ovo moze elegantnije, ali mrzi me sad da se cimam. Dosta je.. drugi put.
Dakle u bootstrap-u:


Aaaa, odlepicu! Za par minuta sam resio problem prateci kroz source obradu zahteva, dok sam na guglu izvisio.. pa sigurno sat-dva ukupno, svasta pokusavajuci. A nekada listam source i nikako da pohvatam sta je sta, pa na kraju nadjem resenje na guglu za pola minuta. Deam! Kako nikad da potrefim iz prvog puta gde je lakse. :(

Ok, najbitnije je da si sad rešio taj problem... :) A i kao što sam napomenuo u pretposlednjem post-u, taj Zend_Controller_Action_Helper_ViewRenderer postaje "glavna faca" što se tiče View-a, nakon što ga dodaš na stek action helper-a. Za sve što je vezano za view se obraćaš njemu, direktno ili indirektno, jer on tu instancu Zend_View objekta koju si mu dodelio, posle u init() hook-u set-uje i trenutnom Action kontroleru, pa je to onda isti onaj objekat kome pristupaš npr. u akciji nekog kontrolera, kad dodaješ neke promenljive view-u ($this->view->foo = 'bar').

_{[Ovu poruku je menjao Nikola Poša dana 23.11.2010. u 12:44 GMT+1]}

Potrebno mi je da odradim chat na sajtu i to ne nista komplikovano(ne treba chat sobe i sl). Ono kako sam ja planirao jeste mysql u pozadini sa tabelom koja ce imati dve kolone za korisnike, jednu za poruku i jednu za vreme poruke. E ono sto me muci jeste sto sam planirao da se stranica, tj. deo radi refresh na svakih nekoliko sekundi. Jel idem u dobrom pravcu i jel ima neko neko usmerenje kako je radio ovo u Zend-u?

Ima li neko da je uspjesno instalirao Zend na Win7 i Xampp-u?

I jos jedno pitanje. Da li neko zna kolike su sanse da se na shared hostingu dobije virtual host (koji je, kako sam ja shvatio,
potreban da se Zend koristi za live sajt)?

Zend kao Zend Studio, Zend Framework, Zend Optimizer...?

Pogresno si razumeo to za virtual hostove. Uglavnom tokom razvoja aplikacija se nova aplikacija pravi pod virtual hostom, tipa: http://projekat.localhost/ cisto da bi migracija na http://projekat.com/ bila sto laksa. Jedino sto je pozeljno za ZF based aplikacije jeste da imas pristup jedan nivo iznad public_html foldera (sto je dosta cest slucaj u poslednje vreme, kako sam ja primetio).

Mislim na instalaciju Zend Framework-a na Win7 i Xampp-u

Sto se tice mana ZF-a, citao sam jedan clanak gdje se spominje kao mana to da se na shared hostingu mora imati mogucnost kreiranja Virtual Host-a

http://net.tutsplus.com/tutorials/php/10-compelling-reasons-to-use-zend-framework/
(search: ADDENDUM pa ce te odvesti na listu nedostataka)

Mozda ce opet ispasti da ne razumijem dobro ali... Nadam se da je tako kako ti kazes.
Sto se tice pristupa nivoima iznad /public_html, imam reseller paket jedne domace (bosanske)
firme i imam pristup tom nivou (znaci li to da cu moci bez asistencije njihove podrske napraviti
da mi Zend aplikacija radi kako treba na serveru?)

Ha! Ti razumes dobro, ali oni ne razumeju dobro :D taj deo su omasili (citao sam clanak ranije, ali na ovo nisam obratio paznju).

Sto se tice hostinga, potrebno je da imas mod_rewrite, da imas pristup 1 level iznad public_html-a (ili www, ili public, ili vec kako su nazvali web root) i otprilike to je to.

ZF nema sta da se instalira. Kopiras fileove iz fw-a negde u putanju (note: negde. Ti odlucujes gde ce biti zf fileovi smesteni), namestis .htaccess i otprilike to je to. Ti ionako razvijas kod sebe u lokalu, posle samo frljnes na server, promenis pristupne podatke za bazu i to je to :) meni se na kraju posao prebacivanja na live server svodi na upravo to. Bilo da idem na svoj VPS, bilo na klijentov shared hosting.

U redu, hvala na odgovoru, laknulo mi je

Krenuo sam prije nekih 2 sata s instalacijom ZF-a. Naravno, imam odredjenih problema

Dakle, radi se o:

Win7
Xampp
ZF 1.11

Odradio sam (mislim) sve sto se trazilo, ne znam sta mu je vise
da probam navesti sve urađeno:

1. dodao putanju do /library foldera u include_path php.ini-ja
2. kreirao projekt (quickstart) - dobio kreiran istoimeni folder s odgovarajucoj strukturom
3. napravio symlink foldera iz D:\WebDev\ZendProjects\library\Zend ka D:\WebDev\ZendProjects\quickstart\library
4. boostrap ostavio onakvim kakav jeste, kako i sam autor quickstart tutoriala kaze


5. application.ini je ovakav:


6. kreirao virtual host u Xampp-u
U httpd.conf sam nasao uncommented liniju "include vhosts.conf bla-bla" tako da podesavanja vuce iz tog vhost fajla, gdje sam unio:


7. dodao 127.0.0.1 quickstart.local u host file


Ne znam vise sta hoce od mene. Ne dobijam nista kada kucam http://quickstart.local/ - samo error:

Object not found!
The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again.

kod wamp-a se podesava tako sto na apachu dodas alias (npr.: projekat), dodas putanju ka njemu(npr.: c:/Program Files/wamp/www/ime projekta/public/ ) i onda kada kucas http://localhost/projekat/ to radi

ovde ti je jos bitno da kod apacha (apache modules) ukljucis rewrite_module opciju

Ma veliku sam glupost napravio pri pravljenju virtual hosta

Posto je u tutorialu stajalo /path/to/quickstart/public, ja sam pri unosu stavio i u putanju do document root-a ovo "quickstart", bas onako kako je u lokalnom folderu gdje drzim fajlove projekta.
Zapravo mi to ne treba, vec samo ide C:/xampp/htdocs/public

Cim sam to ispravio sve je proradilo kako treba.

A tek sada mi predstoji znojenje sa bootstrap-om (kako mi samo ovo opako i zloslutno zvuci)
U CodeIgniter-u toga nema, tako da mi je to sasvim novo.

Ali postam opet cim negdje zapnem a ne uspijem se iscupati sam

Šta vam govori ova gomila grešaka?



Mislim da je problem sam Xampp jer on ima "C:\xampp\php\pear\Zend" koji sadrzi te Bootstrap i BootstrapAbstract fajlove.
Ja u root-u svog projekta (virtual hosta) koji je "quickstart.local" imam kopiran library direktorijum iz Zend instalacije (tako sam negdje procitao da mora biti).
Sada ocigledno dolazi do kolizije ovih bootstrap fajlova, tj. ne ucitava/ne koristi se onaj pravi (IMHO).

Po svoj prilici Xampp nije najsretnije rjesenje za instalaciju Zend-a, a zend studio mi se ne koristi jer ne mogu uporedo furati i Xampp. S druge strane, za manje projekte ne planiram
koristiti Zend pa ce mi Xampp nedostajati.

AKo ima neko nesto na umu - neka slobodno kaze.

Hajde da i ja napisem nesto iako i sam trazim pomoc od ljudi ovde i nisam jos uvek doveo znanje zf-a na nivo koji mi odgovara. Ali ovo je ipak pocetak (vecinom teorija), to bih trebao znati :)

Prvo sto zapazam jeste da treba da razgranicis zavisnost zend-a (kao frejmvorka) od stvari koje pominjes. Zamisli da si sam napisao framework. Sve se svodi na .php a za to moras imati instaliran php jel tako? Apache ako hoces da ti se vrti aplikacija u browseru inace ako nekada radi posao (testiranje i sl.) dovoljan je terminal.
Znaci u celoj prici su bitni apache server (virtual host, pristup iz browsera - grubo receno) i php da se izvse .php fajlovi (*sql kada se javi potreba za bazom). Da li je to xampp, lamp, wamp, zend server ili peske kompajlirani apache i php nema velike veze sve dok rade kako su njihovi tvorci zamislili. ZF je biblioteka klasa koje ti olaksavaju (veoma, veoma mnogo) da napises aplikaciju. U sustini zf je mnogo, mnogo vise nego sto se u jednoj recenici moze napisati, ali to se odnosi na funckionalnost a ne na zahtevnost.

Include path su putanje gde ce da trazi fajlove. Nema potrebe da menjas php.ini. Imas u public folderu index.php i tamo zadas include path kako tebi odgovara. Bez putanja koje su ti sumnjive. Na taj index.php ce svi zahtevi biti preusmerani a za to je potreban .htaccess fajl (u istom folderu) koji ce web serveru reci sta i gde da upucuje. Da bi to radilo mora biti ukljucen mod rewrite.

Ako dobijes sadrzaj fajla ....view/scripts/index/index.phtml kada u browseru ukucas ime kojim si nazvao vhost (buduci da je to ime homepage tvog sajta jel) sve ostale nevolje koje budes imao su posledica pogresno napisanog koda. Ne od zf-a nego ono sto ti pises. Mozda bude neki problem ako ti fali neka bibilioteka za php i tako nesto.. ali to ces znati i to je druga prica.

Resenje tih problema je da poznajes php naravno, i da citas zf manual. Ja sam takodje muke mucio dok nisam seo par dana i prcitao sve sto se odnosilo na delove frejmvorka koji sam koristio. I sada ima zavrzlama jer je zf vrlo kompleksan, ali vecinom ih lakse resavam nego ranije.

Sto se tice poslednjeg posta. Mislim da si hteo pozvati view tamo gde ga nema. Zapravo bootstrap-ovati ga, a cini mi se da sam ja prvo to uradio za layout pa onda view kada je islo iz bootrstrapa. Iz plugina je drugacije imas na predhodnoj strani. Takdoje izgleda da fajlove framework-a vuce iz tog xampp\php\PEAR\Zend foldera. Ako nisi tamo stavio zf navedi u index.php set_include_path() putanju foldera koji zelis da koristis. Mada ako su iste verzije zf-a isto ti dodje.
Imas u ranijim postovima (2-3 strane nazad) kako da na samom pocetku udesis neke stvari vezane za view. Mozes u bootstrap-u, preko plugina.. Obavezno procitaj i ostalo sto ti nije sad glavno i probaj da slazes kockice polako. Ali glavni vodic treba da bude manual.



Ako mozda postoji jos neki razlog za menjanje xampp-a moja topla preporuka je da predjes na linux. :D Znam kako to cudno zvuci, predloziti promenu OS-a u ovakvom kontekstu, ali ja sam puno srecniji od kada koristim Ubuntu (lol zvucim kao na onim reklamama jel da?). Ozbiljno, sve je na dohvat ruke, sve je logicno, kroz jednu liniju u terminalu reseno. Server, koji ce terati tvoje aplikaciju, skoro sigurno koristi linux. Jasno je da su unix - unix like, apache, mysql, php ista "ekipa".
Ovo, pak, ne mora nista da znaci. Napisao sam vec na pocetku da ti treba bilo sta sto moze da izvrsi .php ekstenziju i to je u sustini dovoljno.
Ali ipak evo jedan mali demo kako se resava problem pripreme kompa za rad u php-u (zf-u).



Kreiras virual host fajl (a2ensite *), strukturu foldera, fajlove (mnogo lako sa zend tool - iz terminala kao i ovo iznad), zatim a2enmod rewrite i nista ti vise nije potrebno. Stvarno uzivancija.. Jos dodamo eclipse ili netbeans ili nesto slicno tome... ma savrseno. I posteno na kraju. Malo je ljudi kod nas koji uredno placaju software, da se ne lazemo. Ovamo je opensource ideologija i skoro sve mozes besplatno koristiti.

Javicu se kada stignem (nadam se vec u toku tada) i okaciti pocetak jedne proste aplikacije, da mozes videti strukturu, gde se ono osnovno podesava i kako. Mada to velikim delom vec postoji na ovoj temi, ali mislim da nije lose sumirati radi kasnije jednostavnosti pristupa informacijama. [mozda je bolje da to Nikola, Robert ili neko drugi ko je obogatio ovu temu jer ipak su oni maheri za zf..]

<sub>[Ovu poruku je menjao strutter.poison dana 03.12.2010. u 09:45 GMT+1]

[Ovu poruku je menjao strutter.poison dana 03.12.2010. u 09:46 GMT+1]</sub>

U svakom slucaju, hvala na detaljnom odgovoru i savjetima.

Ipak, nasao sam na jednom poljskom forumu rjesenje. U application.ini je trebalo dodati ove 2 linije:



Dakle ovaj resource kojim se odredjuje basePath je kocio cijelu stvar.
bez druge linije (encoding) isto radi ali tamo stoji da se i ona ubaci (to je valjda nacin da se podesi
enkodiranje layout-a)

Cudan je ovaj Zend, sve se radi na neki specifican nacin. A najgore u svemu je sto rjesenja ne mozes
sam naci ako nisi iole napredniji ZF-ovac.

Slazem se s autorom gornjeg posta da treba citati, citati i lagano slagati kockice. S vremenom ce stvari
postajati samo lakse, nikako slozenije. A mogucnosti koje Zend pruza je ono sto me tjera da se i dalje bakcem
s njim, iako na momente zalim sto sam digao ruke od CodeIgniter-a ili sto se nisam odlucio za Symfony, npr.

U .ini je neophodno samo neke osnovne stvari podesiti. Sve ostalo moze
iz bootstrap-a ili preko plugin-a koji se registruje u bootstrap-u, a
deo toga moze naravno i u .ini kao sto si ti upravo uradio.
Dakle to sa .ini je jedno resenje problema, drugo ti je bilo, mislim, i
blize nego pomenuti poljski forum :D - na dve strane od ove. ;)
Nije to neki bas specifican nacin. Zend radi na potpuno OOP nacin, koji
ja nisam bas dobro poznavao kad sam se prvi put sreo za zf-om. Tako da,
iz iskustva, ovo moze da predstavlja problem. Naravno imao i nesto svoje
specificno, ali nije strasno kada se razume pogotovo sto je skroz u
skladu sa OOP-om.
Nesto zanimljivo za zend sto sam procitao ovde (mislim da je Nikola
napisao) a iskusio sam nekoliko puta: "zf ima jednostavna resenja za
kompleksne probleme i kompleksna resenja za jednostavne probleme".
Ali lako taj jednostavan problem moze da postane kompleksan u zavisnosti
od faktora i malo drugacije situacije a da u sustini i daje ima istu srz
problematike i onda bas dobro dodje to kompleksno resenje. ;)
Relativiter razbija i lako se da prosiriti samo kad se tako gleda.. cika
Ajnstajn nije bio samo mali cudni sedi coveculjak. :) Al da ne
filozofiram, dosta je. ;)
Pozz
--
Growing old is mandatory; growing up is optional.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Ne znam odakle nekom ideja za takav savet, al' ajde... Base path će biti set-ovan bilo od strane samog action kontrolera, ili od strane ViewRenderer action helper-a, za slučaj da se odlučiš da koristiš benefite tog helper-a. Encoding je po default-u podešen na UTF-8 (pogledaj vrednost $_encoding člana Zend_View_Abstract klase), tako da je i ta druga linija sasvim suvišna.

Inače, taj view resurs, pa i bilo koji drugi kojeg inicijalizuješ u konfiguracionom fajlu je u stvari klasa koja implementira Zend_Application_Resource_Resource interfejs. Zend Framework dolazi sa nekoliko app resursa koji olakšavaju postupak inicijalizovanja određenih komponenti, i svi oni se nalaze u folderu Zend/Application/Resource. Jedan od njih je i taj View resurs, kojeg si ti pokušao da inicijalizuješ (baci pogled na kôd njegove klase - Zend_Application_Resource_View). Taj resurs, pored toga što kreira instancu Zend_View objekta, kojem pritom prosleđuje opcije koje želiš da set-uješ, tu istu instancu set-uje i ViewRenderer action helper-u, koji potom biva dodat na stek action helper-a. Korišćenje tog helper-a je veoma preporučljivo, jer te lišava npr. ručnog render-ovanja view script-ova na kraju svake akcije nekog kontrolera.

Ja taj View resurs inicijalizujem upravo iz razloga da ne bih morao sam da uključujem ViewRenderer action helper u igru, i to na način što obično podesim doctype:

Pratim jedan tutorial vezano za integraciju Zenda sa Doctrine-om i sada sam naisao da dio gdje treba kreirati skriptu za Doctrine CLI (Command Line Interface), kako bih mogao generisati modele pomocu YAML fajlova.

Rekao bih da je primjer skripte napisan za UNIX sistem jer ima linija:

chmod +x doctrine-cli

E sada, posto sam ja na windows platformi, kako da napravim odgovarajucu skriptu koja ce mi omoguciti koristenje doctrine-cli skripte.. Navedeni tutorial kaze da se skripta (nakon omogucavanja izvrsenja iste) ovako izvrsi:



Buduci da sam u pocetku mislio da je to to, pokusavao sam na taj nacin, istim tim kodom izvrsiti skriptu. Medjutim, izbaci mi ono standardno: " '.' is not recognized as a ... command, bath file, bla-bla"
Kasnije sam skontao da meni treba nesto za windows. U redu, napravio sam ja rucno tabelu i polja u bazi ali ne vrijedi jer mi nije generisan model koji mi treba za dovrsavanje tutoriala a naravno i kasnije
mi treba ta CLI funkcionalnost.

Evo sadrzaja "doctrine-cli" skripte:



Sta predlazete?

Pa valjda ti je jasno da iz Command Prompt-a, tj na Windows-u, tu komandu: $ ./scripts/doctrine-cli generate-models-yaml ne možeš da koristiš na isti način kao i na Linux-u. Zato ti i izbacuje tu grešku vezanu za tačku, jer Windows nema pojma šta ona predstavlja. Na Linux-u, ona se odnosi na trenutni radni direktorijum (valjda ). Tako da, na Windows-u, taj tvoj skript bi trebao da izvršavaš ovako nekako: php putanja/do/doctrine-cli.php ovde-idu-neki-parametri.

Nikola, probao sam svasta ali na Windows-u to nikako ne mogu.

Kako god, napravio sam rucno te modele koji su trebali biti generisani putem CLI-ja, međutim ispada da mi Zend ne radi autoload Doctrine modela.

Ima li neko od vas iskustva s kombinovanjem Zenda i Doctrine-a? Ako DA, kako je rijesio to pitanje?


Napomena: Zasto sumnjam u NEloadanje modela? Imam gresku (a taj model/klasa se nalazi u odgovarajucemo folderu):

Ja lično nikad nisam pokušavao da integrišem Doctrine u neki Zend Framework projekat, ali u bookmark-u imam par odličnih tutorijala i saveta na tu temu:
http://www.zendcasts.com/deep-...zend-and-doctrine-1-2/2010/01/
http://weierophinney.net/matth...ities-from-Zend-Framework.html

Taj prvi link je veoma detaljan video tutorijal, a drugi vodi na članak sa bloga kojeg uređuje Matthew Weier O'Phinney, u kome on opisuje jedan od načina za omogućavanje autoloading-a Doctrine modela.

Hvala Nikola, mada sam i sam dosao do tih linkova u prvoj pretrazi na google-u

problem kod mene je sto je u nekim tutorialima doctrine bio stavljen u folder /library, a u nekima u /library/doctrine pa tek onda dodje sama bibiloteka doctrine-a, dakle
/library/doctrine/Doctrine
/library/doctrine/Doctrine.php

Uglavnom, kada sam popravio tu lokaciju (obrisao dodatni nivo) sve je proradilo kako treba, tako da sada imam integrisan Zend i Doctrine i jako mi je drago zbog toga.

Inace, citam da Zend_Db i nije nesto jak sto se tice database layer-a pa sam objerucke prihvatio Doctrine. Dok sam jos bio u CodeIgniter-u, dvoumio sam se cesto i pitao
"Da li meni zaista treba ova gnjavaza s Doctrine-om?"

Sada dileme nema ali opet, vidjecemo kako ce stvari ici dalje

Pa Zend_Db nije ORM, ako si na to mislio. Zend_Db je DAL, baš kao što si i napisao, pa samim tim ne možeš da praviš neku komparaciju između te komponente ZF-a i Doctrine. Možda najbolje što Zend_Db ima u svom arsenalu je implementacija Table Data Gateway pattern-a, u vidu Zend_Db_Table komponente.

Nikola, zasto mi NestedSet (zf) vraca objekat za getTree, fetchAll.. ?
Gresim li negde? Verovatno gresim, samo mi nije jasno gde.. Ajd kad stignes baci
pogled na ovo ispod. Tnx. :)

Skontao sam kako ovo radi. Vidim da ono depth u bazi nije potrebno.. al' dobro,
tad nisam kapirao kako funckionise.
Uglavnom, napisao sam nekoliko metoda za dodavanje, brisanje i preuzimanje cele
navigacije. Testirao i radi... nije bilo tesko a veoma dobro :). Ali kontam,
posto je ona tvoja klasa nekoliko puta veca od ovog sto sam ja napisao verovatno
cu pre ili kasnije videti da nesto fali (za sada je u skladu sa trenutnim
potrebama i to je ok). Zato, jos uvek stoji pitanje, pa.. a mozda i ja u
medjuvremenu ponovo pogledam gde je zapelo, sad imam nesto drugo. Zzzz

Poz ppl imam problem sa zendom i update


pozovem tu funkciju, prosledim $mid parametar..sve ok ALI



odnekud mi ubaci 'ssss' parametar? a ja ne kontam odakle, gde gresim?

Najlakse je da uradis pretragu u fileovima za ta 4 slova s, pa vidi odakle to tamo ;)

pa jesam al nista nema, fora je da mi se to desava kod svakog update-a

Ako misliš na to "ssss", to nije nikakva greška, jer argument u toj formi i treba da bude prosleđen bind_param funkciji, koju utilizira Mysqli db statement.

Čudno, dužina tog stringa koji definiše tip varijabli koje treba bind-ovati (ssss) je 4, a broj parametara za update-ovanje koje prosleđuješ je takođe 4, tako da ne bi trebalo da dođe do te greške koju ti izbacuje...

jel u zendu postoji spisak gradova i regija za zemlje?
Nasao sam spisak zemalja preko clase Zend_Locale

Trebao bi da ponudim regije i gradove iz zemlje koju korisnik odabere

Naravno da ne postoji. To bi bilo suludo da sadrzi.

ovaj zend je fenomen, danas radi sutra ne :S

ja ponovo sa updejtom i sad necu da ga pustim na miru jer je juce radilo kako treba




Prosledi ispravan $bid, znaci to je ok ali mi da error



WTF? kolona "0" nepostoji ? odakle je on izvukao nulu kad niko je ni ne spominje?
Ispade da mi nigde ne radi update funkcija, a radilo je do pre koji dan...
I da znam da mogu izvuci adapter pa da napisem svoj query i tako zaobici sve peripetije, ali hocu da se drzim ZF-ovog pravila...

Lose prosledjujes parametre:



promeni u:

jaooo da , blam :S

e sad se vratio na moj prvi problem sa bind-om :)

Posto vidim da ovde ima dosta ljudi koji drzi ZF u malom prstu da htedoh da priupitam kako je sledece moguce izvesti u Zendu.

Hteo bih da imam jednu akciju koja bi mogla da se poziva iz bilo kog kontrolora ili akcije, a sama akcija nesme biti direktno dostupna putem linka. Ovo je najlakse objasniti ako pretpostavimo da na nekom site-u imamo sidebar ciji se sadrzaj menja u zavisnosti od kontrolera ili akcije koja je pozvana, a izlaz te akcije zavisi od parametra koji je prosledjen. Naprimer negde zelimo da se u sidebar-u ispise prvih 10 naslova, na drugom 5 itd.

Do sada sam uspeo sve da odradim sem da zabranim direktan pristup akciji koja ce se koristiti na vise mesta (index/sidebar). Takodje sam slucajno otkrio da ako pozovem neku akciju za prefiksom [_] , a pri tome postoji akcija bez prefiksa zend mi baca sledeci exception - Zend_View_Exception. No ako pozovem nepostojecu akciju sve radi ok, tj. dobijam 404 gresku koja je ocekivana.





Naravno ovo je uproscen kod. Sidebar bi trebalo da poziva neki model i da vrati rezultat koji bi se iskoristio na vise mesta u aplikaciji!

Imaš potpuno pogrešan pristup... Zašto ta logika oko sidebar-a treba da bude akcija?

Napravi view helper koji će biti zadužen za ispis tog sidebar widget-a, i onda ga u layout-u pozivaj ovako nekako: echo $this->sidebar();. E sad, ako sadržaj koji u njemu treba da se ispisuje zavisi od trenutnog request-a (modul/kontroler/akcija), tim podacima možeš da pristupiš preko Zend_Controller_Front::getInstance()->getRequest()->getParams(), ili pojedinačno: get[Module|Controller|Action]Name(). Pritom, nije preporučljivo da view layer ima dodira sa kontrolerskom logikom, tako da bi bolja varijanta bila da svaki taj kontroler, u odgovarajućoj akciji (ili odma' u init() metodu) prosledi view-u nešto preko čega posle taj view helper može da "shvati" o kom kontroleru/akciji se radi, tako što će da očita vrednost te assign-ovane promenljive preko $this->view. Naravno, to $this->view ćeš imati jedino u slučaju da se taj tvoj helper izvodi iz Zend_View_Helper_Abstract.

Bas zato sam hteo da pitam da li je to best practice. Tek pocinjem da radim u ZF pa mi je bila potrebna smernica. Uradio sam kako si rekao i sve radi kako treba. :-))



Da nemas neku ideju sta je razlog ovoga. Mozda pogresno podesena aplikacija ili ZF bug?! Izlaz koji dobijem je:

Pa ja mislim da je taj izuzetak kojeg dobijaš logičan... Prouči kako radi ViewRenderer action helper (klasa Zend_Controller_Action_Helper_ViewRenderer). Obrati pažnju koja pravila za filtriranje koristi njegov inflector (getInflector() metod). Kao što ćeš videti, akcija se provlači kroz ovaj set filtera: array('Word_CamelCaseToDash', new Zend_Filter_PregReplace('#[^a-z0-9' . preg_quote('/', '#') . ']+#i', '-'), 'StringToLower'). Pre svega toga, primeti da ViewRenderer provlači akcjiu kroz dispatcher-ov (Zend_Controller_Dispatcher) _formatName() metod, koji pravi PHP-friendly name, brišući sve ne-alfanumeričke karaktere. Dakle akcija će biti evaluirana kao ta bez prefiksa, ali ime view script-a će biti pogrešno.

Probaj da izbegavaš takve situacije...

Jos jednom hvala na pomoci! Sad cu da pogledam to.

Mada možda si i u pravu kad kažeš da je to bug, jer ako sam te dobro razumeo, ti nemaš deklarisanu akciju sa donjom crtom kao prefiksom, već samo tu neku standardnu, a ipak kad u browser-u uneseš site.com/ime-kontrolera/_ime-akcije, umesto očekivane "Not found" greške dobijaš taj izuzetak, koji govori da je ZF-ov dispatch-er ipak pronašao pravu akciju (a ne bi trebao), ali je problem što nema view script-a koji odgovara imenu te (nepostojeće) akcije.

Bas tako.

Je l se susreo neko mozda sa sledecim problemom. Napravio sam route koje se prevode tako da se prilikom posete adresa
/archive
/moja-arhiva
poziva 'module' => 'default', 'controller' => 'index', 'action' => 'test'. E sad tu se javlja problem. Ja zelim da kad neko poseti /archive i zatrazi prevod za neki key da dobije prevod za taj jezik. Trenutno to neradi kako treba, a uspeso sam da utvrdim da ce se koristiti razlicit locale u zavisnosti kako je definisem za rutu

Kad posetim linkove imam sledeci izlaz
/archive
month
/moja-arhiva [pogresno]
/moja-arhiva
/moja-arhiva

/moja-arhiva
month [pogresno]
/moja-arhiva
/moja-arhiva
/moja-arhiva

Ono sto ja ocekujem je da /archive sastavi link /archive umesto /moja-arhiva, a da /moja-arhiva za prevod ispise mesec.

A ako uradim ovako


/archive
mesec [pogresno]
/moja-arhiva [pogresno]
/moja-arhiva
/moja-arhiva

/moja-arhiva
month
/moja-arhiva
/moja-arhiva
/moja-arhiva

Engleska ruta vuce pogresan prevod i link, a na srpskoj je sve ok!?

Evo i koda