ugrás a tartalomhoz

Template engine

Max Logan · 2007. Jún. 21. (Cs), 14.23
Volt egy topic ahol szóba kerültek a tempalte engine-ek. Ott írtam, hogy én egy sima egyfüggvényes engine-t használok. A céljaimnak megfelel.

A topicban PP felvetette, hogy a megoldásommal, hogyan oldom meg a működési logika és a megjelenítés szétválasztását.

A kérdésen agyalva rájöttem, hogy valójában nálam nincsen külön megjelenítési réteg, csak egy .tpl file, amiben a megadott helyen kicserélek értékeket. Tehát nálam a template csak HTML és CSS kódot tartalmaz.

A Smarty-s példák alapján egyértelművé vált számomra, hogy ott a template-ben van "programkód", ami a template engine saját syntaxisával van leírva. Ez azt jelenti, hogy adott esetben egy menü kiírásához szükséges adatokat megkapja a működési logikától a tpl engine és majd ő megoldja a megjelenítést.

Ezt végiggondolva úgy gondolom, hogy bár a Smarty ilyen működés mellett valóban megjelenítési réteget képez, felesleges művelet zajlik.

Egy menü kiírásához ugye a PHP összeszedi az infókat, majd átadja pl. egy tömb formájában. Ez eddig egy ciklus. A smarty fogja az adatokat és lefuttat egy másik ciklust, ami valójában létrehozza a megjelenítendő kódot.

Sztem ez itt erőforráspazarlás, mert két ciklus oldja meg azt amit eggyel PHP szinten meg lehet oldani.

Ha számításba vesszük azt, hogy nem smarty-t használunk, hanem a .tpl-be PHP kódot teszünk, akkor is ott vagyunk, hogy két ciklus fut le (és a tpl máris kódot tartalmaz).

Tehát megítélésem szerint a template engine-ek ilyen működése erőforrás pazarló. Most azt nem nézem, hogy pl. a smarty képes cache-elni.

Az én egyfüggvényes template megoldásomban a lényeg a PHP és HTML kód szétválasztása volt. Tehát, hogy ne ötmillió echo szerepeljen a kódban, és ha már egyszer külön van a tényleges kódtól, akkor egyszerűsödik az új kinézet kialakítása (kinézetváltás). (Egy menü összeállítása nálam egy függvénnyel van megoldva, ami egy .tpl file-t tölt fel adatokkal, majd ezzel a kész template részlettel tér vissza (kész html kód). A visszatérési értéket pedig hozzácsapom az index.tpl-hez és már kész is az oldal.)
‹ Programozási módszerek PHP proxy forrás ›
 ■
1

MVC

PraiSe · 2007. Jún. 21. (Cs), 14.57
Üdv,

a lényeg nem azon van, hogy a template-ben ne legyen PHP/egyéb programozási kód. Hanem azon, hogy azok a funkcionalitások, amik ahhoz szükségesek, hogy az oldal végső kimenetét megkapd, azok teljes mértékben külön legyenek választva azoktól, melyek az adatokat összegyyűjtik, és átadják a template engine-nek. Valójában ennek az a lényege, hogy külön képes legyél azonos adatokból felépíteni egy XML-t, egy RSS-t, egy WAP oldalt, egy böngésző által megjelenített oldalt, sőt, akár még azt is szabályozd, hogy milyen CSS-ek kerüljenek bele az oldalba, mert elképzelhető, hogy más CSS szolgál ki egy nyomtatandó tartalmat, mint egy weboldalon megjelenőt. Ergo képes vagy meghatározni a programodban, hogy adott feltételek együttállása esetén milyen megjelenítést kapjon az az adat, amit te összegyűjtöttél.
Ez az egyik lényeges eleme az MVC (Model-View-Controller) szétválasztásnak.
3

Így már más ...

Max Logan · 2007. Jún. 21. (Cs), 15.29
... a leányzó fekvése. De még most sem világos, hogy miért a sablonnak kell a megjelenítési logikát tartalmazni? Miért nem jó megoldás az, ha van egy függvény PHP-ben, ami ugyanazt végzi mint amit a T.E. tehát létrehozza a kimenetet. Ha itt létrehozunk egy függvényt, ami előállítja az adatokat, majd egy tömbbel visszatér, ezt a tömbböt átadjuk pl. a create_Post, create_PostRSS függvénynek, akkor az eredmény ugyanaz lesz és megvalósítottuk a működési logika és a megjelenítés szétválasztását. Bár ebben az esetben is fennál, hogy két ciklus fut le. Ezt igazából mérésekkel lehetne egy kész rendszeren tesztelni, hogy mennyivel több erőforrást használ fel a külön megjelenítési réteges megoldás, mint ahol egy ciklusban szedjük össze az adatokat és hozzuk létre a kimenetet (és célszerűen egy forgalmas oldalnál lenne ez látványos, vagy nem lenne érzékelhető a különbség).
2

egyensúly

Joó Ádám · 2007. Jún. 21. (Cs), 15.26
A programozás mindig egyensúlyozás a programozó és a felhasználó kényelme között. Ha fénysebes weboldalakat akarsz, minimális erőforrás igénnyel, akkor nekiülhetsz assemblyben leprogramozni, csak nem lesz túl hatékony...
A programkódot el lehet választani a HTML sablontól, én pl. egy olyan motorban gondolkodom, ami a különálló HTML sablont DOM függvényekkel dolgozza fel.
De maga a PHP kód is elhelyezhető a sablonban: megfelelően használva ugyanolyan átlátható, a validator is megeszi, és kifejezetten erőforrás hatékony.
4

Kód a sablonban

Max Logan · 2007. Jún. 21. (Cs), 15.32
Nemtom, nekem az a meggyőződésem, hogy a sablon az sablon, abban ne legyen programkód. A működési logika és a megjelenítési réteg szétválasztása (mint az előző kommentben írtam) pusztán PHP szinten megoldható. Nem látok indokot arra, hogy a sablon tartalmazza a megjelenítési réteg funkcióit.
5

erőforrások

Joó Ádám · 2007. Jún. 21. (Cs), 15.47
Pedig fentebb épp az erőforrások kímélése mellett kardoskodsz. A sablonba helyezett PHP kódnál nincs erőforrás kimélőbb megoldás a problémára.
8

Erőforrások ...

Max Logan · 2007. Jún. 21. (Cs), 16.53
Jelenleg én nem választom szét a megjelenítési réteget a működési logikától, tehát nekem csak egy ciklusom van.

A komment lényege pontosan az, hogy a szétválasztást tisztán PHP szinten meg lehet oldani, hogy a sablon az tényleg csak sablon legyen, ami nem tartalmaz programkódot.
19

erőforrás

hector · 2007. Jún. 22. (P), 13.11
Ez valójában a smarty-nál is így működik. A template file-t csak egyszer futtatja át az értelmezőn, akkor készül belőle egy php file, amit letárol a templates_c könyvtárba, és onnantól kezdve azt használja (mindaddig, amíg nem módosítod a template-et).
7

Sablonban a kód

szaky · 2007. Jún. 21. (Cs), 16.04
Sajna az nem kikerülhető, hogy mégha nem is php, de valamilyen "programozás szerű" nyelvi elemek megjelenjenek atemplétben. Mert különben egy egyszerű listát sem tudsz megjeleníteni
9

Lista

Max Logan · 2007. Jún. 21. (Cs), 16.53
Miért nem tudok egy listát megjeleníteni?
6

XML bigtime...

janoszen · 2007. Jún. 21. (Cs), 15.55
Én mostanában kezdtem erőteljesen érdeklődni az XML technológiák iránt. Azért tetszenek nagyon, mert gyakorlatilag szabványos megoldást jelentenek az ilyen problémákra. (Templatezésre pl. az XSLT) Sajnos nem tudok minden technológiát alkalmazni, mert az XSQL és XQuery messze túl gyenge az igényekhez képest, úgyhogy ott kénytelen vagyok saját magam alkotni, de a lényeg még mindig az, hogy egy XML adathalmazt kapok és az transzformálódik át HTML-lé az XSLT-vel. Elméletben, egyelőre. Majd nemsokára gyakorlatban is, reményeim szerint.
10

kényelem...

csla · 2007. Jún. 21. (Cs), 18.04
Lehet, lehet, de legalább ennyire fontos a kényelmes, rugalmas, gyors fejlesztés. Én is egyszer eltöltöttem több időt a saját kis template rendszerem elkészítésével, de most már csak annyiból áll egy lista kiírása, hogy egy függvénynek átadom egy SQL query eredménytömbjét.
És ehhez a template-ben:

<table>
  {%szamlaTetel:
  <tr>
    <td>
      %1
    </td>
    <td>
      %2
    </td>
    <td>
      %4
    </td>
    <td>
      %3
    </td>
    <td>
      %[%5|money]
    </td>
    <td>
      %6%
    </td>
    <td>
      %[%4 * %5|money]
    </td>
  </tr>  
  %}
</table>
És mint látszik az adatfeldolgozó PHP réteg csak visszaadja a nyers adatot, és a template-ben megadott helyekre behelyettesítésre kerülnek, ott megadható formátumban (pl. pénz), illetve még műveleteket is el tud végezni. Pl. itt a 4-es az mennyiség, az 5-ös az egységár, és a végén megadja az árat. Így ha kéne mondjuk még akármilyen más adatot megjeleníteni, amit ki lehet számolni ezekből, akkor a módosításhoz hozzá se kell nyúlni a programhoz, csak a template-be beírok. Vagyis egy kód a PHP oldalon, és bármennyi megjelenés, sőt, felhasználónként lehetnek tetszőleges adatok és megjelenések úgy, hogy a PHP kódon mit sem kell változtatni. Ez azért szerintem nem rossz dolog... :)
11

kákán csomót

pp · 2007. Jún. 21. (Cs), 18.22
Mondjuk nem kell feltétlenül tömböket átadni, át lehet adni az eredmény tábla azonosítóját is, és el lehet fedni a smink elől ezeket. Tehát csak egy ciklus lesz és az a sminkben, vagy a smink motorban.

Nem az a baj, hogy a smink/template kódot tartalmaz, hanem az, hogy milyen logikát megvalósító kódot tartalmaz. Ha megjelenítésit akkor rendben van, ha működésit akkor nincs rendben.

