ugrás a tartalomhoz

Melyik keretrendszert tanuljam meg?

stan · 2012. Már. 12. (H), 10.29
Elérkezett az idő, hogy végre magas szinten megtanuljak egy keretrendszerben programozni. Ha most megkérdezném tőled, hogy melyik keretrendszert válasszam, Te melyiket ajánlanád?

Milyen főbb különbségek lehetnek a keretrendszerek között, és egyáltalán milyen szempontokat kell figyelembe venni egy keretrendszer választásánál?

A nagy cégek általában milyen keretrendszert használnak php alkalmazások fejlesztésére, és mi alapján döntenek egy keretrendszer mellett?

Ha Te használsz valamilyen keretrendszert, akkor esetleg leírhatnád röviden, hogy szerinted mik az erősségei, gyengeségei, illetve ha váltottál keretrendszert, akkor azt miért tetted?
 
1

Ahogy én (gyakorlatilag

H.Z. v2 · 2012. Már. 12. (H), 10.56
Ahogy én (gyakorlatilag kívülállóként) látom: tökmindegy.
Előveszed az egyiket, ha van elég időd, pár hét alatt kapsz valami fogalmat róla, hogy mennyire áll kézre. Akkor félreteszed, elő a másikat, eljátszod ugyanezt. Esetleg ha van harmadik jelölted is, akkor azzal is. Ezek után nagyjából el tudod dönteni, hogy mi az, ami neked leginkább megfelel és azt kezded használni.
Ami hirdetést láttam, azokban többnyire előnyként és nem feltételként szerepelt x vagy y keretrendszer ismerete.
2

Framework függetlenül, amit

Kubi · 2012. Már. 12. (H), 12.58
Framework függetlenül, amit tanácsolni tudok, hogy tanuld meg a Doctrine használatát (vagy Propel, de Doctrine jobb)

Amúgy Symfony 1.4-ről tudok egy pár jó szót mondani, előnye, hogy nagyon jól lehet benne plugin-eket (sf 2-ben már boundle a neve) készíteni, azok egyes részeit felülírni anélkül, hogy az eredeti pluginhoz hozzányúlnál, ami a kód újrahasznosíthatóság miatt előnyös.

Másik nagy előnye (ami sf 2-ben még nem tökéletes, de 2.1-re azt mondják lesz már benne), az admin generátor, egy console parancs kiadásával egy adatbázis táblához legenerlálja neked az admin felületet, ahol a tábla bejegyzéseit szerkesztheted. Mindezt olyan formában, hogy nagyon könnyen és gyorsan lehet átalakítani, új funkciókat beletenni, egyes részeit megfelelő jogosultsághoz kötni.

A formok kezelésében is nagy segítséget nyújt, objektum alapú, egymásba ágyazható formok, validálás. Egy-egy form mező (widget) maga is egy objektum, egyedi igény esetén írhatsz sajátot (pl.: autocomplete mező)

Pont a moduláris felépítése miatt sok plugin létezik hozzá, sf 2-höz is már rengetek boundle készült.

symfony 1.4
symfony 2
3

Egyszerűen programozható

stan · 2012. Már. 12. (H), 13.52
Köszönöm az eddigi hozzászólásokat!

Nekem a fő szempont, hogy a keretrendszerekhez képest viszonylag gyorsan és egyszerűen lehessen létrehozni webalkalmazásokat. Azt olvastam több fórumon is, hogy egyszerűség és gyors fejlesztés szempontjából a cakePHP és CodeIgniter azok, amelyek ezt a vonalat képviselik. Azonban azt is hallottam, hogy mivel nem kötik meg túlzottan fejlesző kezét, nagyon nagy projekteknél esetleg nehézkes lehet a kód újrahasznosítás.

A másik, amit hallottam, hogy a tapasztalt profik inkább a Zend és Symphony keretrendszereket említik, mivel nagyon jó a kód újrahasznosíthatóságuk, és megkövetel bizonyos konvenciókat, tehát nehezebb bennük fejleszteni, de egy több programozós csapatban és nagyon nagy projekteknél ezek az ajánlott keretrendszerek.

Én jelenleg egyedül dolgozom egy viszonylag kicsi projekten, tehát nekem a legfontosabb először is, hogy én magam átlássam a kódot, és gyorsan, egyszerűen tudjam fejleszteni, ne legyen benne sok konvenció.

Vélemény? Ki mennyire ért egyet? Kinek mi a tapasztalata az említett keretrendszerekkel?
4

jók a konvenciók

tiku I tikaszvince · 2012. Már. 12. (H), 15.38
A keretrendszereknek - mint ahogy a név is sugallja - egy keretet kell adniuk a fejlesztőnek. A jobb keretrendszerek ezt úgy oldják meg, hogy a nagyon hasonló dolgokat megpróbálják közel azonos logika mentén megvalósítani. Számomra a "kevés konvenció" azt jelenti, hogy nincs minden tipikus problémára válasz kidolgozva a rendszerben. És ez az egyszerűség közép/hosszútávon nagyon durván képes megbosszulni magát.

A kódgenerátorokkal az alapvető problémám, hogy a kezdő ismerkedővel nagyon gyorsan elhitetik, hogy baromi gyorsan megy itt a munka, alig kell hozzányúlni. Aztán amikor egy egyszerű módosítást végig kell vinni a rengeteg gyártott osztályon és sablonon, akkor derül ki mennyire nem így van.

Mivel nem te állítottad össze azt az osztályt, sablont nincs róla egy átfogó képed, hogy ha A ponton értéket adunk egy változónak, azt B helyen milyen módon lehet majd elérni.

Ha keretrendszert szeretnél választani kb a következőket kell tisztázni:
  • Adatbázis: Milyen adatbázis réteg van a rendszer mellé csomagolva? Az neked kézre áll? Ha nem mennyire macerás egy másikra cserélni?
  • Útvonalak kezelése: Furcsán hathat, hogy egyből 2. helyen említem, de egy webalkalmazásnál rendkívül fontos lehet a "szép" URL-ek kezelése. Biztosítja a rendszer ezt? Hogyan biztosítja? Csak elfed egy-egy GET paraméter láncot (yii), vagy már eleve ilyen módon közlekedteti a paramétereket (Zend)
  • Hibák kezelése Hogyan kezeli a rendszer a hibákat? Kezdve a Notice szintűtől egész a szintaktikai hibákig. Gyűjti a hibákat? A kiváltódás helyén jeleníti meg? Naplózza a hibákat vagy a szerver hiba naplóból kell kibányászni?
  • public és app könyvtár biztonsági szempontból az egyik legfontosabb kérdés, hogy külön lehet-e (vagy inkább kell-e) venni a "public" és az alkalmazást tartalmazó könyvtárat.
  • Kód szervezés, könyvtár szerkezet: Az is egy rendkívül fontos kérdés, hogy az egyes osztályokat, sablon fájlokat milyen könyvtár szerkezetbe szervezi. Pl a yii könyvtár szerkezete egy a UNIX rendszerekre emlékeztető, az "azonos dolgok egymás mellett legyenek", "ömlesztett" elrendezést választott: controllerek egy könyvtárban, templatek egy másikban, modellek egy harmadikban). A Zend pedig egy, számomra sokkal logikusabb, a Windows-on tapasztalt logikának megfelelően, az összetartozó dolgokat egy-egy modul könyvtárba szervezi, azon belül azonban egy szigorú könyvtárszerkezetet követel meg.
  • Magick metódusok használatának mértéke: Mindenképp érdemes megvizsgálni az adott rendszer milyen mértékben épít a Magick metódusokra, különösképp a __get, __set, __call. Számomra mindenképp egy riasztó jel, ha egy-egy ősosztályban ezek deklarálva vannak.
  • Request Mindenképp vizsgáld meg, hogy az adott rendszer ad-e Request objektumot! Ad is hozzá valami funkcionalitást, vagy csak egyszerűen "összefogja" a GET/SET/POST/FILE/COOKIE/SERVER tömbböket?
  • Felhasználói adatok: Ad a rendszer egységes logika mentén felhúzott eszközt a felhasználótól kapott adatok szűrésére, validálására?
  • CSS/JavaScript Használ valamilyen JS keretrendszert? Ha nem használ ad eszközt, hogy beépítsd a választottad? Ha használ, jó a választott neked? Vagy le tudod könnyen/egyszerűen cserélni a saját választásodra? Mit kezd az inline scriptekkel? Mit kezd a külső CSS-ekkel?
  • Logolás megoldott-e? Vagy csak és kizárólag var_dump/print_r/echo a hibakereső eszköz?
