Smartyt használok, valószínű ezt is fogok még egy darabig.
Nem próbáltam (ezt már írtam fent.), de a meglévő light dokumentációt elolvasgatván, észrevettem néhány okos funkciót, amit néha hiányoltam.(bár ezek is megoldhatók PHP oldalon)
régen talán az volt, mostmár azt hiszem, azért ezen túlnőtt. mindenesetre ez olyan, mint a keretrendszerek, vagy akármi: absztrakció egy (cél)feladatra, segédeszköz, produktivitás segítő
Először is ez nem tűnik nekem új abstrakciós szintnek, csupán egyszerüsített (jobbanmondva testreszabott) szintaxisnak. Aztán pedig (ez gondolom a smartyra lesz igaz): jól látom, hogy a második kódrészletben szemléltetett funkció később került bele az eszközbe? Ez alapjána dolog már is kezd egy butácska PHPvé válni. Amit látok annyi, hogy az idő próbáját kiállt C szintaxist sikerült valami újjal kiváltanunk. Mivben jobb ez, mint egy foreach PHPben?
Megelégszem egy URL-lel, ami értelmes választ ad, de egyszerűen képtelen vagyok megérteni, miért írunk egy lassú szkriptnyelv fölé még egyet... komolyan.
Volt egyszer egy ilyen thread: http://weblabor.hu/forumok/temak/18219. Itt nagyjából elhangzik elég sok érv, ami a egy smarty szintű cucc mellett szólhat. Manapság viszont a menő frameworköknél szinte mindenhol sima PHP a template, ami annyiban jó, hogy nagyobb a szabadság, viszont könnyebb is disznóságot csinálni, viszont valamilyen szinten maga a framework megvéd attól, hogy a template-ba az kerüljön, ami odavaló.
Régebben szerettem a smartyt, viszont amikor kitaláltunk egy bonyolultabb view réteget a házi frameworkünkbe, akkor pár dolgot macerás lett volna már smartyban megoldani, ezért maradt a sima PHP. Viszont nagyon szépen előjött, hogy a kicsit bonyolultabb eszközkészletet nem mindig jól használták a sitebuilderek, illetve a bátrabbak esetén került néha a templatebe olyan logika, amit nem volt szerencsés odatenni.
Amúgy épp mostanában megint előjött nekem a framework kérdésköre, és még most is szerintem a symfony-nak van az egyik legjobban kitalált view rétege (a ZF kiterjesztettjét még nem néztem).
Egyébként a Smartyban két dolgot nem szeretek, az egyik a viszonylagos átgondolatlansága, a másik hogy az Eclipse szintaktikai elemzője hanyatt dobja magát tőle. A natív PHP meg... olvasható... még nézelődöm, hogy mit lehetne jól használni. Szemezek az XSLT-vel is, bár az meg lehet, hogy ágyúval verébre.
Ahogy nézem ezt a dolgot viszont, egy dolog nagyon nagyon nagyon tetszik benne: http://wiki.dwoo.org/index.php/TemplateInheritance
Én már egy ideje ezt használom Smarty helyett:
http://phptal.motion-twin.com/
Pont az a dolog fogott meg benne, amit te is kiemeltél a dwoo kapcsán. No meg a HTML-be ágyazott custom attribútumok. Cserébe sokkal kevesebbet tud, mint a Smarty, de legalább így nagyjából nullára redukálódott annak az esélye, hogy véletlenül ne megjelenítési logikát tegyek a megjelenítésbe.
Pluginekkel természetesen ez is bővíthető.
én elég sokáig ragaszkodtam a saját sablonozómnál, hogy xml alapú legyen. de sajnos a maga előnyei mellett, megvannak a korlátai is. pl.: egy link href attribútumát elég macerás dinamikussá tenni így. (meg lehet csinálni, csak nem lesz kényelmes használni)
ha a sablonaidat ténylegesen szabvány xml-nek akarod, akkor:
- vagy a meglevő, xml tag alapú funkciókat egészíted ki úgy, hogy attribútumokat másik szintaktikával módosítasz
Nem tudom, hogy a feldolgozó utasítások helyére milyen szabályok vonatkoznak, nem tartom elképzelhetetlennek, hogy az szerepelhet attribútumban is. Márpedig a <?php szintakszis az feldolgozó utasítás, nem XML node.
az alapfelvetés az volt, hogy xml alapú sablon. arra próbáltam rámutatni, hogyha ehhez ragaszkodunk, akkor -jelen ötleteim szerint- nem lesz túl kényelmeg sablont írni. vagy nem lesz xml
Érdekelne, hogy mikre gondolsz ezalatt. Kicsit bátor kijelentésnek érzem, nem akármilyen fejlesztő(k) csinálták, plusz a Smarty igencsak előremutató cucc volt a maga idejében.
Hogy csak a legtriviálisabb példát mondjam, az összeadásra van külön dedikált művelet, a string konkatenálásra nincs. :) Illetve van, csak filter gyanánt. Szerintem, ez átgondolási probléma. Semmi kétség afelől hogy a Smarty egy tetemes munkát megcsinál helyettem, de ugyanolyan átgondolatlannak értem, mint a PHP-t. :)
Mi köze a két dolognak egymáshoz? Miért jó egy template kezelőben szöveget konkatenálni (simán egymásmellé teszed a két változót)?
Másrészt ez a példa olyan, mintha azt mondanád, hogy tök szar ez meg ez az autó, mert nincs a kesztyűtartóban fésű, messze nem az szint, ami alapján egy smarty méretű cuccot jellemezni lehet. Átgondolatlan példa. ;)
Egy checkboxnál próbáltam volna elérni, hogy akkor legyen "selected", ha az értéke megegyezik egy tömbben átadott értékkel. Mivel a checkbox-gyűjtemény egy kapcsolótáblás szerkezetből született, ezért az egyes checkboxok name-ja úgy nézett ki, hogy mezonev_id. Namost, ezt a mezonev_id-t szerettem volna előállítani Smartyban, hogy az adott indexű tömbelemet meg tudjam lesni. Mivel nagy mennyiségű mezőről volt szó, ezért nagy szerepet játszott az automatizmus az elemek kigenerálásában. (include multicheckbox.html... :)
Egyrészt (egyre betegesebben használom ezt a szót :)) ezek szerint nem szöveg konkatenálást nem tud a smarty, hanem nem engedi meg, hogy tömindexként kifejezést tudj megadni (ennek speciel elég jó oka lehet, mert így sem triviális az a pár regexp, amivel operál). Viszont tök egyszerű megkerülni, először egy assignban hozod létre a változó nevét, és utána tudod használni tömbindexként, nincs szükség semmilyen filterre.
Amit tényleg nem tud a smarty: variable variable, ami elég hasznos tud lenni, de ez is kb. ennyi:
Lehet ilyet csinálni, de speciel az egyszerűség kedvéért azt szerettem volna hogy egy ilyen multifield úgy jön létre, hogy egy változóban odaadom a queryből kapott adatokat, egy másikban a számára lényeges generáló paramétereket és a többit intézze el maga. Úgy kerültem meg a problémát (igen, később láttam a lentebb említett cat megoldást) hogy natív PHP kódként tettem be. Nem szép, de működik. :)
nem tudom, hogy pontosan értem-e mit szerettél volna, de nekem is szükségem volt automatikusan előállított űrlapok select-jeinél hasonlóra. itt egy megoldás:
Igen, ezt utána már én is megtaláltam, a lényeg a mondandómban az lett volna, hogy rámutassak a Smarty ilyen jellegű átgondolatlanságaira, mint pl van összeadás de cat hasonló módon már nincs.
rámutassak a Smarty ilyen jellegű átgondolatlanságaira, mint pl van összeadás de cat hasonló módon már nincs.
Fentebb arra próbáltam meg rámutatni, hogy tök más dolgról beszélsz. Ahogyan összeadás van, úgy cat is van (illetve nincs ;), mert nincs is rá szükség). Amit hiányolsz az nem cat, hanem az, hogy kifejezés lehessen egy tömbindex, ennek meg elég jó oka van, hogy ne bonyolódjon el a feldolgozás egy olyan funkció érdekében, amire az esetek többségében nincsen szükség, és amúgy meg könnyedén megoldható hackolás nélkül is.
Lehet, bár én úgy láttam értelmét, hogy ne kelljen a View rétegen kívül azzal szórakoznom, hogy melyik a kiválasztott elem, ami szerintem nem egy irreális elvárás. De egyébként értem, mit mondasz. Visszatérve az eredeti témára, csomószor találkozom olyasmivel Smartyban hogy vannak dolgok amiket meg lehet csinálni, de hozzájuk hasonló dolgokat nem lehet ugyanúgy vagy egyáltalán nem lehet. Lehet, hogy nem tudom jól érzékeltetni példával, de ez volt az érzésem. :)
Érdekelne, hogy létezik-e a fenti igényeket kielégítő sablonozórendszer, ami nem maga a php?
pl.:
{content <li>$content</li>}
Mindezt egymásba ágyazva, megspékelve foreach-ekkel. Ha nem, akkor szerintem egy speciális szerkesztő összeállítása sem egy nagy feladat, ugyanis az igények nagyon hasonlóak (foreach, isset, echo)
tapasztalat?
Tapasznyalás az nincs
Érdekes, hogy pont azokat a dolgokat tudja, amit a Smarty-ból hiányoltam
valószínűleg más is :)
Nem próbáltam
Nem próbáltam (ezt már írtam fent.), de a meglévő light dokumentációt elolvasgatván, észrevettem néhány okos funkciót, amit néha hiányoltam.(bár ezek is megoldhatók PHP oldalon)
Associative Array Example: {assign}
http://wiki.dwoo.org/index.php/Helpers:array
http://www.smarty.net/manual/en/language.custom.functions.php#language.function.assign
bővebben:
http://wiki.dwoo.org/index.php/Main_Page
köszi
Ha jól tudom...
szvsz nemegészen
absztrakció?
Megelégszem egy URL-lel, ami értelmes választ ad, de egyszerűen képtelen vagyok megérteni, miért írunk egy lassú szkriptnyelv fölé még egyet... komolyan.
template kezelő
Régebben szerettem a smartyt, viszont amikor kitaláltunk egy bonyolultabb view réteget a házi frameworkünkbe, akkor pár dolgot macerás lett volna már smartyban megoldani, ezért maradt a sima PHP. Viszont nagyon szépen előjött, hogy a kicsit bonyolultabb eszközkészletet nem mindig jól használták a sitebuilderek, illetve a bátrabbak esetén került néha a templatebe olyan logika, amit nem volt szerencsés odatenni.
Amúgy épp mostanában megint előjött nekem a framework kérdésköre, és még most is szerintem a symfony-nak van az egyik legjobban kitalált view rétege (a ZF kiterjesztettjét még nem néztem).
Üdv,
Felhő
látom...
Köszi.
Mennyire olvasható...
Ahogy nézem ezt a dolgot viszont, egy dolog nagyon nagyon nagyon tetszik benne: http://wiki.dwoo.org/index.php/TemplateInheritance
PHPTAL
http://phptal.motion-twin.com/
Pont az a dolog fogott meg benne, amit te is kiemeltél a dwoo kapcsán. No meg a HTML-be ágyazott custom attribútumok. Cserébe sokkal kevesebbet tud, mint a Smarty, de legalább így nagyjából nullára redukálódott annak az esélye, hogy véletlenül ne megjelenítési logikát tegyek a megjelenítésbe.
Pluginekkel természetesen ez is bővíthető.
Jól
xml template
Nem értem
szabvány xml
- vagy a meglevő, xml tag alapú funkciókat egészíted ki úgy, hogy attribútumokat másik szintaktikával módosítasz
(vagy mint valaki fent belinkelte: lehet csak attribútumokra alapuló sablonozást használni, amivel azért vannak fenntartásaim :))
Processing instruction
<?php
szintakszis az feldolgozó utasítás, nem XML node.xml
átgondolatlanság?
Üdv,
Felhő
Példa
minek
Másrészt ez a példa olyan, mintha azt mondanád, hogy tök szar ez meg ez az autó, mert nincs a kesztyűtartóban fésű, messze nem az szint, ami alapján egy smarty méretű cuccot jellemezni lehet. Átgondolatlan példa. ;)
Üdv,
Felhő
Mező
assign
Amit tényleg nem tud a smarty: variable variable, ami elég hasznos tud lenni, de ez is kb. ennyi:
Felhő
Lehet...
Ez jellemző...
Igen ez jellemző a Smartyra, hogy néhány dolgot, ilyen megkellkerülni dologgal lehet elintézni.
konkatenálás
szerk: kicsit átírtam, hogy érthetőbb legyen.
Láttam
read only
Üdv,
Felhő
Lehet...
ennél egyszerűbb
pl.:
xsl?
Nem teljesen ugyanaz