A Te megoldásoddal hogyan oldod meg, hogy egy listát kiírassál? ott ugye két ul között vannak az li elemek, amiket csak egy ciklussal tudsz oda tenni. Ha nincs egy elem sem, akkor az ul se kell. Ez megjelenítési logika, ezt a sablonba kell beletenni. De lehet nem így csinálja meg a "dizájner" mert neki az tetszik, hogy "* listaelem\n" mert egy email tartalmát állítja össze, vagy egy mobilra optimalizált minimál változatot készít. Ekkor nem kell az ul, meg a vizsgálat sem, de ezt ő nem tudja megcsinálni, mert ő ugye csak a html-t izélhet, vagyis a template-t. Ergo nélküled nem tud dolgozni.

Amennyiben egyedül dolgozol, sose fogod megérteni miért jó szétválasztani a dolgokat ;)
12

Re

Max Logan · 2007. Jún. 21. (Cs), 18.38
Nem az a baj, hogy a smink/template kódot tartalmaz, hanem az, hogy milyen logikát megvalósító kódot tartalmaz. Ha megjelenítésit akkor rendben van, ha működésit akkor nincs rendben.

Ok, de miért a sablon tartalmazza a logikát, amikor ezt megtehetem PHP-ben egy create_Menu függvényen belül? A megjelenítés ekkor is el van különítve és a sablon tiszta marad.

A Te megoldásoddal hogyan oldod meg, hogy egy listát kiírassál? ott ugye két ul között vannak az li elemek, amiket csak egy ciklussal tudsz oda tenni. Ha nincs egy elem sem, akkor az ul se kell.

Ezt a logikát, ha MVC-ben gondolkodunk, akkor nem a sablonba teszem, hanem a create_List függvénybe. Ha nincsen adat, akkor vagy nem teszek ki semmit vagy kiiratom, hogy nincsen "vmi" (vmi helyett az aktuális lista elemtípust írom ki).

Ez megjelenítési logika, ezt a sablonba kell beletenni. De lehet nem így csinálja meg a "dizájner" mert neki az tetszik, hogy "* listaelem\n" mert egy email tartalmát állítja össze, vagy egy mobilra optimalizált minimál változatot készít.

Ezt nem igazán értem. Ha lista, akkor UL és LI és nem variál a designer. Ha másfajta lista kell, akkor meg create_Type01_List, create_Type02_List függvények és kész.

Amennyiben egyedül dolgozol, sose fogod megérteni miért jó szétválasztani a dolgokat ;)

Valóban, egyedül dolgozom. De mint írtam nekem az egész template-ezés azért volt fontos, hogy a kódban csak a program logika legyen és ne legyen egy modulban 5 millió echo, amivel a HTML-t kiíratom (az már csak pozitív mellékhatás, hogy ezáltal könnyű új kinézetet gyártani).
13

Próba

janoszen · 2007. Jún. 21. (Cs), 19.38
Próbálj meg úgy dolgozni, mintha két ember lennél. Tudom, skizofrénül hangzik, de próbáld meg. Egyik munkamenetben Te vagy a sitebuilder, akinek nem sok hozzászólása van a PHP-hez, a másikban meg a PHP programozó, aki a HTML kódhoz nem nyúl túlzottan hozzá. Dolgozz egy órás osztással és akkor nagyon hamar rájösz, hogy hol érdemes optimalizálni. :)
14

Hm

Max Logan · 2007. Jún. 21. (Cs), 20.46
Ha két ember szemszögéből nézem és azt mondom, hogy PHP programozó csak az adatok előállításáért felel, nem foglalkozik a megjelenítéssel, a sitebuilder mondja meg, hogy mi hol jelenjen meg, akkor értem, hogy miért kell a megjelenítési algoritmusokat a template-be tenni.

Lehet, hogy az egész logika azért nem volt nekem tiszta, mert én a sitebuilder alatt a grafikai tervből HTML és CSS kódot előállító user-t értettem (ha megvan a template (1 db HTML + CSS), akkor a PHP programozó már úgy szabdalja magának ahogyan akarja a saját megjelenítési logikája szerint - legalábbis bennem ez a kép élt).

Viszont még mindig tartom azt, hogy egyszemélyes project esetében számomra átláthatóbb, ha a megjelenítési logikát egy PHP függvényre bízom.

Ezzel úgy gondolom, hogy el lehet érni azt, hogy pl. egy blogmotor esetében olyan ember is tudjon template-et gyártani a blog-hoz aki nem beszélni a template engine nyelvét (vagy pusztán egy skin miatt nem akarja megtanulni az adott site sablon motorjának a syntaxisát). Tehát ha kihagy egy {valami} jelölést (vagy elírja), akkor max. nem jelenik meg pl. a post dátuma, de nem vágja haza a site-ot, ha rosszul ír egy foreach szerkezetet.

Ps.: A topic-ot azért índítottam, mert nem értettem, hogy miért mondja mindenki, hogy már pedig így kell. Sajnos ha az ember autodidakta módon tanul, akkor kellenek az ilyen "veszekedések", hogy megértsen dolgokat (mert sok esetben megtudja, hogy mit hogyan kellene, csak a miért marad el - én meg olyan ember vagyok, hogy mindenben a miért érdekel, érteni akarom, hogy vmit miért úgy csinálok ahogy).
15

Is is

ada · 2007. Jún. 21. (Cs), 21.24
Egyet is értek, meg nem is.

Ha egyszemélyes projectet csinálsz, akkor is nagyon megéri külön szedni, már csak azért is mert átláthatóbb, egységesebb, később is jobban kiigazodsz rajta, nem beszélve arról mi van ha más kezébe kerül a forrás, esetleg többen fogják (veled v. nélküled) szerkeszteni a későbbiekben.

A template enginek szintaxisáról annyit, hogy pont ezért nem szeretem a Smartyt, mert meg kell tanulni külön. Jobban szeretem az olyan template engine megoldásokat, amik a php-t használják. Apró példa:

<?php foreach ($termekek as $termek): ?>
Termék ID-je: <?php print $termek['id']; ?><br>
Termék neve: <?php print $termek['nev']; ?>
<?php endforeach; ?>
Ajánlom a következő olvasmányt: Template Engines

És kiemenélném a lényegét az írásnak:
In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.
16

Mindjárt más

Max Logan · 2007. Jún. 21. (Cs), 21.31
In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.

Na igen, így már mindjárt más, nekam annó a HTML és a PHP szétválasztás volt a lényeg és ezért jártam rossz úton ...
18

van ilyen

amonrpg · 2007. Jún. 22. (P), 06.49
Van olyan, ami megfelel az igényeidnek! :) Én is használom.
http://sourceforge.net/project/showfiles.php?group_id=41542

Úgy hívják, hogy php_templates. Ez egy C-ben írt template-kezelő PHP modul. Megfordítja a Smarty logikát, amivel valódi MVC-hűséget ér el. Átteszi a vezérlést a template-fájlból a V modulba. Ugyanis ha jól belegondolsz a template-nek nem szabadna azzal foglalkoznia, hogy _hány_ sort is kaptál a DB-ből. Azzal sem szabadna foglalkoznia, hogy éppen meg kell-e jeleníteni egy adott frag-et. Mert mindez a V modul feladata, és nem a template-fájlé.
Nézz bele a példaprogramba, szerintem érdemes.

Igaz, hogy nagyon régen nem nyúltak hozzá a cucchoz, de szerintem igazán nem is igényli. Én személy szerint egyetlen bugot találtam benne, de azt könnyű kicselezni. Ha úgy parse-olsz fel egy template-t, hogy nincs benne semmilyen változás, akkor nem adja vissza az eredeti, változatlan template-forrást, hanem egy false-szal jelzi, hogy nem volt mit csinálnia. De mondom, ezt egy pici workaround-dal meg lehet oldani.

Én csak javasolni tudom, veszett gyors. Amióta ezt használtam, minden szerver-tulajnak sírok, hogy tegye fel, mert ezt én szeretném. :D Aztán amikor nem sikerül, akkor csinálok egy db. osztályt a template-kezeléshez, és megoldom PHP-val a template-zést. A smarty-t és a hasonló cuccokat már el is felejtettem. Csak ha muszáj.

Ez volt itt a reklám helye. :D
20

Most akkor mi van?

Max Logan · 2007. Jún. 25. (H), 23.18
Megfordítja a Smarty logikát, amivel valódi MVC-hűséget ér el. Átteszi a vezérlést a template-fájlból a V modulba. Ugyanis ha jól belegondolsz a template-nek nem szabadna azzal foglalkoznia, hogy _hány_ sort is kaptál a DB-ből. Azzal sem szabadna foglalkoznia, hogy éppen meg kell-e jeleníteni egy adott frag-et. Mert mindez a V modul feladata, és nem a template-fájlé.

Hm, ezek szerint, akkor nem is jártam rossz úton?
21

szerintem(!) nem

amonrpg · 2007. Jún. 26. (K), 07.18
mivel az én logikám szerint a template nem kód kéne, hogy legyen, hanem adat. Az említett php_templatesben ez teljesül is. Mondok egy példát. Csinálsz mondjuk egy fórum motort, ami skinezhető. Mi történik? Csinálsz hozzá N skint. Aztán elkezdik használni. Felmerül az igény, hogy több skin is legyen hozzá. Két lehetőség van, vagy te készíted el, és akkor olyan lesz, amilyennek kell, vagy boldog-boldogtalan turkálhat a kódban. Mert a skin PHP-val vagy Smarty-val, az kód. Nem adat. Ellenben ha a szoftver V modulja járja le a kódbeli köröket, és a template valóban csak a megjelenítés _hogyan_ját szolgálja, és nem a vezérlését, máris nyugodt szívvel mondhatod, hogy nesze, az csinál hozzá template-t, aki nem szégyell. Egyszerűen nem képes tönkrevágni a kódot, mivel nem is fér hozzá. A template adattá válik, amin műveletet végzel. Ráadásul ilyen szempontból a php_templates tök jó, majdnem ugyanúgy be lehet konfigolni, mint a smarty-t (tag-ek), de ugyanezzel a huszárvágással be lehet állítani, hogy dreamweaver template-kompatibilis legyen. Azt hiszem nem kell taglalni ennek a hasznosságát. :D (S ez volt itt a reklám helye... :p )
22

Sztem is

Max Logan · 2007. Jún. 26. (K), 08.32
Ellenben ha a szoftver V modulja járja le a kódbeli köröket, és a template valóban csak a megjelenítés _hogyan_ját szolgálja, és nem a vezérlését, máris nyugodt szívvel mondhatod, hogy nesze, az csinál hozzá template-t, aki nem szégyell.