6

Látom értesz hozzá

stan · 2012. Már. 12. (H), 16.08
Köszönöm a szakszerű szempontrendszert.

Tudnál konkrét példát mondani, hogy szerinted mely keretrendszer valósítja meg ezeket a legjobban?

Te milyen keretrendszer(ek)t preferálsz? Miért?
15

nézd meg mindet

tiku I tikaszvince · 2012. Már. 12. (H), 18.55
Valaki itt már leírta, hogy nézd meg mindet, mert rengeteg függ attól is, hogy neked melyik esik kézre. Vedd a szóba jöhető rendszerek kézikönyvét, és nézd át, mennyire látod át, milyen gyorsan fedezed fel a rendszert benne. A manual "tesztelésére" azt a módszert szoktam alkalmazni, hogy kitűzök egy egyszerű kis feladatot, és azt megpróbálom megoldani a dokumentációt bogarászva.

Pl.: legyen a feladat egy vendégkönyv. Semmi értelme, de nagyon jól lehet tesztelni azt, hogy hogyan kezeli a framework az űrlapokat. Hogyan lehet egy formot felépíteni, az onnan kapott adatokat validálni, beengedni az adatbázisba. Kiderül, hogy a rendszerrel mennyire lesz szívás az XSS támadások kezelése. Kiderül milyen körülményes lesz egy adatbázis utasítás végrehajtása.

Tapasztalatom a már említett Zend és Yii rendszerrel van. Zend-et kb a 0.6-os verziótól az 1.10.valameddig napi rendszerességgel használtam. Volt olyan projekt, aminek a fejlesztése az 1.1-es Zend verzió környékén fejeződött be, és komolyabb problémák nélkül folyamatosan tudtuk alatta upgrade-elni a keretrendszert. Korábban már említettem, hogy a Zend egy számomra szimpatikus modul könyvtár szerkezetet használ, ahol a beállításokon keresztül ezeket a könyvtárakat is átnevezheted, akár át is helyezheted. Igazság szerint a Zend Framework, a többi rendszerhez viszonyítva (CodeIgniter, Symfony, Yii, CakePHP, Kohana) nem is keretrendszer, inkább egy hatalmas kódkönyvtár, amiből azt használsz, amit jól esik (a keresztbe függések miatt ez sajnos nem minden esetben teljesül). A legjobb példa erre, hogy egy csomó tutorialt találhatsz a Zend_Db Propel vagy Doctrine rendszerre való cseréjére. Saját front controllert akarsz használni? Hajrá! Írd meg hozzá és használd azt. Nem tetszik a Zend_Loader és a vele szállított autoloader? Cseréld le nyugodtan! Smarty-t szeretnél használni View rétegnek? Nem feltétlen tartom jó ötletnek, de ez is megoldható.

A másik rendszer, amivel volt szerencsém közelebbről megismerkedni, az a Yii. Fogalmazzunk úgy, hogy a Zend után nem volt a legkényelmesebb rendszer. Az előbb leírt komponens cseréket egyáltalán nem olyan egyszerű megvalósítani. Azt nem merem leírni, hogy nem is lehet, mert annyira azért nem kerültünk közeli ismeretségbe. A legnagyobb problémám a Yii-vel, hogy olyan pontokon ad teljesen szabad kezet a fejlesztőnek (mondhatnánk úgy is, hogy ott engedi el a fejlesztő kezét), ahol szerintem egy jó rendszernek épp terelni kellene a jó megoldások felé. Viszont az olyan jellegű módosításoktól, mint a fentebb leírtak is nem könnyű letolni a torkán.

