ugrás a tartalomhoz

Sablon rendszerrel kapcsolatban kérnék segítséget

felyx · 2008. Feb. 5. (K), 04.31
A segítségeteket szeretném kérni, régóta foglalkoztat a gondolat, hogy egy sablon rendszert elkezdjek használni. Smarty-t egyszer megnéztem és biztos vagyok benne, hogy jó és használható, de miután eleget olvasgattam a témában úgy gondolom sokkal ésszerűbb php nyelven kezelni a sablonokat több szempontból is. A problémám abból adódik, hogy hiába töltöttem estéket azzal hogy utánajárjak annak, hogy php-ben hogyan tudnám megvalósítani ezt, nem sikerült megértenem jobban a hogyanját. Sajnos nem vagyok phpguru, de látom a pozitív oldalát a sablonoknak és ha valaki megtenné, hogy elmagyarázza, hogyan működik a sablon kezelés pontosan és mit érdemes tudnia egy ilyen rendszernek, akkor nagyon szépen megköszönném. Ha esetleg példákkal is meg tudná valaki mutatni azt is megköszönném, de nem várok kész megoldást, bár nem titkolom kerestem hasonló egyszerű rendszert, hogy az alapján sajátot írhassak. Furcsának tűnhet, hogy ha nem tudom hogyan is működik a dolog akkor miért akarom használni, no a válaszom az, hogy egyrészt a kinézetét az oldalnak könnyebben megtudnám változtatni, másrészt ha olyasvalakivel dolgozok együtt egy projecten aki nem programozó, akkor ne kelljen neki a php kóddal túl sokat foglalkoznia, csak alapvető dolgokat kelljen megmutatnom neki. Elnézéseteket kérem mindenesetre, mert tudom hogy ez a téma már sokszor felmerült, igyekeztem megoldást találni de sajnos már nemtudom hol keressem a választ. Segítségeteket előre is köszönöm.
 
1

Saját template engine

Max Logan · 2008. Feb. 5. (K), 10.53
Az utóbbi időben éppen egy saját template engine-t írtam. Tegnap lettem vele kész, szóval jelenleg béta állapotban van. Ha gondolod odaadom, de dokumentáció még nincsen hozzá és mivel még béta, lehetnek benne hibák.

Én a CakePHP vonalán indultam el. Megnéztem, hogy ott hogyan van megoldva a view-k megjelenítése és abból kiindulva írtam meg (meg a Smarty-t is nézegettem, de már konkrétan nemtom, hogy onnan mit lestem el). Objektum Orientált alapokon nyugszik egyébként, valamint a sablonfájlok sima HTML állományok beágyazott PHP kóddal. Ez mondjuk ott gond lehet, ahol a sitebuilder nem ismeri a PHP-t.
2

Megnézném.

felyx · 2008. Feb. 5. (K), 14.09
Megnézném ha nem bánod, hogy esetleg ötleteket merítek belőle.
3

Ok

Max Logan · 2008. Feb. 5. (K), 14.18
Keress meg magánba (a honlapomon megtalálod a mail címem) és elküldöm. Adok egy egyszerű példát is, de annál jóval többet tud az engine (a kód egyébként jól kommentelt, szóval meg lehet érteni, hogy mit lehet vele kezdeni) ...

Ui.: Ahogy időm engedi befejezem a bugkeresést és elkészítem hozzá a doksit is. Majd dobok egy blogmark-ot ha készen van ...
4

E-mail

felyx · 2008. Feb. 5. (K), 18.55
Küldtem neked egy e-mailt a megadott címre. Köszönöm a segítséget.
5

symfony view

Hodicska Gergely · 2008. Feb. 7. (Cs), 19.20
Szerintem az egyik legjobban kitalált view réteg a symfonyban van, érdemes lehet ötlet szerzésként megnézni. Mi annó egy ehhez nagyon hasonló cuccot csináltunk, csak egy kicsit optimalizálva lett nagy terhelésű, több nyelvű oldalak kiszolgálásához.


Üdv,
Felhő
6

Köszönöm.