Akkor úgy látom, hogy egyezik a véleményünk template kérdésben :-)
23

nem a PHP, HTML szétválasztása a cél

Hodicska Gergely · 2007. Jún. 26. (K), 10.20
Ugyanis ha jól belegondolsz a template-nek nem szabadna azzal foglalkoznia, hogy _hány_ sort is kaptál a DB-ből.
Ez mennyiben zavarná meg az MVC logikát?

Azzal sem szabadna foglalkoznia, hogy éppen meg kell-e jeleníteni egy adott frag-et.
A frag nem tudom, hogy pontosan mit jelent, gondolom egy kisebb template részlet. Az ténylegesen nem jó, ha ilyen logikát kever az ember a templatekbe, és az agyon van ifezgetve. Nyilván ezt is ésszel és érzékkel kell csinálni.

Mert mindez a V modul feladata, és nem a template-fájlé.
Na szerintem pontosan itt van a nem jó szemléletmód. Nem V modul vagy template, a template az a V modul szerves része.

Ahogy említették is többen, nem a kódot kell szétválasztanod a HTML-től, hanem az üzleti logikát a megjelenítési rétegtől. Ez a cucc pontosan itt hibádzik, de legalábbis maximálisan erre tereli a használót (megnéznék pár konkrét használati esetet).


Üdv,
Felhő
24

Szerintem is elhibázott a szemléletmód

Nagy Gusztáv · 2007. Jún. 26. (K), 12.19
Persze bizonyos értelemben magánügy, hogy ki mire és hogyan használja a sablonozást.
Szerintem egy nagyon jó forrás magyarul a PHP fejlesztés felsőfokon.
25

második kiadás

Hodicska Gergely · 2007. Jún. 27. (Sze), 15.38
Ha már előkerült: http://www.amazon.co.uk/Advanced-PHP-Programming-Large-scale-Applications/dp/0672329239/. Kb. egy fél éve vártam már, hogy megjelenjen. :)


Üdv,
Felhő
26

még mindig nem érted...

amonrpg · 2007. Jún. 28. (Cs), 07.14
Ezt a vitát már szerintem jó két éve folytatjuk. :D

Szóval szerintem a template egyértelműen adat, szerinted meg kód.
Ennyi a különbség.
S amennyiben feltételezed, hogy valóban adat, már értetővé válik, miért is írtam azt, amit.

Ha te kódként értelmezed azt az adatot, amely definiálja az oldal megjelenésének hogyanját, akkor természetesen nem gáz, hogy a V modulhoz simán hozzácsapod a template fájlokat is.

De mondom, szerintem éppen, hogy adatot nevezünk ki kóddá, csak hogy használhassuk a smartyt. Ami szerintem nem oké. :D Meg aztán nagyban függ attól, hogy mire és miként használjuk a template-t.

Az én példámban nem is szabad másként, csak és kizárólag adatként nézni a template-re, ami ellenőrzésre szorulhat, nem tudhatod, mi érkezik benne. Senki sem szeretne ellenőrizhetetlen, ellenőrizetlen kódrészletet a szoftvere kellős közepén, ami mindezek tetejében a megjelenítésért felelős.

Egy átlag vállalati projektben mindegy, miként kezeled a template-t, mert ált. csak egy template készül, az is házon belül, kicsi az esélye az ellenőrizetlen kódnak a template-ben.
27

Szerintem Te nem érted

pp · 2007. Jún. 28. (Cs), 07.54
Itt arról van szó, hogy a működési logikát szétvállasztjuk a megjelenítési logikától. Azt a logikát, hogy "az aktuális oldalra mutató link kicsit máshogyan nézzen ki" nem tudjuk szétválasztani úgy a működési logikától, hogy a template-ben - mely a megjelenítési logika - nem használhatnánk valamilyen kódot, amivel a megfelelő döntést, ergo a logika feldolgozását hajtanánk végre. Az, hogy Te ezt a template engine-be/sablon motor/sminkelő gép kódjába teszed vagy magába a templét fájlba tök mindegy a cél szempontjából. Mi a műkodési logika(kód)/(megjelenítési logika)template szétválasztásáról Te a template engine/template fájl szétválasztásáról beszélsz. Nyílván való a megfelelő feladathoz a megfelelő template engine-t kell választani általános megoldást nem lehet rá mondani, mert akkor mindenki azt használná, és nem menne itt a vita arról melyik a király.
28

vagy mégis? ;)

Hodicska Gergely · 2007. Jún. 28. (Cs), 10.30
Ezt a vitát már szerintem jó két éve folytatjuk. :D
Hát ja, csak szerintem nem ott csúszik el a dolog, hogy én nem értem ezen módszert, hanem hogy nem teljesen tiszta az elgondolásod az MVC-ről.

Szóval szerintem a template egyértelműen adat, szerinted meg kód. Ennyi a különbség. S amennyiben feltételezed, hogy valóban adat, már értetővé válik, miért is írtam azt, amit.
Ezzel nem is lenne gond (szerintem nem szerencsés megoldás, de ez lényegtelen), csak akkor ne hivatkozz az MVC-re. Mert te ezzel a kialakítással pontosan ezt sérted meg, a az M-be keversz bele V beli dolgokat.

Senki sem szeretne ellenőrizhetetlen, ellenőrizetlen kódrészletet a szoftvere kellős közepén, ami mindezek tetejében a megjelenítésért felelős.
Azért remélem érzed, hogy ez erős eltúlzása/kiforgatása a Smartynak.

Egy átlag vállalati projektben mindegy, miként kezeled a template-t, mert ált. csak egy template készül, az is házon belül, kicsi az esélye az ellenőrizetlen kódnak a template-ben.
Egy csapatnál szerintem nem is lenne használható ez a módszer már csak olyan szempontból se, hogy iszonyatosan összeköti a sitebuildert a fejlesztővel, egy csomó tisztán sitebuilder melót ezentúl csak úgy tudnak megcsinálni, hogy kérni kell a programozó segítségét is. Van egy listád sorban 10 elemmel. Szeretnéd ezt megváltoztatni, hogy 2x5-ben jelenjen meg: máris kell a fejlesztő.


Üdv,
Felhő
29

ez így túl általános

Fraki · 2007. Jún. 28. (Cs), 19.08
A kód-adat párossal egy kicsit túlegyszerűsíted a dolgot, bár a lényeg benne van.

A template az üzleti logikához képest tényleg adat, viszont nem úszod meg, hogy a template-ed vezérlési struktúrákat is tartalmazzon. A vezérlési struktúra pedig igencsak kódszagú valami. Amit persze lehet absztrahálni és adatosítani; pont erről szól a smarty.

(BTW 1. Valaki fentebb írta, hogy már a smartynak már a nevétől is undorodik. Kezet fogok vele.)

(BTW 2. Úgy látom, a sablonozó rendszerek használatánál magasabb szintű dolog a keretrendszer-használat, ui. ezek bírják a sablonozók képességeit, ugyanakkor (azokkal szemben) egyértelmű a hasznuk. Ez alatt azt értem, hogy a sablonrendszerek hasznát általában véve vitatják (nincs értelme csak a szigor és a fent említett adatosítási absztrakció kedvéért külön sablonozóréteget használni, pláne ilyen ronda nevűt). Viszont a keretrendszereknek magasabb a tanulási görbéje is. Ez nagy átlagban sokat számít, a fejlesztői közösség nehezebben mozdul rájuk. Ahogy itt néhány hónapja követgetem a weblabor álláshirdetéseit, úgy vettem észre (lehet, hogy tévedek), hogy a smarty terjed. Ebből én azt olvasom ki, hogy a közösség az első szintet (sablonozók) meg-meglépi, de a keretrendszerek (vagy az egy de facto szabvány keretrendszer) ideje még nem jött el.)
30

nincs defacto PHP framework

Hodicska Gergely · 2007. Jún. 28. (Cs), 23.40
úgy vettem észre (lehet, hogy tévedek), hogy a smarty terjed.
Ez szerintem annyiban nem igaz csak, hogy nem terjed, hanem a Smarty már nagyon régen kb. a de facto PHP template rendszer, azért is szokott ez előfordulni az állás hirdetésekben. És annyit azért érdemes róla tudni, hogy amikor megjelent, akkor igencsak innovatív megoldások voltak benne (lefordítja a templatet stb.), plusz eléggé jól kitalált valami, ha megnézzük, akkor lassan már nagyon régóta nem kellett hozzányúlni, nagyritkán valami apróbb bugfix szokott kijönni. És hát részben az az ember csinálta, aki most a PHP6 meghatározó alakja, és aki látta bármely prezentációját, akkor tudhatja, hogy ritka jó koponya, ja és pl. a preg_ függvényeket is neki köszönhetjük.

a közösség az első szintet (sablonozók) meg-meglépi, de a keretrendszerek (vagy az egy de facto szabvány keretrendszer) ideje még nem jött el.)
Hát itt egy gondolat, hogy a közösség azért az elég tág fogalom, hisz PHP oldalon rengeteg a kezdő/hobbi programozó. Akik komolyan csinálják, azok körében azért elég sokan csinálnak/használnak valamilyen keretrendszert. Az hogy ez pl. állás hirdetésekben kevésbé mutatkozik meg, az azért lehet, mert nincs de facto keretrendszer, a legtöbb cég esetében saját fejlesztésű cuccokat használnak. Eleve ha valaki kicsit is komolyabban szeretne céges környezetben ebből megélni, akkor nem engedheti meg magának, hogy ne legyen valamilyen frameworkje. 1-2 olyan komoly rendszert láttam, ami mögött teljesen egyedi rendszert állt, amúgy minden cégnél volt valamilyen framework, ahol eddig dolgoztam. Plusz nekem diploma munkám is egy saját MVC alapú framework volt, emiatt annó körbenéztem, és már akkor (bőven PHP4 időkban) volt vagy majd 100 PHP keretrendszer, ezek között jó pár egészen komoly. A többségük különböző JAVA keretrendszerek portolása volt, de volt egy csomó valamilyen szinten egyedi elképzelés, de az szinte általában elmondható volt, hogy a legtöbb szerzője az más nyelven tanult meg programozni. Aztán most meg rengeteg PHP5 alapú framework jött ki, ezek között is legalább vagy 10 igencsak erős van (sok RoR klón, de van .NET-re hajazó is), plusz ott a ZF, ami talán válhat majd de facto cuccá, főleg, hogy gondolom előbb-utóbb lesz hozzá komoly PDT támogatás is. Mondjuk nem tudom, hogy komoly teljesítmény igények esetén mit tud teljesíteni, de majd kiderül.