Az viszont tény, hogy erőforrás igényben - sajnos - a Zend messze lemarad pl a Yii mögött. Pl ez is lehet egy olyan szempont, amit mérlegelni kell egy rendszer fejlesztése előtt.
13

Adatbázis kezelés

_lacus_ · 2012. Már. 12. (H), 18.50
Van olyan keretrendszeri adatbázis csomagoló, ORM, ami mindenféle lekérdezést le tud kezelni és majdnem 100%-ban hordozható kódot lehet vele készíteni?

Én a Zend adatbázis csomagolóját használom, azzal pl. nem kezelhető a FORCE INDEX, a csoportos INSERT és az összetettebb lekérdezések sem. Tervezési okok miatt nincs benne pl a mysql specifikus REPLACE.

Így az alkalmazás lekérdezéseinek kétharmada hordozható, a többi meg kézzel összerakott. Erre meg minek az ORM, ha esetleges adatbázis motor váltáskor úgyis buherálni kell a kódot?
16

..

Greg · 2012. Már. 12. (H), 19.10
az ORM-nel szerintem nem a hordozhatosag a legfobb szempont, hanem hogy a leggyakoribb lekerdezeseket nem kell ujra es ujra megirnod. peldaul a tipikus CRUD muveletekhez.
9

Miért van rá szükséged?

Hidvégi Gábor · 2012. Már. 12. (H), 17.31
Ha van egy saját rendszered, akkor miért akarsz bevezetni egy keretrendszert?

Nemcsak előnyökkel jár egy ilyen környezet, hanem hátrányokkal is, amit sokszor "elfelejtenek" megemlíteni.
  • plusz egy réteget hoz be a szoftverbe, amit meg kell tanulni
  • az általánosan megírt kód miatt a futás lassabb lehet, mintha te készítetted volna el ugyanazt a funkciót
  • ki kell tapasztalni a hibáit, korlátait
  • az optimalizálás nehezebb, mert meg kell érteni a teljes működést
  • verzióváltáskor nagy eséllyel írhatod át a kódot, mert szoktak változtatni a függvények paraméterezésén
  • függsz egy harmadik féltől, a fejlesztést bármikor abbahagyhatják, és akkor bajban lehetsz
  • ha helyből egy keretrendszerrel kezdesz, sok folyamatot elrejthet a szemed elől, és ezeket a problémákat nem tanulod meg megoldani
Szerintem akkor éri meg velük foglalkozni, ha a feladatod nem több egy-egy egyszerű CMS összedobásánál, ahol a cél az, hogy egy általános rendszert minél hamarabb elkészíts. Amint összetettebb problémát kell megoldani, előjöhetnek a fent említett hátrányok.

A jelenlegi munkámat én is egy kliensoldali keretrendszerrel kezdtem (ExtJS), aztán az lett a vége, hogy szép lassan megszabadultam tőle. Egy példa: egy bizonyos objektum forrása ott több mint 600 sornyi volt és négy objektumhierarchián keresztül öröklődött, míg én ezt megoldottam 200 sorból, egy szinttel.
11

saját rendszer

Greg · 2012. Már. 12. (H), 17.49
A sajat rendszernek is van sok hatranya. Amikor peldaul felveszel egy programozot es be kell tanitani, nekem sokkal konnyebb oket a Yii weboldalara iranyitani, mint a sajat keretrendszer mukodeset megtanitani. Arrol nem beszelve, hogy a sajat rendszert csak te fejleszted es ez eleg sok idot elvihet. Viszont ha egy open source frameworkot hasznalsz, akkor a fejlesztesen valoszinuleg tobben is dolgoznak, igy nem csak a te idodet fogja elvenni es az igy felszabadult idot innovaciora fordithatod :).
Ezeket tapasztalatbol irom, mert a cegnel ahol dolgozom mi is evekig sajat rendszert hasznaltunk, aztan a sokadik programozo felvetele utan arra jutottunk, hogy lehet egyszerubb lenne egy open source framework-re atterni, mert sokkal konnyebb az ujoncok betanitasa es meg sokminden mas.
12

Igazad van

Hidvégi Gábor · 2012. Már. 12. (H), 18.19
A saját rendszer fejlesztése más előnyökkel és hátrányokkal jár. Mi viszont pont fordítva haladunk, az én részemről a kliensoldalon is, míg a backenden is keretrendszerről tértünk át a tisztán saját fejlesztésre.
konnyebb oket a Yii weboldalara iranyitani, mint a sajat keretrendszer mukodeset megtanitani
Ez szerintem tervezés kérdése, lehet jól és rosszul csinálni. Nálunk először rossz volt, rengeteg hibát vétettünk, de sikerült fokozatosan letisztítani a kódot, ahogy egyre több tapasztalatot szereztünk.
az igy felszabadult idot innovaciora fordithatod
szerintem saját fejlesztésnél is rengeteg időt lehet és kell is innovációra fordítani
14

..