felyx · 2008. Feb. 8. (P), 00.48
Köszönöm, hogy szóltál, megnéztem és tényleg jónak tűnik, habár nekem pont az a problémám a legtöbb sablon rendszerrel/megjelenítő rendszerrel, hogy többet tudnak, mint amire valójában szükség van és a végén már jóformán a *.tpl fileokban is csak php van az alapvető html elemektől eltekintve. Ez az én véleményem szerint egyrészt lassítja is az oldalt, másrészt bonyolítja is azt, sokkal több a dinamikus rész ami jó, de ez lényegesen több munkát ad az oldalnak, persze mire valo a chache...az segít ezen, de ettől sem feltétlenül hatékonyabb. Persze mások mindenkinek az igényei, de amikor még programozó tanuló voltam, a tanáraim mindig panaszkodtak, hogy mindent túlbonyolítok. Megfogadtam a tanácsuk és igyekszem racionálisan dönteni, hogy egy-egy feladatot hogyan oldjak meg. Egyszerűségre és hasznosságra törekszem, így csak azokat a feladatokat akarom elvégeztetni a sablon rendszerrel, amit feltétlen muszály. Nem arról van szó, hogy a php-t kell elválasztani a html-től, hiszen nem ez a lényege, de azt sem látom jó megoldásnak, hogy gyakorlatilag mindent phpvel végeztetünk.

Mégegyszer szeretném megköszönni a tanácsod ötletszerzéshez mindenképpen jó.
11

A symfony view rétegében mihez hasonlított a ti cuccotok?

Fraki · 2008. Feb. 9. (Szo), 21.47
A symfony view rétegében mihez hasonlított a ti cuccotok? Kaszkádolt konfiguráció? yml-ban? Response object? Component slots? Escape-stratégia (ez az array interfészes data object)? Minden? :)

Csak érdeklődöm.
14

ennyire nem

Hodicska Gergely · 2008. Feb. 10. (V), 02.17
Ami nagyon tetszett a symfony-ban az a slot, és az escapelés. Korábban olyat használtam már, hogy JS-t lehetett a headerhez adni, de ez így rugalmasabb. Az escapelés meg jó ötlet, mert sajnos elég sokan folyamatosan megfeledkeznek róla, ha meg már valamiért a raw formára van szükséged, akkor meg már tudni fogod, hogy miről is van szó.

Blokkunk korábban is volt, de ezt szét választottuk az új rendszerben blokkra és komponensre. A blokknak nincs saját üzleti logikája (maximum mindig rendelkezésre álló rendszer változókat használ, pl. be van-e jelentkezve a user), míg a komponensnek van. Kb. ő egy mini MVC, saját maga állítja elő az adatszükségletét.

Kb. ezek voltak amiket átvettünk koncepcionális szinten, a megvalósítás teljesen saját, nem is néztük nagyon meg, hogy a symfonyban hogyan lett megoldva.

Konfig, array interface: ilyesmi konkrétumokra eleve nem volt szükségünk, de amúgy is túlzásnak érzem.


Üdv,
Felhő
18

Nekem is kicsit túllihegettnek tűnt egy-két dolog, részben..

Fraki · 2008. Feb. 10. (V), 22.41
Nekem is kicsit túllihegettnek tűnt egy-két dolog, részben ezért is kérdeztem, részben meg azért, hogy megtudjam, mennyire symfony-specifikus az, amire az arra való hivatkozásod alatt gondolni kell. (Nem nagyon.)
19

symfony view

Hodicska Gergely · 2008. Feb. 11. (H), 02.41
Azért azt vedd hozzá, hogy mi ott egy olyan rendszerhez terveztünk, ami napi több 10 millió kérést kell kiszolgáljon, ezért fontos szempont volt az egyszerűség, és ezzel együtt funkcionalitásában elégge hasonló lett. Ehhez képest egy symfony egy általános framework, aminek szélesebb réteget kiszolgálnia. Az meg hogy bonyolultabb a kódja, annak oka is lehet.

Ezzel együtt a symfony view része szerintem nagyon jól ki van találva, minden részének meg van a gyakorlati haszna is, és ha körbenézel a top frameworkök esetében, általában jóval kevesebbet nyújtanak, általában a layout támogatásban merül ez ki.


Üdv,
Felhő
20

Szerintem félreértesz, még egyszer: csupán arra voltam...

Fraki · 2008. Feb. 11. (H), 04.28
Szerintem félreértesz, még egyszer: csupán arra voltam kíváncsi, mennyire csak a symfonyra jellemző az, amit megvalósítottatok, vagy mennyire inkább csak általános dolog, ami mellesleg a symfonyban is van. (Nem vitattam, miért implementáltatok sajátot.) Merthogy úgy tűnt nekem, hogy a symfonyban elég sok dolog van (már a view rétegen belül). Például ott van a kaszkádolt konfig koncepciója, ami igen lényeges. Tkp. a django template-öröklődésének felel meg. Erre azt mondtad, túlzás. Elementek, blokkok, komponensek, helperek/partials, automatikus eszképelés stb. meg máshol is vannak.

És alapvetően a symfony is "layout-támogatást" ad.

Tehát ismétlem: nem vagyok meggyőződve róla, hogy olyan nagyon symfony-specifikus volna az általatok megvalósított koncepció, dehát győzz meg.
21