Üdv,
Felhő
31

Kérdések

Fraki · 2007. Jún. 29. (P), 01.28
azért is szokott ez előfordulni az állás hirdetésekben.


Azt tudom, csak én úgy vettem észre, mintha mostanában egyre többször fordulna elő az álláshirdetésekben (lehet, rosszul érzem, nemrég óta vagyok itt).

Az hogy ez pl. állás hirdetésekben kevésbé mutatkozik meg, az azért lehet, mert nincs de facto keretrendszer, a legtöbb cég esetében saját fejlesztésű cuccokat használnak. Eleve ha valaki kicsit is komolyabban szeretne céges környezetben ebből megélni, akkor nem engedheti meg magának, hogy ne legyen valamilyen frameworkje.


Arra van valamilyen magyarázatod, hogy ezek a cégek miért találják fel újra a kereket?

Én az első és egyetlen cégemnél dolgozom, viszont egy komolyabb projektnél időhiány miatt bevontunk külsősöket félúton. Olyan ígérettel jöttek, hogy saját CMS-ük van, meg kiforrott, kész megoldásaik. Akkora szívás volt, hogy nem igaz. Semmilyen CMS-ük nem volt, holott azt hiszik most is, hogy van, csapnivaló programozók úgy általában, és utólag minden kódsorukat ki kellett dobni (spagettikód), újra kellett írni az egészet. Mikor még ismerkedéskor kérdeztem őket, miért nem meglévő CMS-t használnak, pl. drupalt, miért sajátot, a válasz az volt, hogy "próbáljak csak meg drupallal dolgozni, majd meglátom, miért".

Akkor nem voltam döntési helyzetben, de azóta megpróbáltam drupallal dolgozni, és tényleg rájöttem, miért (saját "CMS"-t (haha) használnak): mert a drupalhoz (meg az új dolgokhoz, meg a tanuláshoz) kevesek. Hú, erről most nagyon sokat tudnék regélni.

Nem akarok általánosítani, de nekem a "saját frameworkök" meg "saját CMS-ek"-ről azóta kb. ez jut eszembe. Persze nem beszélek a nagy cégekről, nincs tapasztalatom.


amúgy minden cégnél volt valamilyen framework, ahol eddig dolgoztam.


Framework vagy CMS? Tudom, hogy lényegtelennek hangzik, de erre kíváncsi vagyok.


És visszatérve a smarty álláshirdetésekre: ezek a cégek smartyval együttműködő frameworköt használnak? Minek? A frameworköknek (és CMS-eknek is) saját sablonozó metodikájuk szokott lenni. Akkor ezeknek a cégeknek minek smarty?

S még egy kérdés: minek teszik az álláshirdetésbe a smarty-kritériumot, mikor ennek a tanulási görbéje gyakorlatilag kb. egy nap? A keretrendszerüket meg jól elhallgatják...
32

válasz, vagy valami olyasmi :)

Hodicska Gergely · 2007. Jún. 29. (P), 04.36
Arra van valamilyen magyarázatod, hogy ezek a cégek miért találják fel újra a kereket?
Hát talán a legfontosabb tényező az lehet, hogy PHP esetén nem igazán vannak "best practice" megoldások. Pl. JAVA esetén szerintem nem nagyon jut eszébe az embernek saját ilyen jellegű eszközöket írni, van pár jól bevált lehetőség. PHP esetén rengeteg framework van, sok esetben nem kevés időt kéne rászáni, hogy kiválaszák a megfelelőt, ehhez még hozzájön a betanulás ideje is. És sok helyen valszeg ennek elkerülése érdekében vágnak bele saját megoldások fejlesztésbe, amit aztán folyamatosan csiszolgatnak. Ezenkívül mindig lehetnek olyan speciálisabb igények, amelyeket nem könnyű egy kész rendszeren átverni, vagy nagyon kéne ismerni, ami viszont nincs meg akkor, amikor az ember kutakodni kezd egy lehetséges megoldás után. Ráadásul viszonylag kész komponensekből nem is olyan sok idő alatt össze lehet hozni egész jó cuccokat oly módon, hogy tartalmazhat valami olyan specialitást, amit az adott cégre, vagy annak munkamódszerére, vagy ügyfélkörére jellemző. Ha megnézed egy Symfony is alapvetően kész dolgok megfelelő társítása.

Nem akarok általánosítani, de nekem a "saját frameworkök" meg "saját CMS-ek"-ről azóta kb. ez jut eszembe.
Küldtem egy szerintem jót. ;)

Framework vagy CMS? Tudom, hogy lényegtelennek hangzik, de erre kíváncsi vagyok.
Hát első melóhelyen sajátot használtam, de csak mert kéznél volt diplomamunka kapcsán. Az egy általános fejlesztést segítő framework volt, elég erőteljes form kezelés támogatással, ezáltal elég ideális volt admin felületek gyors előállításához. Következő melóhelyen kezdetben inkább csak egy CMS szerűség volt, ami sikerült megreformálni, meg kialakítani egy framework kezdeményt, azóta ahogy én tudom egy nagyon szép rendszert hoztak össze. Következő helyen egy olyan rendszer volt, ami kódgenerálásra épült, és sok mindent szépen klikkelgetve lehet megcsinálni a segítségével. A mostani helyen meg általában "cél PHP-k vannak", mostanában próbálunk meg bizonyos framework jellegű megoldásokat bevezetni, csak a terhelés miatt csínyján kel bánni ezekkel.

És visszatérve a smarty álláshirdetésekre: ezek a cégek smartyval együttműködő frameworköt használnak? Minek? A frameworköknek (és CMS-eknek is) saját sablonozó metodikájuk szokott lenni. Akkor ezeknek a cégeknek minek smarty?
Itt szerintem pár dolgot összemosol. Egyrészt a hirdető cégeknek nem biztos, hogy van frameworkjük. Másrészt szétbontanám a CMS, framework-öt. Egy CMS, hogy ha templatezhető, akkor ha jól van kialakítva, meg kéne tudja engedje, hogy lehessen hozzá illeszteni tetszőleges template kezelőt, de itt ez nem hangsúlyos. Egy framework esetén viszont szerintem rég rossz, ha nem lehet hozzá külső template kezelőt illeszteni, hacsak nincs benne valamilyen speciális elem (komponensek, eseményvezérelt). Azon cégek, meg akik saját rendszert raktak össze, többnyire smartyt használnak, bár láttam/hallottam több XML/XSLT alapú template megvalósításról is. Szóval bőven lehet létjogosultsága az álláshírdetésben a smartynak.


Üdv,
Felhő
33

Smarty, CMS-ek, frameworkök...

Fraki · 2007. Jún. 29. (P), 10.57
Egy framework esetén viszont szerintem rég rossz, ha nem lehet hozzá külső template kezelőt illeszteni


Az én tájékozódási horizontom előterében a Drupal és a RoR és társai vannak. A Drupalban lehet Smartyt használni, de nem preferált, nem hiszem, hogy egy Drupalra ráálló fejlesztő közösség huzamosabb ideig magával vonszolná a Smartyt. RoR & tsai ügyében elsősorban a CakePHP jön szóba, ahhoz is lehet Smartyt használni, de minek...

Hozzánk nemrég jött egy srác Smarty háttérrel, magának eldolgozgathat vele, de cégen belül nem fog elterjedni, mert én a CakePHP felé vettem az irányt. (A CakePHP-t meg ugródeszkának használom a RoR és/vagy a Django felé.) No és nem meglepő módon saját admin modullal érkezett, amit szívesen "eladna" nekünk (haha). Ezzel nem bántani akarom őt, de ez akkor is kerékújrafeltalálás. Egyrészt már online CRUD-generátorok is vannak az interneten, úgyhogy még letölteni sem kell hozzá semmit, másrészt a keretrendszer épp arra jó, hogy a különálló feladatokat (sablonozás, admin-felület stb.) egy keretbe összefogja.

De sokat számít, amit mondasz, a kutatási költség. Új keretrendszer kiszemelése, tájékozódás, tanulás. Nyilván így alakulnak ki a saját megoldások, hogy mindenkinek folyamatosan termelnie kell, és a szükség hozza ezeket. Ezért aztán a kis tanulási görbéjű dolgok becsúsznak a közhasználatba, mint pl. a Smarty, a nagyobbak helyett pedig a szükség hozta sajátmegoldások.

Nekem szerencsém van ilyen szempontból, mert volt lehetőségem a Cake-kel foglalkozni (de mondjuk ki is követeltem magamnak). De nagy a felelősség, mert éles projekthez van betanulva, nincs kecmec; ezt hívják hazardírozásnak.

Ez előtt meg persze a saját metodológia, saját libek... Smartyt elismertem mindig is, de helyette csakazértis az XSLT-t választottam volna, csak ez meg úgy tűnik, kifejezetten XML-technológián alapuló környezethez testhezálló, és a Cake MVC-modelljében tárgytalan. Ettől függetlenül az XSLT számomra nagyon szimpatikus, és előnye, hogy szabvány.

Ezenkívül mindig lehetnek olyan speciálisabb igények, amelyeket nem könnyű egy kész rendszeren átverni, vagy nagyon kéne ismerni, ami viszont nincs meg akkor, amikor az ember kutakodni kezd egy lehetséges megoldás után.


No pont itt érdemes szétválasztani szerintem a CMS-t és a frameworköt. A drupalos tapasztalatom ui. a következő volt: megismertem egy szimpatikus, okosan felépített, jó supportot adó rendszert és a közösségét, de leálltam vele, mert rájöttem, hogy programozó volnék, és jobban szeretek programozni, mint összekattintgatott rendszereket hackelni; ill. az általad írt probléma merült fel. Megtetszett a Drupal, szeretnék is még vele foglalkozni, de az irány most a RoR-féle társaság. Ezek ui. frameworkök, és úgy látom, hogy az említett veszélytől mentesek.
34

framework - saját templatekezelő