Greg · 2012. Már. 12. (H), 18.51
az a baj hogy a sajat rendszerrel nem dolgozol ossze masokkal. ertem ezt ugy, hogy van aki peldaul nagyon jol atlatja hogyan kellene egy jo ORM-nek mukodni es vannak ehhez otletei, van aki a route-olasi megoldasokban jo, van aki a template-ekben. ezert ha tobb fejleszto osszedolgozik, akkor jo esetben mindenkinek kijon az erossege es egy jo rendszert fognak osszehozni. ez sajat rendszernel sajnos nagyon ritkan jon ossze.
ami meg nalunk a sajat rendszerrel gond volt, hogy fejleszteni kellett folyamatosan es ez bizony eroforras. a nyilt rendszernel viszont tobben fejlesztik a rendszert igy a fejlesztesre szant ido eloszlik. ha jol emlekszem Linus Torwalds mondta egyszer azt, hogy az open source azt jelenti, amikor mas elvegzi helyetted a munkat :). ugyebar a mai Linux kernel kodjanak, ha jol tudom o kb 20%-ert felelos, megis az o projectje.
szerintem a legjobb az, ha az ember valaszt olyan open source frameworkot ami kozel all hozza, es annak a fejleszteseben segitkezik, igy adva vissza a fejlesztoi kozossegnek az ingyenes eszkozert valamit.
de egyebkent mindenki azt hasznal amit szeretne. en csak a sajat tapasztalatom alapjan tudom azt irni, hogy nekem konnyebb az eletem, amiota sajat rendszerrol, open source framework-re alltunk at. foleg miota a yii githubra koltozott es igy konnyen lehet kozremukodni a fejlesztesben.
48

Mindkettőnek van előnye és

inf3rno · 2012. Már. 14. (Sze), 15.47
Mindkettőnek van előnye és hátránya. Saját keretrendszert írni több hónapos munka. Ennyi idő alatt akár több másik keretrendszer használatát is meg tudod tanulni. A keretrendszereket mások fejlesztik, nem kell foglalkoznod velük, csak használnod őket.

A problémák a keretrendszerekkel ott kezdődnek, ha felfedezel bennük valamilyen hibát, és javítani szeretnéd. Saját rendszernél ennek nagyon gyors átfutási ideje van, egy keretrendszernél viszont ehhez képest rengeteg időbe telik, míg bekerül egy javítás, és akkor az új feature-ökről ne is beszéljünk.

Szerintem olyan rendszert érdemes választani, ami könnyen módosítható, az egyes osztályok könnyen lecserélhetőek benne. Jó jel, ha sok interface-t definiál, mert az valószínűsíti, hogy cserélhetőek benne az osztályok. Megintcsak jó jel, ha rövidek az osztályok (50-100 sor), és dependency injection-t használnak. Persze az optimalizálás ronthat ezen. Megintcsak jó jel, ha vannak unit test-ek és integrációs tesztek hozzá, ezekből még akár tanulni is lehet azzal kapcsolatban, hogy mi az elvárt viselkedése az egyes osztályoknak.

Javasolni egyelőre nem tudok egy rendszert sem, mert csak átfutottam őket. Ami szimpatikus volt, az a Zend és a Symfony, de túlbonyolítottnak éreztem őket. Ez még a régebbi verzióknál volt, azóta biztosan ezek is letisztultak. Én mindenesetre elkezdtem egy saját rendszer fejlesztését, sokat tanultam belőle, pl azt, hogy ez nem öt perces feladat, szóval ha megbíztak egy projekttel, akkor egy létező rendszert használj, ne kezdj el sajátot fejleszteni. Ha nincs határozott elképzelésed, hogy mit vársz egy ilyen rendszertől, akkor bele se kezdj, mert esélytelen, hogy használható kódod lesz a végére. Egy saját rendszer így is csak hónapok után érik meg a használatra, onnantól viszont nagyon nagy előnye lesz a többi rendszerhez képest, hogy te fejleszted, kívül-belül ismered, minden gyorsan megy benne, és akkor módosítod, amikor csak akarod, ha hibát találsz, vagy valami új feature-t akarsz beletenni, sosem fog bezavarni a következő verziófrissítés... Persze ettől függetlenül én is át fogom nézni az új Zend-et és Symfony-t, mert érdekel, hogy hogyan oldották meg a problémákat, amikkel összetalálkoztam a saját rendszeremnél.
21

Ezen a fórumon szinte csak

Protezis · 2012. Már. 12. (H), 22.12
Ezen a fórumon szinte csak tőled látni ehhez hasonló, határozott hozzászólásokat. Olyanokat, amelyeket nehéz felülmúlni hülyeség terén.

Egy kérdést tegyél már fel magadnak: Egy szoftvernek jó esetben sokkal hosszabb az életciklusa, mint a fejlesztési ideje. Ha te rendelnél egy szoftvert, tényleg örülnél annak, ha csupa egyedi - többnyire szar - megoldással implementálnák azt, vagy jobb lenne, ha egy ismert, nyílt forráskódú keretrendszert használnának, amihez a jövőben esetleg más is hozzá tudna nyúlni?

Nyilván te jobbat tudtál írni, mint az ExtJS, ez nem vitás.
26

No ezt nem fogom soha megérteni...

H.Z. v2 · 2012. Már. 12. (H), 22.57
Miért kell lehülyézni a másikat, pusztán azért, mert másképp látja a világot, mint te?

Úgy őszintén: fejlesztőnek hol érdeke, hogy az általa írt programba később más is bele tudjon piszkálni, ne őt keressék meg a fejlesztési igényekkel? A megrendelő - legalábbis nagyvállalati körökben úgy tűnt, ez a helyzet - inkább ad a szoftver minőségére, mint arra, hogy később esetleg más fejlesztővel dolgozhasson tovább ugyanazon a szoftveren. (szoftver minőségén a megbízható, gyors működést, könnyű üzemeltethetőséget értem, nem a szép és olvasható kódot)

Szóval nekem úgy tűnik, amellett, hogy totál felesleges lehülyézni másokat, most még igazad sincs.
29

Nem hülyéztem le. Lehet

Protezis · 2012. Már. 12. (H), 23.15
Nem hülyéztem le.

Lehet széllel szembe hugyozni, csak nem érdemes. Kaptál te már más fejlesztőtől régi - egyedi - kódot? Ha dolgozol egy ideje, akkor biztos vagyok benne. Hányszor fogtad a fejed? Hányszor anyáztál? PHP-s körökben sajnos pont az ilyen fafejűség miatt vannak ilyenek. Nagyvállalati körökben általában nem PHP-t használnak (tekintsünk el a kisebbségtől) és tényleg szabványokat használnak. Igazi szabványokat és de facto szabványokat. Mindenesetre olyat, amiről hallottak már a déli féltekén is.

