Hello!
Smarty PHP-ben hogyan lehet megoldani, hogy tudjon keresni az adatbázis egy bizonyos táblájában majd azt kilistázza?
Válaszokat előre is köszi.
Hozzászólások
Hello!
Én úgy tudom a smarty egy template kezelő rendszer, ami csak limitált funkciókat (pl. loop-ok egy listához/sorokhoz tud)
adatbázisból lekérdezni amúgy sem a megjelenítési rétegben kell.
Szerintem kérdezd le egy tömbbe, majd a smarty segítségével a tömbön szaladj végig valamilyen ciklussal, hogy azt szépen "megjelenítse".
Remélem seítettem egy kicsit, ha van még kérdés írd meg konkrétabban és segítünk.
nézz utána az MVC felfogásnak, hogyan kell gondolkodnod az adatok összeállításáról, és csak utána a megjelenítéséről, a smarty az utóbbira jó, a már összerakott adatokat tudja megjeleníteni
javaslom akármit csinálsz, eszerint tervezd újra, képzeld el legegyszerűbben úgy, hogy teljesen más az, hogy lekérem az adatbázisból az adatokat és összerakom egy tömbbe, és megint más az amikor ezt megjeleníted html-be tüzdelve
(megjegyzem nekem a tapasztalatom szerint a smarty sokmindenre jó, de egyáltalán nem ajánlom általánosságban)
Van benne ket pelda class is, egy controller es egy model, igy konnyen ki lehet talalni, hogy hogyan tudod betolteni a db-bol a objektumot, es hogyan tudod a smarty-nak atadni. Arra figyelj, hogy itt osztalypeldanyok mennek at, es nem asszociativ tombok, igy az attributumokra $user->login formaban kell hivatkozni, nem pedig $user.login formaban.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
bár értemén a mvc-t, de sok esetben annyira komikus az egész kod felépitése, hogy gyakorlatilag full goto az egész. de mint tudjuk az igazi programozo nem fél a gototol. átláthatatlan, tulkomplikált.
azt fentebb direkt nem írtam, hogy érdemes a sablonkezelés után a másik nagy kérdéskört is végiggondolni: objektum vagy nem objektum. látszólag nincs kérdés, de a fenti példádhoz hasonlóan, én sok project-nél tapasztalom (főleg ha nincs egész pontos irány kialakítva), hogy gyorsabb és átláthatóbb egy procedúrális kód.
én ugy csinálnom, hogy az alap dolgok vannak osztályozva. smarty, mysql+memcache egyben, login, stb. és ezekből legozom össze. ha valami a kodbol több helyen kell, akkor megy osztályba. gyakorlati tapasztalat az, hogy ha egy kod többhelyen kell, többnyire pici modositásokkal mégis máshogyan kell, így tisztább ujra megírni, mint pl egy osztályban teleifezgetni, bevive millionyi hibát. ha valamit egyszer használok, felesleges classozni szerintem. egyik helyen igy kell a gyorsitotárazás, másik helyen ugykell... katyvasz. néztem mvc-s mintákat, tök jol lehet vele villantani, de a classban ugyanugy globálozgat, mint nem classban, "beleéget" $_GET-et, $_SESSIONT. mivan ha mégse onnan jon az adat, máris használhatatlan. hameg nagyon specifikus, egyszerhasználatos kod, megint ottvagyok hogy felesleges classozni.
kérdés, utána kéne nézni, hogy performancéban vane különbség akodfuttatásnál a class nemclass megoldásnak...
Teljesitmenyben ertelmes kod es kodszervezes mellett nincs szamottevo kulonbseg az OOP es a proceduralis kod kozott, nagyon nagy latogatottsagu oldalak futnak nalunk egy OOP alapu frameworkon, korabban proceduralis volt, eroforrasigenyben nincs szamottevo novekedes (tehat valamivel nagyobb az igenye, ez teny, de osszessegeben nem nagy mertekben).
Az atlathatosag pedig teljes mertekben programozo kerdese. Nekem az OOP kod sokkal jobban attekintheto, sokkal jobban szervezheto, akkor is, ha en csak egy szinten szervezem a dolgokat (csak oszalyokba, nem hasznalok nevtereket). Raadasul nekem nagy ellensegem a nevadas, proceduralis szervezesnel nagyon sokszor jott az elo, hogy mar nem tudtam mivel prefixelni a hasonlo funkcioju, de alapvetoen totalisan mas fuggvenyeket. Az osztaly kerdes viszont ezt megoldja.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
kért url: /valami mod_neve.php?m=valami
kért url: /valami/kutya mod_neve.php?m=valami&q=kutya
kért url: /valami1 mod_neve.php?m=valami1
kért url: /masvalami mod_neve2.php?m=masvalami
van egy init.php, amiben beolvasom a konfot, példányositom az osztályokat, és előkészitem ami kell 99%ban mindenhova. van egy 4000 soros fuggvénygyűjteményem is, ami tényleg univerzális, mindenhova jo. get_next_array_key; get_prev_array_key; sok hasznos dolog.
mod_neve.php:
include init.php;
switch(true){
case $_GET['m']=='valami':
if(post_keres_van){
// feldolgozom;
header location valahova;
exit
}
$mysql->query('select 1');
$smarty->assign($mysql->valamifetch);
break;
case $_GET['m']=='valami1':
if(post_keres_van){
feldolgozom;
}
//barmi mas kod
break;
}
$smarty->display('valami.tpl');
a htaccessben a szépurlt átforgatom paraméterezett phpre, így hivom meg. így egyszerűen ki lehet kapcsolni részeket, az eltérű sitefunkciok kulon fájlt kapnak, kevés a felesleges gépelés, tiszta átlátható a kód. a switch szerkezettel jol lehet kontrolálni. ide mondtam ha sokat használt sitespecifikus eljárások, kodsorok lennének, akkor készülne egy osztály, amibe ezek belekerülnének, és az lenne meghivva switch egy esetében.
Igen, ismerem ezt a fajta szervezest, ketto bajom van vele:
- szamomra atlathatatlan
- szamomra ertelmetlen
Nalam a .htaccess ketto darab sorbol all:
RewriteEngine On
RewriteRule . /index.php [L]
Es ennyi, a tobbit index.php -bol oldom meg. Mert igenis, egy webapp legyen kepes onmagat elroutolni manko nelkul.
Ez kivalt annak fenyeben tunik fontosnak, hogy ugy nez ki: az 5.4-tol az lesz a trendi, hogy a beepitett webszervert hasznaljuk fejlesztesre, ahol viszont nincs rewrite modul.
De ez az en velemenyem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Hogy kezdünk egy ilyet fejleszteni:
1. Meghatározzuk mit szeretnénk
2. Megpróbáljuk algoritmikusan elképzelni
3. Átgondoljuk az első 2 pontot ismét
4. Visszatérünk az előző ponthoz
5. Megírjuk a router algoritmusunkat az 1. pont alapján
6. Használjuk
Az hogy hova rakod, az már más kérdés, de a tied felesleges bonyolult, a switch (true) miatt el se kezdeném tovább nézni.
Nálam egy ilyen kódot nem tolnál át a szűrőn, helyből vágnám vissza, sőt, kiegészíteném a tanulj előbb sorokkal
mivel nem vagyok úgy gépközelben, ezért most nem.
Nekem van egy jól megírt route osztályom, ami controller/view/action -re bont szét mindent, lehet benne átirányításokat végezni és új route folyamatot indítani (ami pl egy wizzard esetében rohadt jó tud lenni), illetve kezeli a beérkező paramétereket. Mindezt dúrván kb. 80 sorban.
Mivel kellően generikus, az elmúlt két évben egyszer nem nyúltam hozzá és "haxolás" nélkül mindent meg tudtam benne valósítani.
Nezd meg a linkelt GitHub repo-t. A README-ben le van irva, hogy hogyan tortenik a mappeles. Meg kb. minden.
Persze, ez meg eleg alap, at akarom irni regexesre, csak ahhoz melyebben meg kell ismerkednem a PHP regex kepessegeivel. De az alap otlet az az, hogy a routokat at kell konvertalni controller, action es param reszekre.
Jelenleg kod szinten elegge szet van osztva a dolog, a nagy resze a classes/Request.class.php 133. sora kornyeken kezdodik, de nemi utofeldolgozas van az index.php-ben is (a tenyleges route hivas).
"továbbá miért jobb phpbol? gyorsabb? egyszerűbb?"
Egyreszt egyszerubb, masreszt az oldal igy fuggetlenedik mindentol. Sokszor van olyan, hogy pl. tarhelyre fejleszt az ember, ahol nem mindent lehet megtenni htaccessbol, vagy egyenesen tiltott, ilyenkor macera minden egyes routing otlet miatt rendszergazdat kerni.
Aztan meg sokkal tobb lehetoseget kapsz a kezedbe. Gondold el, akar SQL-beli infok alapjan is routolhatsz, vagy akarmit megtehetsz, anelkul, hogy akar csak ismerned is kellene, hogy 1) milyen webszerver alatt futsz es 2) ott ezt hogy lehet megtenni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
tudsz nekem segíteni egy példával? hasonlóan egyszerű htaccess-t használok (RewriteRule ^(.*) index.php?redir=$1 [QSA]), de ez ha nincs rewrite modul, akkor problémás...
(jelenleg az index-ben kezelem azt, hogy a hívott cím mi lehet, szöveges tartalom, termékoldal, speciális funkció, ... és megjelenítem, amit meghívtak, különböző precedenciákat kezelve, ha jól értem az általad vázolt irányt használom, de az alábbi miatt nem vagyok biztos:)
"
beepitett webszervert hasznaljuk fejlesztesre, ahol viszont nincs rewrite modul
"
Ugye az en modszeremnek annyi a trukkje, hogy (legalabbis apache + mod_php eseteben) akkor is mukodik, ha nincs rewrite modul: az url-eket meg kell prefixelni egy index.php -vel.
Es neked is azt ajanlom, hogy nezegesd a linkelt GitHub repo-t, fentebb irtam, hogy mit erdemes nezni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Ha nem érzed, nc., de akkor már kifejtem:
Egy vezérlési szerkezetet nem úgy használni, ahogy azt kitalálták, az maximum beteg, elvetemült és szar megoldás. Ráadásként áttekinthetetlen is és durván semmi értelme
Az, hogy nem szervezi egyaltalan a rendszert, es pillanatok alatt valik kezelhetetlenul naggya, mivel fuggetlen dolgok lesznek egy helyen.
a minimalis megoldas az szokott lenni, hogy:
$action = tisztit($_REQUEST['action']) || "defaultaction";
if (is_callable($action){
call_user_func($action);
}
Ekkor meg nincsenek osztalyaid, nincsenek kulon fajljaid, egy funkcionalitas - egy funkcio felosztas van csak, ami anno a minimalkovetelmeny volt ahhoz, hogy egyaltalan vegighallgassalak egy interjun.
de e mentén nagyon gyorsan akár kiszervezheted osztályokba is, sőt...:) Autoloader alkalmazása mellett egy nagyon egyszerű és nagyon gyors megoldást alakíthatsz belőle egyszerű projectekhez
nem mondtam, hogy egy nagy file lesz az egész site, és azt sem mondtam, hogy független dolgok lesznek egy helyen. tehát nem verem egybe a logint az index oldallal. rajtam múlik, hogy mit verek egybe, és mit szedek külön, mind a te esetedben, mind az én esetemben. továbbá annak nem látom értelmét, hogy egyszer használt dolgokat kitegyek függvénybe, hogy azon belül globálozgassak, meg ugráljak oda ha debugolni kell. az egyszer futó dolgok ott ahol kell, egyébként osztály.
<?php
include ('init.php');
switch ($_GET['m']) {
case 'tags': #/hirek/valami a kérés
// $_GET['q']ban a cimke
//ha van a cacheben break;
//kiszedjuk az oldalszámot, ha nincs ilyen include('mod_404.php');
$smarty->assign('sumpage', $mysql->result('oldal'));
$smarty->assign('itemcount', $mysql->result('db'));
//lekérdezzük az elso oldalt
$mysql->query($elsooldal_sql);
$smarty->assign('list', $mysql->fetchtoArray());
$smarty->assign('title', 'Hírek');
$smarty->append('header', array('title' => 'Hírek ' . htmlspecialchars($_GET['q']) . ' témában'), true);
break;
case 'list': #/hirek a kérés
//ha van a cacheben break;
//kiszedjuk az oldalszámot
$smarty->assign('sumpage', $mysql->result('oldal'));
$smarty->assign('itemcount', $mysql->result('db'));
//lekérdezzük az elso oldal
$mysql->query($elsooldal_sql);
$smarty->assign('list', $mysql->fetchtoArray());
$smarty->append('header', array('title' => 'Hírek', 'description' => 'Hírek'), true);
break;
case 'details': /hirek/allatok-23 az url
//kiszedjuk az sqlből, esetleg dolgoz rajta, smartyhoz assignol. $_GET['url']ben az url $_GET['id']ben az id, ha nincs ilyen include('mod_404.php');
break;
}
$smarty->display('index_news.tpl');
?>
ez egybe tartozó dolog, 3 block egy fájlon belül. könnyen bővíthető. pl ha lenne képgaléria, azt egy másik hasonló szerkezetű fájl dolgozná fel.
nálam ez jol bevált, nem kell ugrálnom összevissza.
azt megfontolhatnád, hogy a rewrite-okat php-ből kezeld, rugalmasabb, én erre használom szinte csak az index-et...feldarabolom a bejövő address-t, megnézem precedenciákat mérlegelve, hogy milyen tartalmat akar a user lekérni, van-e olyan tartalom, van-e olyan speciális modul, stb., sorban, ... innentől ugyan az, mint nálad, elvi szinten.
van-e hozzá joga, és egyéb kérdéseket ugye a modul kezeli, amit betöltök, de alapvetően nekem könnyebb volt php-ből kezelni ezt, mint htaccess-t bővítgetni, ha adott project-ben kell egy olyan oldal, aminél az adott form-ot nem contact-nak, hanem services-nek hívják. itt csak egy config átírás
feledékeny vagyok, nem találom épp, hogy mi volt, amit nem tudtam htaccess-ben megoldani rewrite-al, valaminél kezelni akartam azt, hogy ha megadja A paramétert, és B-t, és C-t, akkor ez, de ha nem adja meg B-t, akkor is, csak B akkor legyen default...ha megtalálom bedobom ide
amúgy a másik, hogy valahogy jobban kézre állt feldolgozni az egész bejövő address-t mint egy string-et, kiszedni, hogy rakott-e bele anchor-t, van-e olyan paraméter ami csak adott oldalra vonatkozik, van-e olyan ami globális beállítás, ezek php-ben egy if, htaccess-ben néha minden előző sor újra bemásolása egy kiegészítéssel, végén lesz egy x soros htaccess-ed, ahelyett, hogy lenne egy folyamatod php-ben
Szerintem meg ez harom dolog egyetlen fuggvenyben, egy tags, egy list, meg egy details.
Megcsak egy szokozod sincs kozottuk.
Meg vim-be is irok olyan makrot, ami adott nevu fuggvenyre keres, a debugging nem mentseg.
Szoval ez neked lehet hogy jo, de en nem szeretnek ilyen kodot kapni, mert nagyon sok idom menne el azzal, hogy rendberakjam, es igy meg nem mernem feltenni sehova se.
function execute_list($smarty){
//ha van a cacheben break;
//kiszedjuk az oldalszámot
$smarty->assign('sumpage', $mysql->result('oldal'));
$smarty->assign('itemcount', $mysql->result('db'));
//lekérdezzük az elso oldal
$mysql->query($elsooldal_sql);
$smarty->assign('list', $mysql->fetchtoArray());
$smarty->append('header', array('title' => 'Hírek', 'description' => 'Hírek'), true);
}
function execute_details($smarty){
//kiszedjuk az sqlből, esetleg dolgoz rajta, smartyhoz assignol. $_GET['url']ben az url $_GET['id']ben az id, ha nincs ilyen include('mod_404.php');
}
main();
?>
Ezek utan mar csak az Implementation Patterns vonatkozo fejezeteit kene elso korben alkalmazni, es akar lehetne is egy nem OOP-s valtozatunk.
Amugy egy switch-case mindig refaktorolhato reflectionre.
megleptél, eddig meglepetésemre sok helyről kaptam vissza, hogy az objektum orientált kód optimálisabban fut...beigazolódni látszik, hogy csak sz@r procedurális kóddal hasonlították össze.
az OOP-s tapasztalatom is kevés (tény), és legtöbbször elég zavarosnak tűnő, épp változás alatt levő kódokat láttam ezügyben, emiatt konkrétan nekem problémát jelentett állandóan összehangolni az objektumok működését...ez procedúrális elgondolásnál is probléma, de nem volt annyi munka, mint objektumoknál...mondom, lehet tapasztalat hiánya.
tapasztalat hiányának meg az oka: eddig nem tűnt úgy, hogy nagyon rászorulok OOP-ben való építkezésre, egyszerűen tudtam úgy építeni procedurális kódot is, hogy ne legyen szükségem névterekre, lib-eknél összetettebb kódbázisokat
(troll off please, nem kifejezetten óriás rendszereken dolgozom, ahol vannak konvenciók, és érdemes objektumokat bevezetni)
Igazabol PHP-ban nem vagyok nagyon otthon, igy lehet, hogy amit en merek (egy ceges belso fejlesztesu framework) az a PHP szempontjabol szuboptimalisan van megirva. Az en szemszogembol azt jelenti az optimalis, hogy OOP szempontbol optimalis, nincsenek nagy hulyesegek benne. A PHP reszet - mivel tenyleg csak kocafejleszto vagyok ebben a nyelvben - nem tudom objektiven megitelni, amit tudok, az alapjan legalabbis nem tul rossz.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
"tapasztalat hiányának meg az oka: eddig nem tűnt úgy, hogy nagyon rászorulok OOP-ben való építkezésre, egyszerűen tudtam úgy építeni procedurális kódot is, hogy ne legyen szükségem névterekre, lib-eknél összetettebb kódbázisokat"
Míg meg nem érted az OOP lényegét és nem tudod jól alkalmazni, addig tényleg nyűg, a procedurális programozás meg faék egyszerűségű, lévén csak sodródsz az árral szemlélet.
Viszont így pár év elteltével már kevés olyan valid dolgot látok magam előtt, amit oop nélkül kezdenék el.
A gyakorlatban nem programozunk OOP-t, szerencsere, fraszt kapnek egy smalltalk envtol.
Kepzeld el azt, hogy minden objektumod scala actor. Na, ez az OOP.
Amit csinalunk, az strukturalt programozas. Ezekben az osztalyokat Dahl vezette be. A kezdet kezdetetol (a 72-es "Strukturalt Programozas" c. konyv megjelenese ota) jelen vannak.
Tudom, van mindenfele nezet az OOP-rol, maradjunk annyiban, hogy ha random felutok egy projektet githubon, az 80-90%-ban SP-szeruen fogja hasznalni az osztalyokat, plane ha webMVC frameworkrol lesz szo.
Nem csak a strukturalt programozasra gondolok, hanem pl az adatbazis reprezentalasara objektum orientaltsag elven.
Ertheto hogy a main logikat nem objektumkent fogom tekinteni, viszont egy adott controller felepitese, mukodese, adott osztalytol valo szarmaztatasa mar oop szamomra.
Es pl. egy altalanos megoldas, hogy az action-ok kezeleset adott ojjektumon belul egyforma megoldassal kezelem, lenyegtelen hogy milyen megvalositassal, mar tenyleg nem szamit
miert lenne az mvc full goto? Valamit beneztel:)
Ha neked az MVC egyenlő azzal, hogy valahol is goto-t kell használnod, akkor valamit nagyon de nagyon nem értesz mégsem
a kód széttagoltságára gondolok. kirakod osztályba a dolgokat, akár elemi szinten is, és ahhoz hogy magad lekövesd, ugrálnod kell egy csomo fileban. így értettem.
Ez lenne az objektum orientált programozás lényege. Annak nem nagyon van értelme, hogy egy osztályba bepakolok mindent. Szerintem.
MVC esetében pedig tudom, hogy a modell szolgáltatja az adatokat, és nem érdekel hogyan teszi. A controller elvégzi rajtuk amit kell, és adja a view részére a megjelenítendő adathalmazt. a view megjeleníti. Ha tartom magam a naming conventions-hoz mindenről tudom hol keressem.
A lényeg, én CakePHP-vel nagyon jól elvagyok, és nem zavar a sok fájl, mindent tudok, hol keressek. A 2.2.x óta a core-hoz csak nagyon extrém esetekben kell nyúlni.
nem tudom miről beszélsz, de most rám vonatkozik a "nem is érdekel".
Nálad valami nagyon fura dolog lehet, mert sem az objektum orientáltság, sem az mvc nincs a helyén. Így kérlek ne, ismétlem !ne! alkoss véleményt, főleg hülyeségről:)
ha már smarty topic, és elmentünk teoretikai irányba:
smarty vagy nem smarty?
én magam nem használom, elég kevés template kezelő funkciót használok, de pl. érdekelne, hogy gyakorlatban tényleg jobb-e, mint egy foreach-et elmagyarázni 2 percben egy designer-nek, egy echoval (sőt, erre saját function-t írni hogy jobban átlássa a sablonfájlt), tényleg gyorsít-e érdemben a munkán és a futáson? van-e olyan előnye, amiről nem tudok?
hogy miről nemtudsz, azt nemtudom.
a smarty lassan dolgozza fel a templatet, de utána szerintem piszokgyors. konnyen bővithető, jol dokumentált, van támogatás. szerintem jo. ha megtanulod, halados
nekem semmi elonyom nem szarmazott a smartybol, lassuk be a php tempalte nyelv (volt valaha), teljes mertekben alkalmas kezelni a view reteget (ha mar mvc).
persze, ez az en velemenyem, gyozzetek meg, hogy nincs igazam (bar lassuk be, hogy ez egy soha veget nem ero vita, az internet egyik fele ezt, a masik fele azt mondja) :P
elonyod lehet nem, de hatranyod sem, ebben biztos vagyok. A smarty az összes mvc-hez szükséges dolgot a kezedbe nyomja, csak használni kell. Másrészt, a smarty kódja view kezelésre sokkal szebb és érthetőbb, másodrészt nagyon egyszerű dolgokat (pl hogy minden második sor legyen szürke egy táblázatban), jóval elegánsabb is.
En azert szerettem meg a smarty-t, mert sokszor szaladtam bele abban, hogy a short_open_tags nem volt engedelyezve a szerveren, es szerintem a
<?php echo $fubar ?>
undorito. Elso korben valami ASP szeru template cuccot kerestem, aztan szembejott a smarty, eleg sok funkciot tudott, es nagyon tamogatottnak tunt, igy maradt. Ma mar nem tudom, mit csinalnek nelkule.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Nagy kedvencem az öröklés, a blokkok:
pl. az új adat felvitele és az új adat módosítása gyakorlatilag ugyanaz a form, csak a módosításnál van default érték, illetve egy plusz sor a táblázatban, ami az eredeti értéket tartalmazza - nem kell még egyszer ugyanazt megírni, hanem csak kibővíted. Mindenhova ugyanazok a gombok kellenek (OK, Mégsem, legfeljebb más felirattal), minek minden egyes formra megírni ugyanazt? A gombokat beleteszem egy blokkba, amit felül lehet írni, illetve bővíteni.
Jó, tudom, hogy PHP-ban is meg lehet oldani, de miért kellene feltalálni a spanyolviaszt?
Template-bol helper-eket szokas meghivni, de ez keretrendszer fuggo es kb olyan szintu dolgokra hasznaljak, hogy pl van-e valami a kosarban, ha igen, akkor irjuk ki mennyi tetel. Ha tenyleg le kell kerdezni valamit, akkor a Controllerbol tessek a model-t atadni a template-nek. Vagy ahogy a Rails csinalja, egy Relation Object-et, hogy ha veletlenul Cache-bol jon adat, akkor ne legyen az adatbazishoz nyulva.
Szerintem a Smarty-t hagyd meg annak amire való. Jeleníts meg vele adatokat.
Nem kell adatbázisba turkálni vele. Erre csinálj egy controllert és egy modelt ami átadja neki a megjeleníteni kívánt adatot.
Hozzászólások
Hello!
Én úgy tudom a smarty egy template kezelő rendszer, ami csak limitált funkciókat (pl. loop-ok egy listához/sorokhoz tud)
adatbázisból lekérdezni amúgy sem a megjelenítési rétegben kell.
Szerintem kérdezd le egy tömbbe, majd a smarty segítségével a tömbön szaladj végig valamilyen ciklussal, hogy azt szépen "megjelenítse".
Remélem seítettem egy kicsit, ha van még kérdés írd meg konkrétabban és segítünk.
ahogy kollega fentebb leírta, úgy igaz.
nézz utána az MVC felfogásnak, hogyan kell gondolkodnod az adatok összeállításáról, és csak utána a megjelenítéséről, a smarty az utóbbira jó, a már összerakott adatokat tudja megjeleníteni
javaslom akármit csinálsz, eszerint tervezd újra, képzeld el legegyszerűbben úgy, hogy teljesen más az, hogy lekérem az adatbázisból az adatokat és összerakom egy tömbbe, és megint más az amikor ezt megjeleníted html-be tüzdelve
(megjegyzem nekem a tapasztalatom szerint a smarty sokmindenre jó, de egyáltalán nem ajánlom általánosságban)
+1, mvc -nek nézz utána.
Smarty-ban semmi keresni valója adatbázisból való lekérdezésnek
Mar regota publikalni akartam, ez a forum topik adta meg a vegso loketet.
Van egy alapszintu frameworkom, semmi extra, Smarty + PDO, egy kis MVC feelinggel.
Esetleg nezd meg: https://github.com/hron84/html5-smarty-boiler
Van benne ket pelda class is, egy controller es egy model, igy konnyen ki lehet talalni, hogy hogyan tudod betolteni a db-bol a objektumot, es hogyan tudod a smarty-nak atadni. Arra figyelj, hogy itt osztalypeldanyok mennek at, es nem asszociativ tombok, igy az attributumokra $user->login formaban kell hivatkozni, nem pedig $user.login formaban.
--
bár értemén a mvc-t, de sok esetben annyira komikus az egész kod felépitése, hogy gyakorlatilag full goto az egész. de mint tudjuk az igazi programozo nem fél a gototol. átláthatatlan, tulkomplikált.
<?php
$page = new page();
$page->run();
?>
na az ilyeneknek aztán van értelme :D
azt fentebb direkt nem írtam, hogy érdemes a sablonkezelés után a másik nagy kérdéskört is végiggondolni: objektum vagy nem objektum. látszólag nincs kérdés, de a fenti példádhoz hasonlóan, én sok project-nél tapasztalom (főleg ha nincs egész pontos irány kialakítva), hogy gyorsabb és átláthatóbb egy procedúrális kód.
én ugy csinálnom, hogy az alap dolgok vannak osztályozva. smarty, mysql+memcache egyben, login, stb. és ezekből legozom össze. ha valami a kodbol több helyen kell, akkor megy osztályba. gyakorlati tapasztalat az, hogy ha egy kod többhelyen kell, többnyire pici modositásokkal mégis máshogyan kell, így tisztább ujra megírni, mint pl egy osztályban teleifezgetni, bevive millionyi hibát. ha valamit egyszer használok, felesleges classozni szerintem. egyik helyen igy kell a gyorsitotárazás, másik helyen ugykell... katyvasz. néztem mvc-s mintákat, tök jol lehet vele villantani, de a classban ugyanugy globálozgat, mint nem classban, "beleéget" $_GET-et, $_SESSIONT. mivan ha mégse onnan jon az adat, máris használhatatlan. hameg nagyon specifikus, egyszerhasználatos kod, megint ottvagyok hogy felesleges classozni.
kérdés, utána kéne nézni, hogy performancéban vane különbség akodfuttatásnál a class nemclass megoldásnak...
Ez egyeni hozzaallas kerdese, semmi tobb.
Teljesitmenyben ertelmes kod es kodszervezes mellett nincs szamottevo kulonbseg az OOP es a proceduralis kod kozott, nagyon nagy latogatottsagu oldalak futnak nalunk egy OOP alapu frameworkon, korabban proceduralis volt, eroforrasigenyben nincs szamottevo novekedes (tehat valamivel nagyobb az igenye, ez teny, de osszessegeben nem nagy mertekben).
Az atlathatosag pedig teljes mertekben programozo kerdese. Nekem az OOP kod sokkal jobban attekintheto, sokkal jobban szervezheto, akkor is, ha en csak egy szinten szervezem a dolgokat (csak oszalyokba, nem hasznalok nevtereket). Raadasul nekem nagy ellensegem a nevadas, proceduralis szervezesnel nagyon sokszor jott az elo, hogy mar nem tudtam mivel prefixelni a hasonlo funkcioju, de alapvetoen totalisan mas fuggvenyeket. Az osztaly kerdes viszont ezt megoldja.
--
példa egy egyszerű appra nálam:
kért url: /valami mod_neve.php?m=valami
kért url: /valami/kutya mod_neve.php?m=valami&q=kutya
kért url: /valami1 mod_neve.php?m=valami1
kért url: /masvalami mod_neve2.php?m=masvalami
van egy init.php, amiben beolvasom a konfot, példányositom az osztályokat, és előkészitem ami kell 99%ban mindenhova. van egy 4000 soros fuggvénygyűjteményem is, ami tényleg univerzális, mindenhova jo. get_next_array_key; get_prev_array_key; sok hasznos dolog.
mod_neve.php:
include init.php;
switch(true){
case $_GET['m']=='valami':
if(post_keres_van){
// feldolgozom;
header location valahova;
exit
}
$mysql->query('select 1');
$smarty->assign($mysql->valamifetch);
break;
case $_GET['m']=='valami1':
if(post_keres_van){
feldolgozom;
}
//barmi mas kod
break;
}
$smarty->display('valami.tpl');
a htaccessben a szépurlt átforgatom paraméterezett phpre, így hivom meg. így egyszerűen ki lehet kapcsolni részeket, az eltérű sitefunkciok kulon fájlt kapnak, kevés a felesleges gépelés, tiszta átlátható a kód. a switch szerkezettel jol lehet kontrolálni. ide mondtam ha sokat használt sitespecifikus eljárások, kodsorok lennének, akkor készülne egy osztály, amibe ezek belekerülnének, és az lenne meghivva switch egy esetében.
Igen, ismerem ezt a fajta szervezest, ketto bajom van vele:
- szamomra atlathatatlan
- szamomra ertelmetlen
Nalam a .htaccess ketto darab sorbol all:
Es ennyi, a tobbit index.php -bol oldom meg. Mert igenis, egy webapp legyen kepes onmagat elroutolni manko nelkul.
Ez kivalt annak fenyeben tunik fontosnak, hogy ugy nez ki: az 5.4-tol az lesz a trendi, hogy a beepitett webszervert hasznaljuk fejlesztesre, ahol viszont nincs rewrite modul.
De ez az en velemenyem.
--
+1
tudnál irni példát, hogy csinálod?
pl indexes urlt véve :
/gazdasag/magyar/2012/09/02/akk-azerbajdzsan/
/gazdasag/magyar
/gazdasag
/gazdasag/blog
/kulfold
/kulfold/usa
/24ora/kulfold
továbbá miért jobb phpbol? gyorsabb? egyszerűbb?
Hogy kezdünk egy ilyet fejleszteni:
1. Meghatározzuk mit szeretnénk
2. Megpróbáljuk algoritmikusan elképzelni
3. Átgondoljuk az első 2 pontot ismét
4. Visszatérünk az előző ponthoz
5. Megírjuk a router algoritmusunkat az 1. pont alapján
6. Használjuk
Az hogy hova rakod, az már más kérdés, de a tied felesleges bonyolult, a switch (true) miatt el se kezdeném tovább nézni.
Nálam egy ilyen kódot nem tolnál át a szűrőn, helyből vágnám vissza, sőt, kiegészíteném a tanulj előbb sorokkal
máshogy teszem fel a kérdést:
egy létező routolást be tudnál kopizni? csakhogy én is megértsem.
mivel nem vagyok úgy gépközelben, ezért most nem.
Nekem van egy jól megírt route osztályom, ami controller/view/action -re bont szét mindent, lehet benne átirányításokat végezni és új route folyamatot indítani (ami pl egy wizzard esetében rohadt jó tud lenni), illetve kezeli a beérkező paramétereket. Mindezt dúrván kb. 80 sorban.
Mivel kellően generikus, az elmúlt két évben egyszer nem nyúltam hozzá és "haxolás" nélkül mindent meg tudtam benne valósítani.
nezd meg valamilyen php (vagy barmilyen) framework routing megoldasait (symfony, cakephp, ror), sokat lehet belole tanulni.
"tudnál irni példát, hogy csinálod?"
Nezd meg a linkelt GitHub repo-t. A README-ben le van irva, hogy hogyan tortenik a mappeles. Meg kb. minden.
Persze, ez meg eleg alap, at akarom irni regexesre, csak ahhoz melyebben meg kell ismerkednem a PHP regex kepessegeivel. De az alap otlet az az, hogy a routokat at kell konvertalni controller, action es param reszekre.
Jelenleg kod szinten elegge szet van osztva a dolog, a nagy resze a classes/Request.class.php 133. sora kornyeken kezdodik, de nemi utofeldolgozas van az index.php-ben is (a tenyleges route hivas).
"továbbá miért jobb phpbol? gyorsabb? egyszerűbb?"
Egyreszt egyszerubb, masreszt az oldal igy fuggetlenedik mindentol. Sokszor van olyan, hogy pl. tarhelyre fejleszt az ember, ahol nem mindent lehet megtenni htaccessbol, vagy egyenesen tiltott, ilyenkor macera minden egyes routing otlet miatt rendszergazdat kerni.
Aztan meg sokkal tobb lehetoseget kapsz a kezedbe. Gondold el, akar SQL-beli infok alapjan is routolhatsz, vagy akarmit megtehetsz, anelkul, hogy akar csak ismerned is kellene, hogy 1) milyen webszerver alatt futsz es 2) ott ezt hogy lehet megtenni.
--
tudsz nekem segíteni egy példával? hasonlóan egyszerű htaccess-t használok (RewriteRule ^(.*) index.php?redir=$1 [QSA]), de ez ha nincs rewrite modul, akkor problémás...
(jelenleg az index-ben kezelem azt, hogy a hívott cím mi lehet, szöveges tartalom, termékoldal, speciális funkció, ... és megjelenítem, amit meghívtak, különböző precedenciákat kezelve, ha jól értem az általad vázolt irányt használom, de az alábbi miatt nem vagyok biztos:)
"
beepitett webszervert hasznaljuk fejlesztesre, ahol viszont nincs rewrite modul
"
Ugye az en modszeremnek annyi a trukkje, hogy (legalabbis apache + mod_php eseteben) akkor is mukodik, ha nincs rewrite modul: az url-eket meg kell prefixelni egy index.php -vel.
Es neked is azt ajanlom, hogy nezegesd a linkelt GitHub repo-t, fentebb irtam, hogy mit erdemes nezni.
--
jobb helyeken egy ilyenért:
switch(true){
case $_GET['m']=='valami':
levágják az ember kezét. Értem én, hogy működik, de azért nah
mi vele a probléma?
pl hogy ez kérdés:)
mégegyszer:
mi vele a probléma?
Ha nem érzed, nc., de akkor már kifejtem:
Egy vezérlési szerkezetet nem úgy használni, ahogy azt kitalálták, az maximum beteg, elvetemült és szar megoldás. Ráadásként áttekinthetetlen is és durván semmi értelme
Az, hogy nem szervezi egyaltalan a rendszert, es pillanatok alatt valik kezelhetetlenul naggya, mivel fuggetlen dolgok lesznek egy helyen.
a minimalis megoldas az szokott lenni, hogy:
$action = tisztit($_REQUEST['action']) || "defaultaction";
if (is_callable($action){
call_user_func($action);
}
Ekkor meg nincsenek osztalyaid, nincsenek kulon fajljaid, egy funkcionalitas - egy funkcio felosztas van csak, ami anno a minimalkovetelmeny volt ahhoz, hogy egyaltalan vegighallgassalak egy interjun.
de e mentén nagyon gyorsan akár kiszervezheted osztályokba is, sőt...:) Autoloader alkalmazása mellett egy nagyon egyszerű és nagyon gyors megoldást alakíthatsz belőle egyszerű projectekhez
nem mondtam, hogy egy nagy file lesz az egész site, és azt sem mondtam, hogy független dolgok lesznek egy helyen. tehát nem verem egybe a logint az index oldallal. rajtam múlik, hogy mit verek egybe, és mit szedek külön, mind a te esetedben, mind az én esetemben. továbbá annak nem látom értelmét, hogy egyszer használt dolgokat kitegyek függvénybe, hogy azon belül globálozgassak, meg ugráljak oda ha debugolni kell. az egyszer futó dolgok ott ahol kell, egyébként osztály.
legyen egy egyszerű példa:
RewriteRule ^hirek$ /modules/news.php?m=list [QSA,L]
RewriteRule ^hirek/(.*)-([0-9]+)$ /modules/news.php?m=details&url=$1&id=$2 [QSA,L]
RewriteRule ^hirek/(.*)$ /modules/news.php?m=tags&q=$1 [QSA,L]
hozzá tartozo php
<?php include ('init.php'); switch ($_GET['m']) { case 'tags': #/hirek/valami a kérés // $_GET['q']ban a cimke //ha van a cacheben break; //kiszedjuk az oldalszámot, ha nincs ilyen include('mod_404.php'); $smarty->assign('sumpage', $mysql->result('oldal')); $smarty->assign('itemcount', $mysql->result('db')); //lekérdezzük az elso oldalt $mysql->query($elsooldal_sql); $smarty->assign('list', $mysql->fetchtoArray()); $smarty->assign('title', 'Hírek'); $smarty->append('header', array('title' => 'Hírek ' . htmlspecialchars($_GET['q']) . ' témában'), true); break; case 'list': #/hirek a kérés //ha van a cacheben break; //kiszedjuk az oldalszámot $smarty->assign('sumpage', $mysql->result('oldal')); $smarty->assign('itemcount', $mysql->result('db')); //lekérdezzük az elso oldal $mysql->query($elsooldal_sql); $smarty->assign('list', $mysql->fetchtoArray()); $smarty->append('header', array('title' => 'Hírek', 'description' => 'Hírek'), true); break; case 'details': /hirek/allatok-23 az url //kiszedjuk az sqlből, esetleg dolgoz rajta, smartyhoz assignol. $_GET['url']ben az url $_GET['id']ben az id, ha nincs ilyen include('mod_404.php'); break; } $smarty->display('index_news.tpl'); ?>ez egybe tartozó dolog, 3 block egy fájlon belül. könnyen bővíthető. pl ha lenne képgaléria, azt egy másik hasonló szerkezetű fájl dolgozná fel.
nálam ez jol bevált, nem kell ugrálnom összevissza.
szerintem.
azt megfontolhatnád, hogy a rewrite-okat php-ből kezeld, rugalmasabb, én erre használom szinte csak az index-et...feldarabolom a bejövő address-t, megnézem precedenciákat mérlegelve, hogy milyen tartalmat akar a user lekérni, van-e olyan tartalom, van-e olyan speciális modul, stb., sorban, ... innentől ugyan az, mint nálad, elvi szinten.
van-e hozzá joga, és egyéb kérdéseket ugye a modul kezeli, amit betöltök, de alapvetően nekem könnyebb volt php-ből kezelni ezt, mint htaccess-t bővítgetni, ha adott project-ben kell egy olyan oldal, aminél az adott form-ot nem contact-nak, hanem services-nek hívják. itt csak egy config átírás
azt értesd meg velem mintával, hogy miért rugalmasabb, miért jobb phpbol feldolgozni.
feledékeny vagyok, nem találom épp, hogy mi volt, amit nem tudtam htaccess-ben megoldani rewrite-al, valaminél kezelni akartam azt, hogy ha megadja A paramétert, és B-t, és C-t, akkor ez, de ha nem adja meg B-t, akkor is, csak B akkor legyen default...ha megtalálom bedobom ide
amúgy a másik, hogy valahogy jobban kézre állt feldolgozni az egész bejövő address-t mint egy string-et, kiszedni, hogy rakott-e bele anchor-t, van-e olyan paraméter ami csak adott oldalra vonatkozik, van-e olyan ami globális beállítás, ezek php-ben egy if, htaccess-ben néha minden előző sor újra bemásolása egy kiegészítéssel, végén lesz egy x soros htaccess-ed, ahelyett, hogy lenne egy folyamatod php-ben
Szerintem meg ez harom dolog egyetlen fuggvenyben, egy tags, egy list, meg egy details.
Megcsak egy szokozod sincs kozottuk.
Meg vim-be is irok olyan makrot, ami adott nevu fuggvenyre keres, a debugging nem mentseg.
Szoval ez neked lehet hogy jo, de en nem szeretnek ilyen kodot kapni, mert nagyon sok idom menne el azzal, hogy rendberakjam, es igy meg nem mernem feltenni sehova se.
oké, akkor fenti példánal maradva, te hogy kodolnád le? csak így nagyjából leirva.
<?php
include ('init.php');
function main(){ //azert rakjuk ide, hogy felulrol lefele lehessen olvasni a kodot, opcionalis
$action = $_GET['m']; //tisztitjuk, mind1
$action_fn = "execute_".$action; //parameterek beszedese utan ures sor!
if (is_callable($action_fn)){
call_user_func($action_fn, $smarty);
$smarty->display('index_news.tpl');
}
}
function execute_tags($smarty){
// $_GET['q']ban a cimke
//ha van a cacheben break;
//kiszedjuk az oldalszámot, ha nincs ilyen include('mod_404.php');
$smarty->assign('sumpage', $mysql->result('oldal'));
$smarty->assign('itemcount', $mysql->result('db'));
//lekérdezzük az elso oldalt
$mysql->query($elsooldal_sql);
$smarty->assign('list', $mysql->fetchtoArray());
$smarty->assign('title', 'Hírek');
$smarty->append('header', array('title' => 'Hírek ' . htmlspecialchars($_GET['q']) . ' témában'), true);
}
function execute_list($smarty){
//ha van a cacheben break;
//kiszedjuk az oldalszámot
$smarty->assign('sumpage', $mysql->result('oldal'));
$smarty->assign('itemcount', $mysql->result('db'));
//lekérdezzük az elso oldal
$mysql->query($elsooldal_sql);
$smarty->assign('list', $mysql->fetchtoArray());
$smarty->append('header', array('title' => 'Hírek', 'description' => 'Hírek'), true);
}
function execute_details($smarty){
//kiszedjuk az sqlből, esetleg dolgoz rajta, smartyhoz assignol. $_GET['url']ben az url $_GET['id']ben az id, ha nincs ilyen include('mod_404.php');
}
main();
?>
Ezek utan mar csak az Implementation Patterns vonatkozo fejezeteit kene elso korben alkalmazni, es akar lehetne is egy nem OOP-s valtozatunk.
Amugy egy switch-case mindig refaktorolhato reflectionre.
ja, értelek már.
[dupla]
megleptél, eddig meglepetésemre sok helyről kaptam vissza, hogy az objektum orientált kód optimálisabban fut...beigazolódni látszik, hogy csak sz@r procedurális kóddal hasonlították össze.
az OOP-s tapasztalatom is kevés (tény), és legtöbbször elég zavarosnak tűnő, épp változás alatt levő kódokat láttam ezügyben, emiatt konkrétan nekem problémát jelentett állandóan összehangolni az objektumok működését...ez procedúrális elgondolásnál is probléma, de nem volt annyi munka, mint objektumoknál...mondom, lehet tapasztalat hiánya.
tapasztalat hiányának meg az oka: eddig nem tűnt úgy, hogy nagyon rászorulok OOP-ben való építkezésre, egyszerűen tudtam úgy építeni procedurális kódot is, hogy ne legyen szükségem névterekre, lib-eknél összetettebb kódbázisokat
(troll off please, nem kifejezetten óriás rendszereken dolgozom, ahol vannak konvenciók, és érdemes objektumokat bevezetni)
Igazabol PHP-ban nem vagyok nagyon otthon, igy lehet, hogy amit en merek (egy ceges belso fejlesztesu framework) az a PHP szempontjabol szuboptimalisan van megirva. Az en szemszogembol azt jelenti az optimalis, hogy OOP szempontbol optimalis, nincsenek nagy hulyesegek benne. A PHP reszet - mivel tenyleg csak kocafejleszto vagyok ebben a nyelvben - nem tudom objektiven megitelni, amit tudok, az alapjan legalabbis nem tul rossz.
--
"tapasztalat hiányának meg az oka: eddig nem tűnt úgy, hogy nagyon rászorulok OOP-ben való építkezésre, egyszerűen tudtam úgy építeni procedurális kódot is, hogy ne legyen szükségem névterekre, lib-eknél összetettebb kódbázisokat"
Míg meg nem érted az OOP lényegét és nem tudod jól alkalmazni, addig tényleg nyűg, a procedurális programozás meg faék egyszerűségű, lévén csak sodródsz az árral szemlélet.
Viszont így pár év elteltével már kevés olyan valid dolgot látok magam előtt, amit oop nélkül kezdenék el.
Azert mondjuk ez meg a lo masik oldala.
A gyakorlatban nem programozunk OOP-t, szerencsere, fraszt kapnek egy smalltalk envtol.
Kepzeld el azt, hogy minden objektumod scala actor. Na, ez az OOP.
Amit csinalunk, az strukturalt programozas. Ezekben az osztalyokat Dahl vezette be. A kezdet kezdetetol (a 72-es "Strukturalt Programozas" c. konyv megjelenese ota) jelen vannak.
Tudom, van mindenfele nezet az OOP-rol, maradjunk annyiban, hogy ha random felutok egy projektet githubon, az 80-90%-ban SP-szeruen fogja hasznalni az osztalyokat, plane ha webMVC frameworkrol lesz szo.
Nem csak a strukturalt programozasra gondolok, hanem pl az adatbazis reprezentalasara objektum orientaltsag elven.
Ertheto hogy a main logikat nem objektumkent fogom tekinteni, viszont egy adott controller felepitese, mukodese, adott osztalytol valo szarmaztatasa mar oop szamomra.
Es pl. egy altalanos megoldas, hogy az action-ok kezeleset adott ojjektumon belul egyforma megoldassal kezelem, lenyegtelen hogy milyen megvalositassal, mar tenyleg nem szamit
miert lenne az mvc full goto? Valamit beneztel:)
Ha neked az MVC egyenlő azzal, hogy valahol is goto-t kell használnod, akkor valamit nagyon de nagyon nem értesz mégsem
a kód széttagoltságára gondolok. kirakod osztályba a dolgokat, akár elemi szinten is, és ahhoz hogy magad lekövesd, ugrálnod kell egy csomo fileban. így értettem.
Ez lenne az objektum orientált programozás lényege. Annak nem nagyon van értelme, hogy egy osztályba bepakolok mindent. Szerintem.
MVC esetében pedig tudom, hogy a modell szolgáltatja az adatokat, és nem érdekel hogyan teszi. A controller elvégzi rajtuk amit kell, és adja a view részére a megjelenítendő adathalmazt. a view megjeleníti. Ha tartom magam a naming conventions-hoz mindenről tudom hol keressem.
hát amit néztem mvc mintákat, mind ilyen szétaprózótt valami volt. a "nem érdekel hogyan teszi" egy jobbféle meglátás.
MVC mintát egyet ismerek :) megvalósítás az van sok :)
oké vazze, kössé bele. :D
A lényeg, én CakePHP-vel nagyon jól elvagyok, és nem zavar a sok fájl, mindent tudok, hol keressek. A 2.2.x óta a core-hoz csak nagyon extrém esetekben kell nyúlni.
nem tudom miről beszélsz, de most rám vonatkozik a "nem is érdekel".
Nálad valami nagyon fura dolog lehet, mert sem az objektum orientáltság, sem az mvc nincs a helyén. Így kérlek ne, ismétlem !ne! alkoss véleményt, főleg hülyeségről:)
fél-off:
ha már smarty topic, és elmentünk teoretikai irányba:
smarty vagy nem smarty?
én magam nem használom, elég kevés template kezelő funkciót használok, de pl. érdekelne, hogy gyakorlatban tényleg jobb-e, mint egy foreach-et elmagyarázni 2 percben egy designer-nek, egy echoval (sőt, erre saját function-t írni hogy jobban átlássa a sablonfájlt), tényleg gyorsít-e érdemben a munkán és a futáson? van-e olyan előnye, amiről nem tudok?
hogy miről nemtudsz, azt nemtudom.
a smarty lassan dolgozza fel a templatet, de utána szerintem piszokgyors. konnyen bővithető, jol dokumentált, van támogatás. szerintem jo. ha megtanulod, halados
tudnál pár funkciót mondani, amit megoldott neked, a kvázi behelyettesítős template kezelésen kívül? (lásd egy foreach)
nemértem. foreachre mondjak példát?
http://www.smarty.net/docs/en/language.function.foreach.tpl
nekem semmi elonyom nem szarmazott a smartybol, lassuk be a php tempalte nyelv (volt valaha), teljes mertekben alkalmas kezelni a view reteget (ha mar mvc).
persze, ez az en velemenyem, gyozzetek meg, hogy nincs igazam (bar lassuk be, hogy ez egy soha veget nem ero vita, az internet egyik fele ezt, a masik fele azt mondja) :P
elonyod lehet nem, de hatranyod sem, ebben biztos vagyok. A smarty az összes mvc-hez szükséges dolgot a kezedbe nyomja, csak használni kell. Másrészt, a smarty kódja view kezelésre sokkal szebb és érthetőbb, másodrészt nagyon egyszerű dolgokat (pl hogy minden második sor legyen szürke egy táblázatban), jóval elegánsabb is.
En azert szerettem meg a smarty-t, mert sokszor szaladtam bele abban, hogy a short_open_tags nem volt engedelyezve a szerveren, es szerintem a
undorito. Elso korben valami ASP szeru template cuccot kerestem, aztan szembejott a smarty, eleg sok funkciot tudott, es nagyon tamogatottnak tunt, igy maradt. Ma mar nem tudom, mit csinalnek nelkule.
--
Nagy kedvencem az öröklés, a blokkok:
pl. az új adat felvitele és az új adat módosítása gyakorlatilag ugyanaz a form, csak a módosításnál van default érték, illetve egy plusz sor a táblázatban, ami az eredeti értéket tartalmazza - nem kell még egyszer ugyanazt megírni, hanem csak kibővíted. Mindenhova ugyanazok a gombok kellenek (OK, Mégsem, legfeljebb más felirattal), minek minden egyes formra megírni ugyanazt? A gombokat beleteszem egy blokkba, amit felül lehet írni, illetve bővíteni.
Jó, tudom, hogy PHP-ban is meg lehet oldani, de miért kellene feltalálni a spanyolviaszt?
Ilyen kérdést csak PHP "programozó" tud feltenni :)
És a magasságosnak mi a tanácsa a földi halandónak, ha már kérdezni mert?
Template-bol helper-eket szokas meghivni, de ez keretrendszer fuggo es kb olyan szintu dolgokra hasznaljak, hogy pl van-e valami a kosarban, ha igen, akkor irjuk ki mennyi tetel. Ha tenyleg le kell kerdezni valamit, akkor a Controllerbol tessek a model-t atadni a template-nek. Vagy ahogy a Rails csinalja, egy Relation Object-et, hogy ha veletlenul Cache-bol jon adat, akkor ne legyen az adatbazishoz nyulva.
Bovebben: http://sandor.czettner.hu/blog/11/10/26/rails-3-relation-object
Smarty-val is megy ugyanez, csak moge kell rakni egy kis logikat. Ha mindenkeppen template engine kell, miert nem Twig?
Ne bantsd a Smarty-t, nagyon jo kis template rendszer.
--
+1
Szerintem a Smarty-t hagyd meg annak amire való. Jeleníts meg vele adatokat.
Nem kell adatbázisba turkálni vele. Erre csinálj egy controllert és egy modelt ami átadja neki a megjeleníteni kívánt adatot.
arth2o: honlapkészítés