Hodicska Gergely · 2007. Jún. 29. (P), 12.52
RoR & tsai ügyében elsősorban a CakePHP jön szóba, ahhoz is lehet Smartyt használni, de minek...
Pl. mert az alap CakePHP templatek esetén előjön az összes probléma, amit már korábban felhoztunk az ellen, hogy sima PHP fájl legyen egy template. Nem tudom, hogy milyen szisztémában fejlesztetek, de érzésem szerint nincs külön kifejezett sitebuilder, programozók csinálják a templateket. Ha ez nem így lenne, akkor szerintem jobban belátnád, hogy miért jó egy Smarty jellegű template kezelő.

Mellesleg az alap HTML helper segítségével összepakolni egy oldalt koncepció nekem igencsak nem tetszik. Nyilván komolyabb építőkockák előállítása az hasznos, de egy img taget $html->img() hívással kódból való kipakolását nem igazán érzem hasznosnak.

Nekem szerencsém van ilyen szempontból, mert volt lehetőségem a Cake-kel foglalkozni (de mondjuk ki is követeltem magamnak). De nagy a felelősség, mert éles projekthez van betanulva, nincs kecmec; ezt hívják hazardírozásnak.
Azért a Cake-kel nagyot bukni nem lehet, max elsőre nem a legoptimálisabb megoldást sikerül összehozni.

de helyette csakazértis az XSLT-t választottam volna,
Én bevallom, még konkrétan sose használtam ilyen rendszert, de abban szinte biztos, vagyok, hogy teljesítmény szempontjából gyengébb kell legyen, és pl. nálunk ez is komoly szempont.

csak ez meg úgy tűnik, kifejezetten XML-technológián alapuló környezethez testhezálló, és a Cake MVC-modelljében tárgytalan.
Nem látom be, hogy az XML az miért ütközne az MVC szemléletmóddal, látam is így működő rendszert (csak pont amikor én beszálltam volna, akkor lett hozzá smarty illesztés is :)). Látatlanba mernék fogadni, hogy minimális kódolással (saját Model és View származtatása) megoldható ez a Cake-kel is, és valszeg egy átlagos terhelésű oldal esetén nem is jelent komoly overheadet.

No pont itt érdemes szétválasztani szerintem a CMS-t és a frameworköt.
A speciális igények nem feltétlenül CMS jellegűek, hanem nem szokványos funkciók támogatása framework szinten. Egy példa (már szerintem volt itt): adott egy admin melyenk funkciói (kb. adott GET/POST kérések) egy-egy osztály adott metódusára képződnek le. Nem cél a hackelés eleni védekezés, de a saját belső hibák elleni védelemként azt találtuk ki, hogy a metódusok előtti DocBlock kommentek alapján a Controller osztály automatikusan ellenőrzi a bejövő adatokat, és csak akkor hívja meg a metódust, hogy ha az ellenőrzés sikeres volt.


Üdv,
Felhő
35

template, framework stb.

Fraki · 2007. Jún. 29. (P), 15.59
de egy img taget $html->img() hívással kódból való kipakolását nem igazán érzem hasznosnak.


Nem vagy rákényszerítve ezekre. Hogy milyen mértékben vonod be a helpereket a projektbe, rajtad
múlik. Mindenesetre az biztos, hogy a helperek koncepciója valamit brilliánsan megragad a
webfejlesztés metodikájából.

(kicsit off, de ilyen részleteknél már a nyelv maga is belejátszik a képbe, és én fenntartom egy
másik topikban tett állításomat -amire jól megkaptam a magamét-, hogy ez az egész MVC-sdi egyszerűen
nem illik a php-ra. Szebben néz ki a rails rubyban, mint php-ban. Pl. rossz nézni ezt a '$this->'
dzsungelt.)


Nem látom be, hogy az XML az miért ütközne az MVC szemléletmóddal


Nem azt mondtam, hogy ütközik, hanem azt, hogy tárgytalan. A probléma, amit
megoldana, meg van oldva.

[quote]hogy a metódusok elotti DocBlock kommentek alapján a Controller osztály automatikusan ellenorzi a bejövo adatokat, és csak akkor hívja meg a metódust, hogy ha az ellenorzés sikeres volt.[quote]

Amennyit ebből értek (vhol 40% és 80% között), az alapján a Cake az ilyesmire pont fel van készítve
és kb. pont így (beforeFilter és a többi Controller callback meg az egész security komponens), azaz
0 overhead.
36

nem értem

Hodicska Gergely · 2007. Jún. 29. (P), 17.36
hogy ez az egész MVC-sdi egyszerűen nem illik a php-ra. Szebben néz ki a rails rubyban, mint php-ban. Pl. rossz nézni ezt a '$this->' dzsungelt.
Mi köze van ennek az MVC-hez, komolyan nem értem.

Nem azt mondtam, hogy ütközik, hanem azt, hogy tárgytalan. A probléma, amit megoldana, meg van oldva.
Ez a kijelentés számomra szintén rejtély. Kb. ha összerakom az állításokat, akkor ez jön ki: "a probléma, amit az XML megoldana, azt már az MVC megoldja". Kíváncsi lennék, hogy ez alatt mit szerettél volna érteni.

Amennyit ebből értek (vhol 40% és 80% között), az alapján a Cake az ilyesmire pont fel van készítve és kb. pont így (beforeFilter és a többi Controller callback meg az egész security komponens),
Nem hiszem, hogy annotationből dolgozna a CakePHP, aminek pl. a vázolt esetben kettő jelentősége volt, dokumentálva lett a függvény, és ez még plusz haszonnal is járt.

azaz 0 overhead.
Az overhead alatt én teljesítménybeli overheadet értettem, nem pedig fejlesztési időt. Semmi sincs ingyen. ;)


Üdv,
Felhő
37

re: nem értem

Fraki · 2007. Jún. 29. (P), 19.42
Mi köze van ennek az MVC-hez, komolyan nem értem.


Mármint a php-nak? Sajnos nem sok, szerintem se. (Itt azért kiragadtál egy mondatot a szálból.)

Kb. ha összerakom az állításokat, akkor ez jön ki: "a probléma, amit az XML megoldana, azt már az MVC megoldja"


Nem az XML, hanem az XSLT (arról volt szó).

Nem hiszem, hogy annotationből dolgozna a CakePHP, aminek pl. a vázolt esetben kettő jelentősége volt, dokumentálva lett a függvény, és ez még plusz haszonnal is járt.


Ez egy elég egyedi megoldás. A docblockokat felhasználni validációra, nem tudom mennyire jó ötlet...
38

hmm, így nem jutunk előbbre

Hodicska Gergely · 2007. Jún. 29. (P), 20.10
Mármint a php-nak? Sajnos nem sok, szerintem se. (Itt azért kiragadtál egy mondatot a szálból.)
Miért kiragadás, az off részre reagáltam. És a "nem sok" az nem túl informatív válasz. Továbbra sem tisztázott, hogy egy nyelv OOP megvalósításának mi köze van az MVC modelhez. Szerintem nem sok, hisz ez alapvetően szemléletmód.

Nem az XML, hanem az XSLT (arról volt szó).
Oké, akkor: "a probléma, amit az XSLT megoldana, azt már az MVC megoldja". Ennek mi a jelentése?

Ez egy elég egyedi megoldás. A docblockokat felhasználni validációra, nem tudom mennyire jó ötlet...
A konkrét megoldás lényegében mindegy, csak egy példa volt arra, hogy sokféle spéci igény lehet. Amúgy meg szerintem egy elég eredeti ötlet volt, és az élet azt igazolta, hogy elég jól használható is.


Üdv,
Felhő
39

re: így nem jutunk előbbre

Fraki · 2007. Jún. 29. (P), 20.51
Továbbra sem tisztázott, hogy egy nyelv OOP megvalósításának mi köze van az MVC modelhez. Szerintem nem sok, hisz ez alapvetően szemléletmód.


Amint írtam,
Szebben néz ki a rails rubyban, mint php-ban. Pl. rossz nézni ezt a '$this->' dzsungelt.


Régi nyelv a php, nehézkes és verbóz. Az MVC meg egy modern dolog. Ilyen egyszerű. (Ez bizonyos mértékig szubjektív, már amennyiben minősítek, de a szintaxis azért összevethető objektíven is.) Abban igazad van, hogy nem az MVC-ről van szó, hanem általában az OOP-szintaxisról, meg sokminden másról, ami mellett mellesleg nem tudok elmenni az MVC apropóján sem, tehát így valóban pontosabb.

"a probléma, amit az XSLT megoldana, azt már az MVC megoldja". Ennek mi a jelentése?


Hát az, ami oda van írva. Milyen problémát old meg az XSLT? Az egy adatkimenethez többféle nézetkimenetét. (Egy xml, több view - rss, html stb.) Ezt a problémát oldja meg az MVC. Egy controller, több view (meg layout). A sablonozásról beszélünk.


A konkrét megoldás lényegében mindegy, csak egy példa volt arra, hogy sokféle spéci igény lehet. Amúgy meg szerintem egy elég eredeti ötlet volt, és az élet azt igazolta, hogy elég jól használható is.


A konkrét megoldás létjogosultságát nem is vitatom, azt viszont nem látom be, hogy ez mondjuk CakePHP-ban bármilyen overheaddel járna, akár teljesítmény, akár fejlesztés. (Nem, valóban "nem dolgozik annotation"-ből a cake, dehát a php sem dolgozik annotation-ből, ezt az egyedi dolgot le kell implementálni, a docblock-ot parse-olni kell stb., és nem látom be, hogy ez az egész miért ne tudna tök függetlenül működni egy frameworktől. Ami nem a framework feladata, azt nem azzal oldod meg, ettől még a framework használata a többi common funkcióra indokolt. Épp ez a nagy különbség a framework és a cms között: az előbbitől el tudsz függetlenedni parciálisan, olyan mértékig, amennyire jól esik, míg az utóbbit hackelned kell vagy gurunak kell lenni benne. Sőt, ha nagyon beválik, megírod komponensként, és kontribútolsz, hogy úgy mondjam. Írod, hogy "nem szokványos funkciók framework-szinten". Ilyen erővel a sablonozás is framework-szint, mégsem kell lemondanod a smartyról se a frameworkben, se a cms-ben.)
40

MVC