Az, hogy te összehegeszted a kódot egy általad összetákolt, nulláról megírt libraryvel, "keretrendszerrel", adtál a szarnak egy pofont. Két év múlva a megrendelő, a cég, ahol dolgozol, de még Te magad is elátkozod azt a percet, amikor nekiláttál a munkának. Ha ehhez két évnél több kell, akkor arra se vagy alkalmas, hogy felismerd a hibáid -> hagyd ott a programozást és kezdj valami másba.
35

-

H.Z. v2 · 2012. Már. 13. (K), 11.47
Ezt inkább törlöm... kicsit felkúszott a vérnyomásom... (janoszen: bocs, mindig elfelejtem, hogy itt nem csak öt percem van szerkesztésre)
32

Személyeskedés

janoszen · 2012. Már. 13. (K), 09.53
Akkor a személyeskedést itt és most befejeztük, különben ráesik a kezem a szál törlése gombra. A PHP-nak és az egyedi fejlesztésű rendszereknek megvan a maga helye, valószínűleg nem véletlenül választották a világ leglátogatottabb oldalai közül jó páran a Java és kész frameworkök helyett. Konkrétan beszéltem pár LiveJasmin fejlesztővel és egyszer ki is számoltuk, nagyságrendileg mennyi gép kellene, ha Zend frameworköt és Doctrinet használnának a rendszer alá... sok. Az egyedi, célra szabott frameworkök ilyen esetben sokkal hatékonyabbak, mint a generikus, nagy tömegek számára gyártottak.
34

Nem mertem Poetrora

H.Z. v2 · 2012. Már. 13. (K), 11.46
Nem mertem Poetrora hivatkozni, de mintha tőle láttam volna valami hasonló véleményt pár hete.
31

Saját és nyílt forrású

Hidvégi Gábor · 2012. Már. 13. (K), 09.13
Saját és nyílt forrású keretrendszert is lehet jól meg rosszul is megírni, és sokszor az a kód a legkevesebb, amit abból használsz, az alkalmazáslogika pedig több. Viszont ha a keretrendszerben derül ki egy hiba, akkor a nyílt forrásúnál vakarhatod a fejed, hogy hogyan javítsd, míg sajátnál könnyebben nyúlsz hozzá.

A nyílt keretrendszerek egy-egy problémára általános megoldást adnak, ami mindaddig jó, amíg speciális igény nem merül fel, például beágyazott környezetben is futnia kell a programodnak, vagy épp ellenkezőleg, elosztott rendszerben. Ilyenkor előnyben lehet az, aki nem keretrendszeren nőtt fel, és a programnyelv segítségével közvetlenül is meg tudja oldani a problémát.
47

A következőkben legyél szives

inf3rno · 2012. Már. 14. (Sze), 15.23
A következőkben legyél szives visszavenni ebből az arrogáns stílusból, vagy kénytelen leszek törölni az ilyen jellegű hozzászólásaid.
5

yii

Greg · 2012. Már. 12. (H), 15.53
En a yii-t ajanlom. Symfony rengeteg felesleges(szerintem) fajlt general es ezaltal lassu en ezert dobtam. Itt tudod letolteni: yiiframework.com
7

Hallottam róla

stan · 2012. Már. 12. (H), 16.10
Hallottam már a Yii keretrendszerről.

Elmondanád, hogy neked személye szerint miért tetszik?

Milyen tapasztalataid vannak a Yii-vel kapcsolatban, és ha esetleg van hátránya, mi az?
10

..

Greg · 2012. Már. 12. (H), 17.43
En a Rails keretrendszert nagyon megszerettem es kerestem PHP alternativat. Nekem a Yii tunik a legkozelebb allonak hozza, ez volt a valasztas oka.
Ami szerintem pozitivum, hogy nincs felesleges sallang. Van egy jo routing, egy jo ORM(ActiveRecord), ami szerintem a 2 legfontosabb dolog egy frameworknel. Ezen felul konnyen kiegeszitheto, es a kiegeszisek konnyen ujrahasznosithatoak mas projecteknel is.
22

Ami szerintem pozitivum, hogy

Protezis · 2012. Már. 12. (H), 22.23
Ami szerintem pozitivum, hogy nincs felesleges sallang

Az biztos. Nézd meg a CHtml-t, tömör gyönyör. 2200 sornyi statikus metódus.
25

nem hiszem hogy azok a

Greg · 2012. Már. 12. (H), 22.55
nem hiszem hogy azok a helperek felesleges sallangok lennenek. de ha te mondod, biztos :).
27

Tényleg nem az. Ha kicsit

Protezis · 2012. Már. 12. (H), 22.57
Tényleg nem az. Ha kicsit bele akarsz nyúlni, akkor egy egyszerű copy-paste, némi sed, és már meg is van.
28

bar az igaz hogy ezen a

Greg · 2012. Már. 12. (H), 22.58
bar az igaz hogy ezen a reszen lenne mit atalakitani a frameworknek. pont ezen a reszen egeszitettem ki es van par folosleges resz, amit en megszuntetnek. remelhetoleg a kovetkezo verzio mar letisztultabb lesz.
49

Hát kb 100 statikus metódusa

inf3rno · 2012. Már. 14. (Sze), 15.53
Hát kb 100 statikus metódusa van (50-ig számoltam, aztán meguntam)... Ebből több, mint 20 osztály kijönne... Tervezési rémálom... :D
8

Érdekes statisztika

stan · 2012. Már. 12. (H), 16.52
Közben kicsit játszottam a Google Trends szolgáltatással, ez jött ki:
Zend, CodeIgniter, Symfony, Yii, CakePHP népszerűségének időbeni összehasonlítása

Illetve másik játék:
CodeIgniter, Symfony, Yii, CakePHP népszerűségének időbeni összehasonlítása