értettelek

Hodicska Gergely · 2008. Feb. 11. (H), 12.36
És pont ezért is válaszoltam, mert ezeket a funkciókat nem nagyon láttam a mostani menő keretrendszerekben (kb. ez alatt most ZF, Cake, Solar), általában nincs ilyen szinten kidolgozva ez a rész.

Például ott van a kaszkádolt konfig koncepciója, ami igen lényeges. Tkp. a django template-öröklődésének felel meg. Erre azt mondtad, túlzás.
Nekünk túlzás, nem alapvetően haszontalan ötlet.

Elementek, blokkok, komponensek, helperek/partials, automatikus eszképelés stb. meg máshol is vannak.
A helpert nem keverném ide, az b. függvény gyűjtemény. Én nem nagyon láttam máshol ilyen szintű kidolgozottságot, ZF-hez láttam ajánlást, ami szinte ez volt. Ezzel együtt nem spanyol viasz, de egy jól átgondolt egész.

És alapvetően a symfony is "layout-támogatást" ad.
Csak éppen lényegesen több funkcióval. Persze ezt megírhatod helperekkel, csak itt már készen van.

Tehát ismétlem: nem vagyok meggyőződve róla, hogy olyan nagyon symfony-specifikus volna az általatok megvalósított koncepció, dehát győzz meg.
Nem célom téged győzködni. :) (Csak tudom már, hogy miket néztem meg, miből indultunk ki, és milyen ötleteket honnan vettem át.)


Üdv,
Felhő
22

Szerintem megint félreértettél, én sem a symfonyval...

Fraki · 2008. Feb. 11. (H), 18.39
Szerintem megint félreértettél, én sem a symfonyval kapcsolatos véleményedet nem vitatom, sem a symfonyt nem értékeltem. Rendben, kidolgozottság, oké. Arra voltam csak kíváncsi, hogy _az a rendszer_, amit _az erre való hivatkozással_ említettél, az mennyire tükrözi valóban csak a symfonyt és annak a kidolgozottságát.

Erre kaptam is választ: nem nagyon. Ennyi. Győzködnöd sem kell, már válaszoltál.

„általában nincs ilyen szinten kidolgozva ez a rész.”

Mint ahogy a ti rendszeretekben sem.

„Nekünk túlzás, nem alapvetően haszontalan ötlet.”

Így van, a mondat első része érdekelt elsősorban.

„Csak éppen lényegesen több funkcióval.”

Biztos lehetne erről is tartalmas vitákat folytatni, de ismétlem, a kérdésem nem erről szólt. Minden meg van válaszolva.
23

hihetetlen vagy :)

Hodicska Gergely · 2008. Feb. 11. (H), 21.12
És én érzem hülyén magam, hogy leírok valamit, és simán eldöntöd az ellenkezőjét. Többször leírtam, hogy funkciókat vettünk átt a symfonyból, nem konkrét megvalósítást. A felsorolásod nagy része megvalósítással kapcsolatos dolgokat említett, keverve a funkcionalitással. Mi másképp valósítottuk meg, de attól még ugyanaz a funkcionalitás (layout, slot (nevesített slotok is), blokk, komponens, escapelés: elég jól látszik a párhuzam). Nem hiszem el, hogy ez nem tökéletesen érthető, néha már azt hiszem, hogy direkt csinálod.


Üdv,
Felhő
24

Nem tudom, mi a gondod, és miért vagyok hihetetlen,...

Fraki · 2008. Feb. 11. (H), 22.39
Nem tudom, mi a gondod, és miért vagyok hihetetlen, szerintem abba kéne hagynunk. Nem döntöttem el semmit. Felfogtam, hogy nem konkrét megvalósítást vettetek át (nem állítottam az ellenkezőjét).

Mondtad, hogy a symfony view rétege nagyon tetszik, és hogy ahhoz hasonló rendszert csináltatok. Arra voltam kíváncsi, hogy amit csináltatok, mennyire valóban symfony-specifikus-e (talán a „symfony-specifikus” kifejezés okozhatott zavart?). Néhány dolgot felsoroltam címszavakban, azt mondtad "ennyire nem", meg egy kicsit kifejtetted. Oké. Mi a probléma?

Szerintem az eszképelés egyáltalán nem symfony-specifikus valami, a layout sem, a blokk sem és egyebek sem. De elfogadom, ha szerinted igen. Akkor ebben megállapodhatunk nem? Ennyi. Bocs, de én kevés vagyok ahhoz a határhúzogatós (és ilyen szinten halálosan értelmetlen) filozofálgatáshoz, hogy mi honnantól funkcionalitás vagy megvalósítás.