Hodicska Gergely · 2007. Jún. 29. (P), 23.32
Régi nyelv a php, nehézkes és verbóz. Az MVC meg egy modern dolog. Ilyen egyszerű
Hát majdnem. ;) Az MVC mintát kb. 1980 környékén dolgozták ki Smalltalk GUI programozáshoz. Azt már csak csendben említem meg, hogy ez az öreg PHP két évvel fiatalabb mint a Ruby :), az más dolog, hogy ez utóbbi kicsit robosztusabb nyelv.

Milyen problémát old meg az XSLT? Az egy adatkimenethez többféle nézetkimenetét. (Egy xml, több view - rss, html stb.) Ezt a problémát oldja meg az MVC.
Azért elég erős túlzás, az MVC ennél többről szól, az XSLT az max. a V-ben használható, de nem összevethető a két dolog.

hogy ez mondjuk CakePHP-ban bármilyen overheaddel járna, akár teljesítmény, akár fejlesztés.
Valamit keversz, olvass vissza. Én az overheadet a Cake-kel kapcsolatban arra írtam, hogy egy XSLT alapú template kezelő illesztése valszeg jelentene valamennyi overheadet, de egy átlag oldal esetében ez nem számít. Az annotationt meg arra fel írtam, hogy annyi előnye van az általad említett beforeFilterhez képest, hogy nem kell kóddal definiálni, az amúgy is kötelező dokumentációból dolgozik.

és nem látom be, hogy ez az egész miért ne tudna tök függetlenül működni egy frameworktől.
Gondold át, a controller végzi a kérés mappelését egy a kérés által meghatárzott actionre. Ha szeretnél egy ilyen funkciót, akkor Neked ebbe a folyamatba kell belenyúlnod, tehát óhatatlanul is függeni fogsz a keretrendszer alap működésétől. Legjobb esetben is származtatnod kéne az alap controller osztályból, rosszabb esetben a megvalósítás ezt nem teszi lehetővé, kénytelen vagy belenyúlni kód szinten.


Üdv,
Felhő
41

MVC stb.

Fraki · 2007. Jún. 30. (Szo), 20.20
Ok, a "régi" úgy objektíve nem állja meg a helyét, akkor inkább régies. A Rubyval kapcsolatban pedig azt is érdemes megjegyezni, hogy a kutyát nem érdekelte a Rails előtt. Akkor kezdett felcsillanni a szélesebb közönség előtt, amikor a rails-szel karöltve mint a forradalmian új webfejlesztői platformként mutatkozott be. És mit tesz isten, ebben a forradalmian-újságban van is valami. Azt hiszem, az MVC-vel mint már-már webdev buzzworddel is hasonló a helyzet. Tehát az alapok tényleg régóta léteznek, a felfedezettségük viszont új.

Most kezd rájönni a webfejlesztői társadalom, hogy a ruby és a python, amelyek nem elsősorban webre lettek tervezve, hanem általános használatra, a webre éppolyan jól használhatók, ha nem jobban, mint a spec webes nyelvnek kikiáltott php.


Azért elég erős túlzás, az MVC ennél többről szól


Így van, épp ezért oldja meg azt a problémát, amit az XSLT kezel. A sablonozásról beszélünk. A sablonozás pedig nem más, mint az üzleti és a megjelenítési logika szétválasztása. Ezt a képességet pedig az MVC inherensen hordozza. És tény, hogy még több ennél.

de nem összevethető a két dolog.


Nem is vetettem össze. Csak azt mondtam, hogy egy MVC-frameworkben az XSLT tárgytalan. A mobil és az mp3 lejátszó sem összevethető dolog, mégis az előbbi birtokában mondható, hogy az utóbbi tárgytalan, mert a mobil már tudja azt, amit az mp3 lejátszó. Ha van egy mobilom, ami lejátszik mp3-at (vegyük úgy, h ma már mind játszik le), akkor nem fogok külön mp3-lejátszót venni mellé (hacsak nem vagyok mac rajongó).

Én az overheadet a Cake-kel kapcsolatban arra írtam, hogy egy XSLT alapú template kezelő illesztése valszeg jelentene valamennyi overheadet


Ok, eredetileg tényleg nem a megoldásotokra írtad az overheadet, de megjegyzem, hogy itt alátámasztod a fenti állításomat: bármilyen külső sablonozó csak overhead egy MVC-frameworkben, mert egy MVC-framework már egyben sablonozó is. (És mint írtam, az XSLT kifejezetten XML-környezetben vethető be igazán hatékonyan, s én pl. nem szigorúan XML-ben gondolkodom. Ha egy XML-geekkel kerülnék össze, akkor jönne szóba valszeg az XSLT.)

Annotation:

Eredetileg ez a dolog úgy jött elő, mint egy a százféle spéci igény közül. Nem világos számomra, hogy ez a megoldás kinek az igénye. Az ügyfélé? Rendelt egy frameworköt, és kikötötte, hogy docblockból kell tudnia validálni? Nem is nagyon tudom elképzelni, hogy ez hogy működik; írtatok hozzá egy php-parsert? Merthogy előbb nyilván a docblokk-kommenteket ki kell szűrni. És miért ne tudnátok egy controllerben ezt megtenni? Parse-olható az a fájl is, amiben a controller-osztály épp fut.
(De nekem ez hackelésnek tűnik, s kicsit fából vaskarikának is. A humán-gépi vegyes információra jól olvasható formátumokat szoktak használni, pl. a YAML-t, abból aztán olyan doc-ot lehet csinálni, amilyen tetszik.)

De nem ez a lényeg, hanem hogy ezt mint az olyan, bármikor felbukkanható spec igények kategóriájának igazolásaként adod elő, ami meggátol egy webfejlesztői közösséget abban, hogy ráálljon egy MVC-frameworkre (természetesen nyerve vele). Tudnál még ilyesfajta példákat sorolni? De olyat, ami tényleg ügyféligény, mert nekem ebből úgy tűnik, hogy ti szimplán a dokumentációs terheket csökkentettéket ily módon.
42

history

Hodicska Gergely · 2007. Jún. 30. (Szo), 23.09
Lassan tényleg jó lenne, ha visszaolvasnád a threadet. Egyre több olyan mondatot/következtetést adsz a "számba", aminek köze nincs ahhoz, mint amiket írtam. Ráadásul egy csomó (szerintem fontos) észrevételemre nem reagáltál. Így elég nehéz bármiről beszélgetni.

ebben a forradalmian-újságban van is valami
Forradalmian újnak tekinteni szerintem elég túlzás, az tény, hogy a rails iszonyúan átgondolt/kitalált valami, a DRY és a CoC nagyon jól ki vannak találva benne. De szinte nincs benne olyan elem, ami már ne létezett volna előtte is.

A Rubyval kapcsolatban pedig azt is érdemes megjegyezni, hogy a kutyát nem érdekelte a Rails előtt.
Pontosan, ebből is látszik, hogy nem önmagában a nyelv számít, hanem hogy hogyan használod. Ha most valaki csinál egy még szuperebb frameworköt PHP-hoz, akkor az lesz a király nyelv?

itt alátámasztod a fenti állításomat: bármilyen külső sablonozó csak overhead egy MVC-frameworkben, mert egy MVC-framework már egyben sablonozó is.
Eleve nincs olyan, hogy "egy MVC framework", rengeteg féle van, eltérő template kezeléssel. Ha bármelyik mondjuk nem sima PHP-t használ templatnek, akkor ha ilesztek hozzá egy PHP-t használót, akkor a végeredmény gyorsabb lesz. A "MVC-framework már egyben sablonozó" részre: nem egyben sablonozó, hanem van sablonozó komponense, ami jó esetben cserélhető.

Így van, épp ezért oldja meg azt a problémát, amit az XSLT kezel.
Próbáltam feljebb rámutatni, hogy az XSLT az max a V (persze valójában annál is kevesebb), egyszerűen a fenti állításnak nincs értelme, nem összemérhető a két dolog, ráadásul az MVC nem zárja ki önmagában, hogy ne használhatnál XSLT-t a templatek kezelésére.

Csak azt mondtam, hogy egy MVC-frameworkben az XSLT tárgytalan.
Értem, és csak ismételni tudom, hogy ennek nincs értelme. Egy csomó framework használ XSLT-t.

Eredetileg ez a dolog úgy jött elő, mint egy a százféle spéci igény közül. Nem világos számomra, hogy ez a megoldás kinek az igénye. Az ügyfélé?
Ez hogy jön ide? Nálatok az ügyfél rgaszkodik a Cake-hez? ;) Belső igény volt, leírtam korábban, hogy mi volt a cél.

Nem is nagyon tudom elképzelni, hogy ez hogy működik; írtatok hozzá egy php-parsert?
Tök egyszerű: reflection API.

És miért ne tudnátok egy controllerben ezt megtenni?
Komolyan, hol írtam én ilyet? Azt írtad, hogy ez a funkcionalitás tök független a frameworktől ("és nem látom be, hogy ez az egész miért ne tudna tök függetlenül működni egy frameworktől."), megoldható attól teljesen elkülönülve. Arra próbáltam volna rávílágítani (úgy látszik sikertelenül), hogy miért nem igaz ez az állításod.

De nem ez a lényeg, hanem hogy ezt mint az olyan, bármikor felbukkanható spec igények kategóriájának igazolásaként adod elő, ami meggátol egy webfejlesztői közösséget abban, hogy ráálljon egy MVC-frameworkre
Ez így kezd komolyan fárasztó lenni...hol a bánatban írtam én ilyet? Arról volt szó, hogy vajon a saját frameworköt használók miért döntöttek saját használata mellett. Ebben a kontextusban írtam egyik lehetséges okként, hogy létezhetnek különböző speciális igények, és írtam egy konkrét példát. Erre ebből a fenti állítást hozod ki: elég vicces.

Tudnál még ilyesfajta példákat sorolni?
A legalapvetőbb például a teljesítmény kérdésköre, de tényleg lehet elég sokféle igény. Sok esetben pl. egy CakePHP túlzás is lehet, az erősségei közül viszonylag kevés használ ki, az is rossz szemléletmód, ha egy ilyen "kalapáccsal" a kezedben mindent "szögnek" nézel. Pl. nálunk kb. alig akadna olyan lekérdezés, amit egy ORM cucc kibökne magából, használhatnánk egy ilyet, csak nem lenne semmi értelme, lenne egy sokat tudó, bonyolult és lassú cucc, ami a kézzel queryjeinket futtatná.

mert nekem ebből úgy tűnik, hogy ti szimplán a dokumentációs terheket csökkentettéket ily módon
Pont fordítva, mi a dokumentációs terheket fordítottuk a magunk javára.