Nagyon érdekes statisztika, ki mit gondol róla?
17

Re: statisztika

T.G · 2012. Már. 12. (H), 19.27
Előttem már sok mindent leírtak, így én csak egy másik összehasonlítást ajánlok neked! Nézd végig az állás ajánlatok között, hogy melyik keretrendszer ismeretét várják el, az is egy jó képet adhat, hogy itthon miket használnak.
Attól persze óva intenélek, hogy ZF-fel indítsál. Többen leírták már, hogy kezdésnek egy könnyedebbet érdemes választani, én a Kohana-t ajánlanám. (indokolni nem tudok, szubjektív szimpátia:) Utána, ha lesz egy reális képed arról, hogy mit is vársz el egy keretrendszertől, akkor már könnyebben tudsz választani az erősebb rendszerek közül!
18

kohana

Greg · 2012. Már. 12. (H), 19.32
amit en eddig a kohanabol lattam, az alapjan a validaciok a controller-ben vannak, ami szerintem eleg nagy hiba, mert igy nem lesz DRY a kodod egy cseppet sem. persze lehet csak a peldak voltak rosszak amiket en lattam.
19

Ezt most nem biztos, hogy értem...

T.G · 2012. Már. 12. (H), 20.32
Ezt most nem biztos, hogy értem, akárhol példányosíthatjuk a Validate-t. Nincs megszorítás, hogy hol kell. Az, hogy a legtöbb esetben a GET, illetve a POST adatokat ellenőrizzük, és azokat a kontrollba tesszük, még nem azt jelenti, hogy kötelező, hogy így csináljuk, illetve, hogy csak így lehet.
Magukat elegáns HMVC-nek hívják, eddig nem gondoltam volna, hogy gond van ezzel. :)
20

..

Greg · 2012. Már. 12. (H), 20.57
http://kohanaframework.org/3.0/guide/kohana/security/validation
egyszer valaki segitseget kert kohana-val kapcsolatban es errol az oldalrol probalta a mintat probalta megcsinalni. En itt csak annyit lattam hogy a POST-on hivja meg a validalast a framework, a controller-ben. Mostmar latom, hogy ezt barhol megteheted. egyebkent szerintem nem GET es POST adatokat kellene ellenorizni, hanem a model bizonyos attributumait mielott erteket kapnak es ha nem a megfelelo erteket probaljuk atadni, akkor azt nem elfogadni es egy hibat generalni. Ez az ertekadas meg ugyebar tobbfele keppen lehetseges. Johet POST-bol, GET-bol, stb.
23

Előfeltétel

T.G · 2012. Már. 12. (H), 22.47
Kapiskálom, hogy mire gondolsz, és véleményem szerint a Kohana erre maximálisan alkalmas. A megírt példák csak iránymutatóak. Ilyen szintem el lehet térni tőlük, de...
...nem rossz az, ha a klienstől jött adatokat előszűrjük. A modell ne arról szóljon, hogy mindenféle típusellenőrzést végezzünk ott. Ha számot várunk az url-ből, akkor azt még a kontroll alakítsa számmá, a kontroll ne adjon „hibás” értéket tovább. Igaz, ezek csak formai ellenőrzések, illetve átalakítások. Amit te írtál, azok csak ezután jönnek, a modell is végezze el a maga ellenőrzéseit a logikai összefüggések kapcsolatba. De ott már hadd tételezzük fel, hogy pl. az id az egy szám, legyen ez a modell előfeltétele.
24

az a baj, hogy ha a peldak

Greg · 2012. Már. 12. (H), 22.52
az a baj, hogy ha a peldak rosszak, akkor az ilyenek mint en, itt meg is allnak es nem probaljak ki a keretrendszert, holott, lehet hogy tetszene, ha melyebben beleasnam magam.
az url-bol jovo adatokat szerintem mar a route-ok feldolgozasanal ellenorzni kell, ha azt a routenal megadod hogy milyen pattern-nek feleljen meg.
50

+1, akkor azt hiszem

inf3rno · 2012. Már. 14. (Sze), 15.58
+1, akkor azt hiszem félreértettem Greg hozzászólását, azt hittem, hogy az előszűrést akarja a model-be tenni, annak viszont mindenképp a controller-ben a helye ...
40

Alapvetően a modelben vannak

_subi_ · 2012. Már. 13. (K), 12.22
Nekem is szempont volt az új framework választásnál, hogy a model végezze a validációt (ez legyen az alapértelmezett). És a Kohana3-ban ez nincs is másként:
http://kohanaframework.org/3.2/guide/orm/validation
http://kohanaframework.org/3.2/guide/orm/examples/simple

Pontosabban van lehetőség bizonyos ellenőrzések elvégzésére a controller-ben. Pl. a captcha ellenőrzés nem a model feladata.

Egyébként jó pár fw megnézése, és a számomra fontos szempontok kiértékelése után nagyon gyanús, hogy a Kohana3 lesz a befutó, hacsak a Zend Framework 2 nem lesz elképesztően jó, ha kijön végre...
37

Zend != Zend Framework

_subi_ · 2012. Már. 13. (K), 11.49
Jó hogy nem a CakePhp-ből csak a php-t vagy a cake-t írtad be. :)

Egyébként szerintem kezdj a CodeIgniter-rel mert egyszerűbb, mint a többi, a dokumentációja pedig kiváló. Utána, ha ezt az egyszerű keretrendszert megismerted, úgy is meg fogod nézni a többit is. Ha pedig már 3-4 keretrendszert megnéztél közelebbről - azaz heteket töltöttél el velük -, akkor már fogsz tudni választani.
30

Symfony 2

Práger Ádám · 2012. Már. 13. (K), 03.23
Hali!

Nálam toronymagasan a Symfony 2 a győztes, mondom ezt úgy, hogy legalább egy projekt erejéig volt szerencsém a következőkhöz: CodeIgniter, Kohana, Zend, CakePHP, írtam egy sajátot, és részt vettem egy céges fejlesztésében is.