Tehát még egyszer, nem tudom, mi a probléma, szerintem zárjuk le ezt a szálat (kezet nyújt).
7

rendszer

mudlee · 2008. Feb. 8. (P), 11.07
Ha igényes, és minőségi rendszerben szeretnél dolgozni, akkor ajánlom a PRADO keretrendszert.
Mind a templatező, mind maga a rendszer szerintem nagyon jó
8

PRADO

felyx · 2008. Feb. 8. (P), 23.57
Biztos nagyon hasznos, de ez a program is mindenre a kezembe akarja adni a megoldást, én inkább szeretném megírni magamnak amit csak tudok. Neked is köszönöm mindenesetre a tippet. Egyébként én csak template engine azaz sablon kezelő rendszer után érdeklődök, ez pedig egy komplett framework. Néztem a statisztikát, 100,000 sornyi kód, 500 class, borzasztó sok olyan dolog van bene amit sosem használnék, így szerintem energiaforrás pazarlás lenne.
9

Kiproba

zmb · 2008. Feb. 9. (Szo), 10.24
Azert erdemes kiprobalni a fent emlitett eszkozoket. Meg mas eszkozoket is. Kicsit jatszol veluk, megismersz mindenfele megoldast, ezek utan mar jobban ossze tudsz rakni magadnak egy olyan alapot, ami megfelel neked.
10

Egyetértek.

felyx · 2008. Feb. 9. (Szo), 14.47
Egyetértek és ezt is teszem egyébként, ezért köszönöm is ezeket a tippeket, mert hasznosak.
12

template

mudlee · 2008. Feb. 9. (Szo), 23.37
Magamnak megirni...
Ezzel sokáig én is így voltam, de rájöttem hogy egyedül nem feltétlen írhatok jobb kódot, mint több ember együttvéve:)
Ha csak sima template enginet keresel, akkor azok közül a smarty a "legjobb", és azért idézőjelben, mert sajnos egy szint felett rengeteg korlátot támaszt.
Viszont viszonylag gyors, kicsi, és 1óra alatt mindent meglehet tanulni vele kapcsolatban.

Ha viszont template kezelőt is saját magad akarsz irni, hajrá... :)
13

A lényeg :)

felyx · 2008. Feb. 10. (V), 00.46
Épp az a lényeg, hogy ezek a dolgok többet tudnak mint kellene (számomra), Max Logan sablon rendszere borzasztó jó alapot adott, az alapján készítettem egy sajátot. Nekem bőven elég ha eljuttatja a kiírandó információkat a tpl fájlhoz, mást nem is kell tudnia mert a többire a php maga is képes...Ezen felül még külön megírni a megjelenítéshez mindenféle egyéb rendszert én feleslegesnek tartok. Persze később kiderülhet hogy tévedtem, még én is nézelődök, tesztelgetek, de 59 sor és még nem vettem észre problémát vagy hiányosságot eddig. Majd meglátom...Biztos hogy nem tökéletes és másnak valószínűleg nem lenne elég, de az igényeim egyenlőre kielégíti. Egyébként nem mindig azért ír meg valamit az ember saját maga mert esetleg jobbat tud írni, egyszerűen csak azért mert meg akarja érteni, ki akarja próbálni vagy csak jobb érzés ha olyat használ amit sajátkezűleg készített.
15

Template Attribute Language

hector · 2008. Feb. 10. (V), 03.52
Én egy ideje rákattantam a Zope féle TAL rendszer PHP-ra portolt változatára, a PHPTAL-ra: http://phptal.motion-twin.com/
Kicsit kötöttebb, mint például a Smarty, de eddig még sikerült minden szituációt megoldanom vele. Meg vigyázni kell az XML szintaktikára, mert arra érzékeny (XML parsert használ template feldolgozás során). Alapban nem tud sok mindent, de bővíthető :)
16

Nem rossz

zmb · 2008. Feb. 10. (V), 11.50
Hmmm, elsore egesz pofas a dolog. Es mit lehet tudni a sebessegerol? Mennyivel gyorsabb/lassabb mint egy smarty, vagy mint egy html-php egyveled? Memohasznalatrol van valami info?
17

passz

hector · 2008. Feb. 10. (V), 14.40
Az a helyzet, hogy nem végeztem vele méréseket (igazándiból nem is tudom, hogy hogyan kéne hozzákezdeni). De ez is, mint a Smarty, PHP/HTML kódot készít fordítás után, és addig azt használja, amíg meg nem változtatod a template-et. Nekem az tetszett meg benne, hogy nincs külön kódblokk a nyelvnek, illetve a slotok és makrók használata átláthatóbbá tette számomra a kódot.