Üdv,
Felhő
43

re: history

Fraki · 2007. Júl. 1. (V), 02.02
Pontosan, ebből is látszik, hogy nem önmagában a nyelv számít, hanem hogy hogyan használod. Ha most valaki csinál egy még szuperebb frameworköt PHP-hoz, akkor az lesz a király nyelv?


Az biztos, hogy jót tenne neki (nem fognak csinálni), de én ebből mást olvasok ki. Azt, hogy a php sikerében van egy adag üzleti ügyesség, és persze a célnyelvsége. De aminthogy megírták az első komolyabb webes frameworköt rubyra, vagyis gyakorlatilag bemutatkozott a webes színtéren, máris felkapta a fejét mindenki. Meg lett mutatva, hogy általános célzata mellett tökéletesen alkalmas (ha nem alkalmasabb) mindarra, mint amire a célnyelvnek kitalált php. És, milyen érdekes, fedezik felfele a pythont is a webfejlesztők. Azt a pythont, amire viszont nem mondhatjuk, hogy a kutya se használta ezelőtt. Egyszerűen az a fajta - egyébként érthető - gondolkodásmód kezd változni, hogy ha valamit a webre találnak ki, akkor arra biztos az is a legalkalmasabb, szemben az általános célzatú eszközökkel. Ez kb. olyan, mint mikor én régen azt gondoltam, hogy a sakkgépem okosabb a számítógépnél, mert csak sakkozni tud, azt viszont nyilván nagyon jól, a számítógép meg csak egy számítógép, ma viszont fordítva érzem: a számítógép inkább előnyben van a sakkgéppel szemben azzal, hogy általában többet tud (most eltekintve a hardverháttértől, elvben).

Eleve nincs olyan, hogy "egy MVC framework", rengeteg féle van, eltérő template kezeléssel.


Az ilyen természetes nyelvi konstrukciót úgy hívják, hogy határozatlan főnévi csoport, amit többek közt generikus értelemben is szoktak használni, nem ritkaság. De a félreértések elkerülése érdekében visszaolvastam a szálat, és ezt találtam magamtól mondani: "csak ez meg úgy tűnik, kifejezetten XML-technológián alapuló környezethez testhezálló, és a Cake MVC-modelljében tárgytalan."

nem összemérhető a két dolog


Próbáltam fentebb rámutatni, hogy nem is mértem össze.

ráadásul az MVC nem zárja ki önmagában, hogy ne használhatnál XSLT-t a templatek kezelésére.


Nem is mondtam, hogy a Cake kizárja az XSLT használatát, azt mondtam, hogy tárgytalan.

Értem, és csak ismételni tudom, hogy ennek nincs értelme. Egy csomó framework használ XSLT-t.


Visszaolvasva a szálat, azt találtam, hogy eredetileg a Cake-ről beszéltem, az meg nem. (Elismerem, bár hidegen hagy, hogy a Pustefix meg a Cocoon frameworkök XSLT-t használnak, de egyikre sincs kedvem rákattintani.)

Ez hogy jön ide? Nálatok az ügyfél rgaszkodik a Cake-hez? ;) Belső igény volt, leírtam korábban, hogy mi volt a cél.


Bevallom, nem értem teljesen a "belső igény" fogalmát. Van az ügyfél, annak vannak igényei, nekem meg vannak rá megoldásaim.

Tök egyszerű: reflection API.


Kösz!!

Komolyan, hol írtam én ilyet?


Milyet? (Én egy kérdést tettem fel.)

Arra próbáltam volna rávílágítani (úgy látszik sikertelenül), hogy miért nem igaz ez az állításod.


Tény, hogy nem értem, pl. egy Cake-controllerből miért ne lehetne reflection API-val docblockból kinyerni a validálási információkat.

Ez így kezd komolyan fárasztó lenni...hol a bánatban írtam én ilyet? Arról volt szó, hogy vajon a saját frameworköt használók miért döntöttek saját használata mellett. Ebben a kontextusban írtam egyik lehetséges okként, hogy létezhetnek különböző speciális igények, és írtam egy konkrét példát. Erre ebből a fenti állítást hozod ki: elég vicces.


No, itt ezt tényleg félreértettem. Én, mint írtam, ügyféligényre gondoltam, nem jutott eszembe, hogy ilyesfajta "belső igényről" van szó. Ez tiszta, ebben kezet foghatunk: hogyha a fejlesztő valamit kifejezetten _úgy_ szeretne megoldani, ahogy egyik másik már létező framework sem teszi, akkor új utakra lép. Az ínyencek csiszolgassák a maguk gépezetét, úgyis ebből születnek aztán a közös értékek. De azért kérdés, hogy vagyok-e olyan erős, hogy emiatt megéri-e, és tényleg valami eredetivel állok-e elő. Én úgy látom, hogy a saját utak járása az esetek túlnyomó többségében a kerékújrafeltalálás betegségének tünete, és csak egy kis részben a zseniké. Sőt, minél tájékozottabb lesz valaki, annál inkább belátja, hogy a saját megoldásai csak kerékújrafeltalálások -- ebben viszont van némi paradoxon, mert új megoldások mindig is születnek, és mindig is lesz rájuk szükség. De elég sokat mernék rá tenni, hogy a saját megoldásokat kitermelő cégek 99%-ának "belső igényei" egycsapásra megszűnnének, ha lenne elég energiájuk kutatni és tájékozódni a fejlesztés mellett. A maradék 1% pedig termeli a valóban eredeti új ötleteket.

Sok esetben pl. egy CakePHP túlzás is lehet


Érdekes, nekem meg kifejezetten lightweight-nek tűnik. Nem gondolom, hogy ágyúval verébre tudna lenni.

Pl. nálunk kb. alig akadna olyan lekérdezés, amit egy ORM cucc kibökne magából


Az azért látszik ezeken a frameworkökön (mint mondtam, tájékozódási horizontomon a RoR, Django és Cake van), hogy az ORM-mel diszkréten bánnak, mert a lekérdezések megkötésével könnyen használhatatlanná tudnának válni. Ennek megfelelően nem egy nagy wasistdas akár a következetes kézzel queryzés sem. És akkor minek neked még mindig ez a framework? Hát a többi szolgáltatása miatt. Ha sajátot írsz, csak bele fogsz csempészni Te is valamilyen ORM-et, mert az jó. Mert a következő projekthez jól jön. (A framework arra van ugye, hogy különböző-féle projektekhez használjuk.) Én nemrég egy hokiszájthoz készítettem viszonylag bonyolult és teljesítménykritikus statisztikamodult, és utólag úgy látom, hogy ez a modul külsősként vígan megfért volna a szájt frameworkje mellett (mármint ha egyáltalán lett volna hozzá framework, mint ahogy nem). A szájtok meg a modelljei működésének (főleg az admin) egy jó nagy hányadára nagyon jól illeszkedik az ORM.
44

általánosítás

Hodicska Gergely · 2007. Júl. 1. (V), 03.11
Az ovodás részt most kihagyom, hogy pontosan ki-mit mondott, bárki visszaolvashat majd.

De elég sokat mernék rá tenni, hogy a saját megoldásokat kitermelő cégek 99%-ának "belső igényei" egycsapásra megszűnnének, ha lenne elég energiájuk kutatni és tájékozódni a fejlesztés mellett.
Majd olvasd ezt vissza mondjuk egy 5 év múlva, eldöntheted, hogy mennyire volt ez túlzó. Főleg akkor lehet majd érdekes, ha megjártál pár munkahelyet, több nagyobb projektet.

Érdekes, nekem meg kifejezetten lightweight-nek tűnik. Nem gondolom, hogy ágyúval verébre tudna lenni.
Nincsenek általánosan jó megoldások, mindig az adott szitu határozza meg, hogy mi fér bele, mi nem. Adott esetben (nálunk pl. adott), kb. kevesebb kódból megvan egy oldal kiszolgálása, mint egy Hello World a Cake-ben (majd lehet, hogy nézek is valami tesztet). Vagy pl. vannak olyan kódok, amik csúcsidőben szerverenként, másodpercenként 1000 kérést szolgálnak ki, nem fér bele egy ilyen framework.

Ha sajátot írsz, csak bele fogsz csempészni Te is valamilyen ORM-et, mert az jó.
Lehet, hogy jó általában, csak nem mindig, azért meg nem éri meg használni valamit, mert van. Pl. teszteltük: 9000 sor lekérése és végigiterálása esetén egy ADODB 400%-kal lassabb, mint a natív mysql/mysqli/pdo. Tök jó az ADODB is, csak így kapásból kiesett. Annó teszteltem Propel-t, EZPDO-t, egyik sem remekelt ilyen téren. Szóval mindent a maga helyén.


Üdv,
Felhő

u.i.: az a baj (pl. Proclubbal/Vbencével is emiatt van SZVSZ a legtöbb vitám), hogy szerintem elég kevés projekten dolgoztatok, és ebből vontok le eléggé általános következtetéseket.
45

re: általánosítás

Fraki · 2007. Júl. 1. (V), 11.53
bárki visszaolvashat majd.


(alkalomadtán még téged is beleértve)

Majd olvasd ezt vissza mondjuk egy 5 év múlva, eldöntheted, hogy mennyire volt ez túlzó.


Ok.

Nincsenek általánosan jó megoldások, mindig az adott szitu határozza meg, hogy mi fér bele, mi nem.


Ez az érvelés egy olyan vitában volna helytálló, ami arról szól, hogy framework vagy nem framework. Csak ez a vita tudtommal nem erről szól, hanem arról, hogy saját framework vagy nem saját framework. De a saját frameworköt is azért írja az ember, hogy a következő projektben is felhasználja, nem pedig azért, hogy, mondván nincsenek jó általános megoldások, majd írunk ahhoz is egy frameworköt.

kb. kevesebb kódból megvan egy oldal kiszolgálása, mint egy Hello World a Cake-ben


Nem a kód mennyisége a fontos, hanem a fejlesztési idő.

Vagy pl. vannak olyan kódok, amik csúcsidőben szerverenként, másodpercenként 1000 kérést szolgálnak ki, nem fér bele egy ilyen framework.


Igen, az lehetséges, hogy nem ugyanolyan volumenű projektekben gondolkozunk, a teljesítményre vonatkozó érveiddel nem tudok vitatkozni, tehát OK (bár szerintem ez is inkább egy framework-nem framework vitában volna érv, mintsem ebben).