Mindenképpen ajánlom, hogy próbáld ki, következők miatt:

- Új, de már kinőtte a gyermekbetegségeket, hosszabb távra leszel jó vele, mint mondjuk egy olyannal ami éppen átírás előtt áll. (Szerintem ez az egyik legfontosabb szempont)

- Ha már kicsit belejössz, akkor nagyon könnyen átlátod, mert minden teljesen logikus, annak ellenére, hogy az elején szokatlan.

- A Symfony és a Zend kivételével mindenhol kicsit az az érzésem volt, hogy két fal közé vagyok szorítva, csak egyféle lehetőség volt, a többit úgy tákolták hozzá. Itt lehetőség van választásra, ha neked xml a kedvenc, akkor abban dolgozol, ha annotation akkor abban. Persze választási lehetőség nem csak a configra van...

- Elképesztően jó Router, és Form kezelés, ez mindig az egyik első dolog amit megnézek egy frameben.

- Doctrine 2 nuff said

- Dependency Injection Container(aka Service Container): Szerintem a Symfonys srácok ezt nagyon eltalálták, igenis van létjogosultsága PHPben is.

- Full stacked... nem kell feltalálnod a spanyol viaszt, de ha akarod megteheted.

Hátrányként 2 dolgot tudnék említeni:

- Nincs hozzá még jó CMS rendszer. Próbálkozások persze vannak, de olyat még nem találtam, amire azt mondom, hogy ez igen. ( Lehet hogy ez inkább lehetőség valamit alkotni? :) )

- Ha egy exceptiont kapsz valahonnan mélyről, akkor elég nehéz dolgod van (az elején). Persze itt nem arra kell gondolni, hogy minden apróságért órákat debuggolsz, az esetek nagy részében teljesen egyértelmű a hiba. Erre egyébként van már egy javítási kísérlet 3. személytől, de még nem próbáltam, már nem igazán futok bele ilyenbe.

+ 1 Tipp: ha már pár napot eltöltöttél vele, és azt látod, hogy nagyon sok olyan dolog van benne, amit lehetne sokkal egyszerűbben is, akkor ne dobd ki, kitartás! Először én is így voltam vele, aztán jöttek a nagy ledöbbenések "Hihetetlen, hogy erre is gondoltak" címmel.

Remélem segítettem.
36

Köszönöm

stan · 2012. Már. 13. (K), 11.48
Köszönöm a kimerítő elemzést!

Nálam jelen pillanatban az utóbbi napok kutatása alapján a codeIgniter a befutó. Tudnál mondani valamit erről a keretrendszerről is? Neked miért nem tetszett a codeIgniter?
43

CI sem rossz

Práger Ádám · 2012. Már. 13. (K), 13.36
A CI sem rossz, de mindenképpen azzal kezdeném, hogy Doctrine2 őt hozzácsapom.

Azt nem mondanám, hogy nem tetszett, inkább fogalmazzunk úgy, hogy kicsit kevés nekem.
Nem php 5.3 as, Model elég vékony, Form osztály gyakorlatilag nincs, csak egy validáció, ami elég szerény, és egy helper, amivel meg tényleg nem mész semmire...

Amiért szerintem népszerű, az a viszont pont az egyszerűsége... egy Symfonytól meg Zendtől nagyon sokan megijednek.
39

Smyfony2 első keretrendszernek?

_subi_ · 2012. Már. 13. (K), 12.19
Egyelőre még sok profi Symfony-t használó embertől is azt hallom, hogy a Symfony2 még nem elég kiforrott, bugos, hiányos a dokumentációja, nincs admin generátor stb., ami miatt még nem ajánlják.

De ha mindezek nem lennének, szerintem akkor sem ajánlható nyugodt szívvel első keretrendszernek.
42

Ez már nem igaz, bár fél éve

Práger Ádám · 2012. Már. 13. (K), 13.22
Ez már nem igaz, bár fél éve még az volt. Mára már bug nem sok maradhatott, mostanában nem találkoztam egyel sem. Admin generátor is elkészült, doksi is már használható. Szerintem aki ezt mondta, valószínűleg még RC állapotban nézhette, vagy kapásból az 1.0 után.

Az hogy első keretrendszernek mennyire jó, az szerintem tudásszint függvénye.
44

Én is sok buggal találkoztam

_subi_ · 2012. Már. 13. (K), 13.38
Én is sok buggal találkoztam és nem fél éve (igaz az utóbbi 1-2 hónapban rá sem néztem a Symfony2-re). Sok cikket is láttam az általam említett hiányosságokról, de bevallom nem figyeltem mindenhol a dátumot.

Az hogy első keretrendszernek mennyire jó, az szerintem tudásszint függvénye.


Nem hiszem, hogy sok, keretrendszert eddig még nem használó fejlesztőnek ideális kezdés lenne. Honnan is lenne meg a tudás, ha a tudás egyik alapköve pont a keretrendszer használat? Szerintem az élet minden területén végig kell járni a lépcsőket...
51

Ha egy exceptiont kapsz

inf3rno · 2012. Már. 14. (Sze), 16.14
Ha egy exceptiont kapsz valahonnan mélyről, akkor elég nehéz dolgod van (az elején). Persze itt nem arra kell gondolni, hogy minden apróságért órákat debuggolsz, az esetek nagy részében teljesen egyértelmű a hiba. Erre egyébként van már egy javítási kísérlet 3. személytől, de még nem próbáltam, már nem igazán futok bele ilyenbe.


Ez tervezési hibára utal, a magasabb absztrakciós szintű osztályoknál try-catch-be kellett volna tenni, az olyan metódusokat, amik alsóbb szinten kivételt válthatnak ki, és új kivételt példányosítani hozzájuk, ami magyarázza a hiba okát. Durván valami ilyesmit kéne csinálniuk:


class LowerAbstractionLevelException extends Exception {
    
}

class HighAbstractionLevelException extends Exception {

    public function __construct($message, Exception $lowerLevelException) {
        parent::__construct($message, null, $lowerLevelException);
    }

}

class LowerAbstractionLevelObject {

    public function doSomethingSimple() {
        if ($somethingWentWrong)
            throw new LowerAbstractionLevelException('something went wrong');
    }

}

class HighAbstractionLevelObject {

    public function doSomethingComplex() {
        try {
            $lowObject = new LowerAbstractionLevelObject();
            $lowObject->doSomethingSimple();
            $anotherLowObject = new LowerAbstractionLevelObject();
            $anotherLowObject->doSomethingSimple();
            //...
        } catch (Exception $lowerLevelException) {
            throw new HighAbstracrionLevelException('complex process failed', $lowerLevelException);
        }
    }

}
Persze ettől még lehet jó rendszer, csak kicsit nehezebb miatta debuggolni...
33

Az órisáprojektek

stan · 2012. Már. 13. (K), 11.46
Még Janoszen említette korábban, hogy a nagyon nagy cégek azok mindenképpen saját fejlesztésű keretrendszereket használnak a jobb teljesítmény miatt. Tehát a gigantikusan nagy projektek esetében (Google, Facebook, stb) nem jöhetnek szóba a hagyományos framework-ök, hanem sajátot használnak?

Kiváncsi vagyok, hogy az olyan világcégek mint a Google, a Facebookb stb, amelyek webre fejlesztenek kifejezetten, milyen keretrendszereket vagy megoldásokat alkalmaznak? Bár gondolom ott a számítások nagy része inkább valamilyen gépközeli nyelven történik pl. C++, és onnan kerülnek vissza az eredmények pl. php-ba, de az már csak egy view réteg. Nem tudom, csak sejtem, hogy így történhet.

Tud valaki valamit arról, hogy az ilyen gigantikus projektekben mi a módi manapság? Bár az már más kategória nyilvánvaló.
38

Volt párszor blogmark a

Hidvégi Gábor · 2012. Már. 13. (K), 11.53
Volt párszor blogmark a Facebook fejlesztéséről, a HipHop PHP-ről, ami PHP-ből C++-t generál. Emellett szokás még a MySQL-t tuningolni, valamint találkoztam már olyan keresőgyártó céggel, akik teljesen saját adatbáziskezelőt írtak, mert a piacon lévő szoftverek képtelenek voltak azt a teljesítményt nyújtani, amire nekik szükségük volt.
41

Óriásprojekt?

Poetro · 2012. Már. 13. (K), 12.46
Magyarországon szerinted pár kivételtől eltekintve vannak ilyen óriásprojektek? Mert például mi, az Examiner.com-nál Drupal 7-et használunk, napi több mint 2 millió oldalletöltéssel. Ez azért több, mint a magyar hírportálok legnagyobbjainak napi forgalma. Azt nem mondom, hogy egyetlen szerverrel csináljuk, mert ugye az egyértelmű, hogy lehetetlen, de azért pár szerver elegendő. Gyakran nem a használt nyelv, hanem az adatbázis vagy a fájlrendszer lesz a korlátozó tényező. Természetesen egyes feladatokra érdemesebb lehet más nyelvet választani, mint a PHP, ismerve annak futási hátrányait más nyelvekkel illetve rendszerekkel összehasonlítva.
53

Keretrendszerekről

fchris82 · 2012. Már. 16. (P), 21.27
A keretrendszer lényege, hogy egy eszközt ad a kezedbe, amivel piszkosul gyorsan tudsz fejleszteni. A gyors fejleszthetőséget feláldozzák a teljesítmény oltárán, de a fejlettebb programnyelvek mind erről szólnak. Biztosan sokkal gyorsabb blogmotor tudna elkészülni Assamble-ben, saját webservert írva benne, csak semmi értelme.

A keretrendszerek lényege, hogy viszonylag olcsón és a lehető leggyorsabban megkapod funkciójában azt, ami kell. Egyrészt ez az esetek 99,99%-ban elég. Főleg, ha egy Start-up ötletről, cégről beszélünk. Elkészül az oldal, úgysem kap egyből 1 000 000 kérést per másodperc. Az oldal fejlődésével, az igények változásával pedig lehet bővíteni a vasak számát, a keretrendszerben lehet elosztott rendszert fejleszteni, lehet optimalizálni adatbázis oldalon - memóriába pakolni a fontosabb adatokat, cache-elések, stb. Egy FB esetén pedig megoldható, hogy a fejlesztés lassabban menjen - vagy több emberrel -, viszont "pure" php-ban készüljön az egész, esetleg C-ben vagy ahogy tetszik, mert ott már az is számít. De ez az esetek 0,0001%-a, és ott már nem egyéni fejlesztőkről beszélünk, meg nem arról, hogy van 2 000 000 Ft induló tőke...
45

Előfeltételek

stan · 2012. Már. 13. (K), 14.11
Még az merült fel bennem kérdésként, hogy milyen előfeltételei vannak, hogy megértsek egy keretrendszert? Ugyanis PHP-val elég jól tudok már programozni, de az OOP-hez még alig értek.

Először érdemes lenne PHP OOP programozást gyakorolnom, vagy anélkül is belevághatok?

Ha előtte azt kell gyakorolnom, mi erre a legjobb módszer? Olvassam át ezt?
http://www.php.net/manual/en/language.oop5.php
46

egyreszt OOP, masreszt a

Greg · 2012. Már. 13. (K), 14.14
egyreszt OOP, masreszt a legtobb rendszer MVC vagy abbol eredo pattern-re epit.
52

Kezdd el, aztán idővel

inf3rno · 2012. Már. 14. (Sze), 16.22
Kezdd el, aztán idővel belejössz. Érdemes elolvasnod néhány követ a témában, pl design patterns, refactoring, clean code, tdd by example, stb... Ezekből rengeteget lehet tanulni, amire magadtól nem biztos, hogy rájössz, vagy csak nagyon sok idő elteltével...