ui. Az ad hominem érveid előtt meghajlok (komolyan).
47

tankönyv

Hodicska Gergely · 2007. Júl. 1. (V), 15.17
(alkalomadtán még téged is beleértve)
Megtettem mindvégig.

De a saját frameworköt is azért írja az ember, hogy a következő projektben is felhasználja,
Na ez tipikusan az utóiratban említett eset. Te ezt élted meg, lehet, hogy egy tankönyvben is ez találod, nekem meg munka tapasztalatom van, ami ezzel ellentmond. Egy nagyobb fejlesztés során simán előfordul, hogy menet közben eszközöket is gyárt az ember, mert így éri meg. Az említett eset meg pl. volt egy délutáni kis tervezgetés, majd reggelre kész is volt, adott esetben nehezebb lett volna ennél hatékonyabb megoldást találni.

Nem a kód mennyisége a fontos, hanem a fejlesztési idő.
Ez is nagy igazság (szép, steril, tankönyvi mondat, amúgy általában igaz is), csak megint azt tudom Neked mondani, hogy én meg per pillanat olyan környezetben dolgozom, ahol teljesen más szempontok uralkodnak, és nem számít a fejlesztési idő (kis túlzással persze), csak az a fontos, hogy a szolgáltatás folyamatosan működjön.

Mekkora volt a legnagyobb látogatottságú oldal, amit fejlesztettél?

(bár szerintem ez is inkább egy framework-nem framework vitában volna érv, mintsem ebben).
Elmondom, hogy miért nem így van. Van egy frameworknek egy olyan alapvető tulajdonsága is, miszerint egységes megoldásokat (design patterneket) kényszerít/nyújt, és ez nagyon fontos ahhoz, hogy pl. egy csapat jól/egységesen tudjon dolgozni egy projekten. És már csak emiatt is érdemes valamilyen szintű frameworkot használni, akár úgy, hogy a fejlesztés csak bizonyos részeit fedi le az ember valamilyen általános megoldással. Egy másik fontos szempont a biztonság kérdése, amire sajnos a legtöbb fejlesztő nem helyez hangsúlyt, ezért ilyen szempontból is érdemes bizonyos műveleteket lefedni, amelyek biztosítják, hogy egy fejlesztő ne tudjon hibázni (vagy legalábbis nehezítsük meg neki). Viszont az érme másik oldala, hogy teljesítmény szempntjából nem fér bele, egy ful framework használata, azért az ember kompromisszumokra kényszerül.

És akkor pl. egy konkrét eset: az örökölt kódokban a DB kezelő kódok szanaszét voltak az oldalak kódjában, függvényekben, egy csomó minden több helyen volt megoldva minimális különbséggel, néha nem is leghatékonyabban, mert x fejlesztő nem tudott egy y fájlban lévő, már létező függvényről. Szerettem volna valamilyen külön rétegbe kiemelni a DB kódokat, de pl. egy ful absztrakciós réteg nem fért bele, ORM cucc pláne, ezért döntöttünk saját mellett. Megnéztük, hogy hogyan használunk DB kezelést: lekérünk egy sort, lekérünk több sort és végig iterálunk, illetve sok esetben cachelünk (amire lett végül egy általános megoldás, de nem volt túl szép). Kis méréssel kijött, hogy a PDO teljesen jó sebességben, kicsit többet memóriát fogyaszt, és önmagában megoldja az első két pontot. Ami érdekes volt, hogy legyen az SQL injection kizárva, ezt szintén a PDO hozta magával (prepared statement). Az cache-elést meg sikerült nagyon szépen egy kis trükkel beleépíteni, úgy, hogy eljesen transzparensen működik:
<?php
class PerformerDAO extends DAO
{
	protected function _getPerformerData($perfromerId)
	{
		// itt simán lekérdezés és visszatérés az adatokkal
	}
}

// Így nem cache-el, hacsak nincs default beállítva neki
$perfromerData = new PerformerDAO()->getPerformerData($_GET["performerId"]);

// Így cache-el 5 másodpercre
$perfromerData = new PerformerDAO()->getPerformerData($_GET["performerId"], DAO::_CACHE_ENABLE, 5);
?>
Kb. egy délutáni tervezgetés, másnap kész is volt a cucc (még egy kis plusz automatikus hibakezeléssel megspékelve). Ennyi munkából/időből lett egy olyan meoldásunk, mely teljes mértékben lefedi az igényeinket, segíti a fejlesztőket biztonságos kód írásában, és minimálisan van nagyobb teljesítmény igénye, mint a natív függvényeket használó megoldás. Nem hiszem, hogy találtunk volna egy ilyesmi cuccot ennyi idő alatt.


Üdv,
Felhő
17

nem feltétlenül fontos

breakline · 2007. Jún. 21. (Cs), 21.53
Én személyesen 3-4 emberrel dolgozok általában együtt, van egy projektmenedzser, van egy html-es, egy designer, pluszba akár rendszergazdák és ügyfelek, és én mint programozó.

A munka menete pedig, hogy megkapom a specifikációt, elkezdtem megtervezni az adatbázist, a különböző alacsony és magas-szintű elemeket, stb.., admin felületet (erre pl. nemigen kapok külön design-t), és mikor megjön a html, akkor kezdjük el összerakni. Út közben jön be a javítás, de, mivel okosak vagyunk :), ezért ritkán kell a html-be nyulni, elég a css-be jobb esetben, én pedig a html-t a php-val csak a megjelenő oldalakon keverem (sok include ugyan, és sok osztály tehát általában javítás is a php kódban kell), mivel a főnök nem engedi a smarty-t, sőt ha tehetjük semmi mástól származó kódot nem használunk, hiszen akár abban is lehet a hiba, bár én sokáig smarty-t használtam, és preferálom mai napig template téren.

Mivel a legritkább esetben kell a html-esnek a kódba nyulnia, mivel én rakom össze a komponenseket, és én telepítem, ezért a smarty végső esetben az én munkámat nehezíti, hiszen alapesetben is két file-ban kéne javítani, egyszer a template-ben, és mégegyszer a template-et meghívó kódban, úgyhogy egy ideje hanyagolom a smarty-t, egyedül drupalos munkákban vagyok kénytelen phptemplate-et használni. Amúgy a smarty egy kellemes megoldás, uh, nagyjából naprakész vagyok vele, de minnél nagyobb egy munka, annál inkább zavaró lesz a rengeteg template file. Akkor viszont hasznos, ha sok hasonló oldalad van, pl. a klasszikus sql lekérdezés megjelenítése táblázatban, ilyenkor egy jól megírt template életet menthet, és rengeteg időt. Ha muszáj, saját rendszert használok, de mivel ebben nincs cache-elés, csak állandó, statikus elemekre alkalmazom, pl. footer-ek, nem dinamikus menük, e-mailek (pl. regisztráció, elfelejtett jelszó), ehhez pedig nem kell smarty sem.
46

Smarty

kris7topher · 2007. Júl. 1. (V), 13.17
Éppen most dolgozok egy oldalon, ahol felmerültek olyan igények, amit Cake-kel nem tudtam volna megcsinálni (meg lehetett volna, de túl sokat kellett volna kódolni hozzá). A probléma végül is az volt, hogy bizonyos C.-k más M.-ekből építkeztek volna, saját M. nélkül, ami ugye Cake alatt hibát ad. A végleges megoldás V.-je a Smarty lett, PHP kódot nem akartam a sablonba, mert mivel egy portálról van szó, abban az esetben a skálázhatósághoz megint sokat kellett volna kódolni (egész pontosan a cache-hez). Az M. sem saját, hanem a sebesség miatti megfontolásból a beépített PDO, szerintem ami a sok M. osztállyal megoldható, az megoldható SQL nyelven is (tárolt eljárás powaa). Egyenlőre úgy néz ki, a dolog sehol sem tángálja az MVC logikát, de ugyanakkor eléggé hatékony is (overhead mondjuk a PDO obj.orientáltsága lehet talán, de a beépített függvényeket nem szeretem, a Smarty cachel, ott is hatékony lesz). Az egész csak attól függ, hogy mit és hogyan rakunk a sablonba, mert persze meg lehet úgy is írni, hogy az teljesen ellentétes legyen az MVC-vel ( {php} blokkokból mysql kérések, mondjuk) de rendesen használva ez a veszély nem igazán fenyeget.
49

Controller Model nélkül

Fraki · 2007. Júl. 2. (H), 01.21
A probléma végül is az volt, hogy bizonyos C.-k más M.-ekből építkeztek volna, saját M. nélkül, ami ugye Cake alatt hibát ad.

Cake-ben a $uses tömbbel tudod szabályozni, milyen modelleket használjon a Controller. $uses = null -ra semmit nem fog használni. Convention over Configuration.
48

WACT DataSpace

Hodicska Gergely · 2007. Júl. 1. (V), 15.58
Ha számításba vesszük azt, hogy nem smarty-t használunk, hanem a .tpl-be PHP kódot teszünk, akkor is ott vagyunk, hogy két ciklus fut le (és a tpl máris kódot tartalmaz). Tehát megítélésem szerint a template engine-ek ilyen működése erőforrás pazarló.
Erre már egyből szerettem volna reagálni (csak elkanyarodott a thread), mert van pár érdekesség ezzel kapcsolatban. Egyrészt amiről itt beszélünk, az a push modell, amikor Te tolod bele a templatbe az adatokat. Ennek az ellentéte a push modell, amikor a template komponens magának kéri el az adatkat, itt már kapásból nincs meg az a para, amit említesz (megjegyzem valami nagyon extrém eseteket leszámítva egy oldal teljesítményigényét nem nagyon befolyásolja érezhetően, hogy két ciklusod lesz).

A két dolog ötvözése pl. egy szerintem érdekes koncepció, amit a WACT használ. Ott van egy DataSpace nevű interfész, ami igazából egy asszociatív tömböt határoz meg, aminek pluszban lehet több sora, amin végig lehet iterálni. MysqlRecordSet is ezt valósítja meg, egy lekérdezés eredménye meg egy ilyet ad vissza. Utána ez kerül átadásra a templatenek, és amikor az végig iterál ezen az Objektumon, akkor azon belül az iterációkor hívódik meg tényleges a mysql_fetch. Így alapvetően push modellt használsz, de végeredményben a template pollolja az adatokat.


Üdv,
Felhő