PHP framework
Sziasztok!
egy újabb témában kérném a segítségeteket. részben kapcsolódik az adatbázisos kérdésemhez.
pp kolléga említi, hogy a probléma Drupal-lal viszonylag könnyen megugorható.
ezeddig volt szerencsém olyan helyen dolgozni, ahol saját fejlesztésű rendszereket is használtunk. emellett volt szerencsém Zendhez, Contenidohoz, Joomla!hoz. és nézegettem Drupalt, Yiit.
Azt mondanám, hogy a Contenido a legprogramozóbarátabb rendszer, mindamellett, hogy egy ...
a rövid véleményem a többi rendszerrel kapcsolatosan hasonló a Contenidonál leírtakhoz, kihagyva a programozóbarát jelzőt.
mindegyik nagyon nagy tudású, ami abban merül ki, hogy egy adott probléma megoldása viszonylag rögös tanulási folyamat végén a szükségesnél sokkal bonyolultabban oldható meg. aki csinált már Zend-ben form-ot tudja miről beszélek. bármit meg lehet csinálni benne nem kérdés, de hogy egy input mező megjelenítésében 5 osztály vegyen részt, az kicsit erős.
de ne csak fikázásról szóljon ez a bejegyzés. vegyünk egy konkrét problémát.
route-olás, controllerek, view-k.
Zend (és ahogy nézegetem Yii-nél is) esetén pl fel kell sorolnunk az összes route-ot, ő szépen végigmegy ezeken, majd kiköp egy Controller/action párost, amit szépen meghív.
/projects
/projects/my-project/
/projects/my-project/contracts/
/projects/my-project/logging/
/projects/my-project/logging/2012-11/
/projects/my-project/logging/2012-11/12/diary-type/
/projects/my-project/logging/2012-11/12/diary-type/create/
/projects/my-project/logging/2012-11/12/diary-type/id/
abstract route-ok segítségével az egyes részek elkészíthetők, aztán ezeket felsorolva össze lehet rakni a konkrét route-okat. és a drága zend végigmegy mindegyiken, megnézve, hogy van-e egyezés. tehát adott esetben a project/my-project/logging 6-szor match-el mire eljut egy találatig. nem vagyok zend guru lehet, hogy másképp van, de mostani ismereteim szerint ez így van. nyugodtan javítsatok ki.
no a kérdésem az volna, hogy van-e olyan framework, amiben pl léteznek 'route tree'-k vagy nem tudom hogyan nevezzem őket?
szintén ezzel a problémával kapcsolatban. egy route végén kapok egy Controller/Action párost. aztán abban kell mókolnom, hogy az adott action-höz milyen layout, satöbbi tartozik, mikor annak az action-nek igazából semmi köze hozzá. pl egy create action csináljon annyit, hogy kiköp magából egy form-ot meg a közvetlen környezetét, aztán majd valaki más csináljon vele amit akar.
ha úgy tetszik megint tree-ről beszélek legyen akkor Controller tree. adott részenként a controllerek szépen elágaztatják a futást, meghívják a feladatnak megfelelő alkontrollert, majd az általa visszaküldött adattal még dolgoznak egy kicsit. tehát szépen végigfut a vezérlés, mint egy event a DOM tree-ben pl.
tulajdonképpen miért van az, hogy nem lehet hierarchiákat csinálni semmiben és ezért idióta elkerülő megoldásokat kell használni, kitekert, fejreállított gondolatmenetet alkalmazva? miért van az, hogy 'hülyének nézik' a framework-ok a fejlesztőt és indokolatlanul nagy mértékben lecsökkentik a lehetőségeit?
én vagyok baromira eltévedve, hogy nem találok egy nekem tetsző keretrendszert, nem találtam meg még az igazit, vagy megtaláltam már, csak nem ismerem eléggé? másoknak vannak ilyen problémái?
segítsetek Vuknak a kisrókának! :)
■ egy újabb témában kérném a segítségeteket. részben kapcsolódik az adatbázisos kérdésemhez.
pp kolléga említi, hogy a probléma Drupal-lal viszonylag könnyen megugorható.
ezeddig volt szerencsém olyan helyen dolgozni, ahol saját fejlesztésű rendszereket is használtunk. emellett volt szerencsém Zendhez, Contenidohoz, Joomla!hoz. és nézegettem Drupalt, Yiit.
Azt mondanám, hogy a Contenido a legprogramozóbarátabb rendszer, mindamellett, hogy egy ...
a rövid véleményem a többi rendszerrel kapcsolatosan hasonló a Contenidonál leírtakhoz, kihagyva a programozóbarát jelzőt.
mindegyik nagyon nagy tudású, ami abban merül ki, hogy egy adott probléma megoldása viszonylag rögös tanulási folyamat végén a szükségesnél sokkal bonyolultabban oldható meg. aki csinált már Zend-ben form-ot tudja miről beszélek. bármit meg lehet csinálni benne nem kérdés, de hogy egy input mező megjelenítésében 5 osztály vegyen részt, az kicsit erős.
de ne csak fikázásról szóljon ez a bejegyzés. vegyünk egy konkrét problémát.
route-olás, controllerek, view-k.
Zend (és ahogy nézegetem Yii-nél is) esetén pl fel kell sorolnunk az összes route-ot, ő szépen végigmegy ezeken, majd kiköp egy Controller/action párost, amit szépen meghív.
/projects
/projects/my-project/
/projects/my-project/contracts/
/projects/my-project/logging/
/projects/my-project/logging/2012-11/
/projects/my-project/logging/2012-11/12/diary-type/
/projects/my-project/logging/2012-11/12/diary-type/create/
/projects/my-project/logging/2012-11/12/diary-type/id/
abstract route-ok segítségével az egyes részek elkészíthetők, aztán ezeket felsorolva össze lehet rakni a konkrét route-okat. és a drága zend végigmegy mindegyiken, megnézve, hogy van-e egyezés. tehát adott esetben a project/my-project/logging 6-szor match-el mire eljut egy találatig. nem vagyok zend guru lehet, hogy másképp van, de mostani ismereteim szerint ez így van. nyugodtan javítsatok ki.
no a kérdésem az volna, hogy van-e olyan framework, amiben pl léteznek 'route tree'-k vagy nem tudom hogyan nevezzem őket?
szintén ezzel a problémával kapcsolatban. egy route végén kapok egy Controller/Action párost. aztán abban kell mókolnom, hogy az adott action-höz milyen layout, satöbbi tartozik, mikor annak az action-nek igazából semmi köze hozzá. pl egy create action csináljon annyit, hogy kiköp magából egy form-ot meg a közvetlen környezetét, aztán majd valaki más csináljon vele amit akar.
ha úgy tetszik megint tree-ről beszélek legyen akkor Controller tree. adott részenként a controllerek szépen elágaztatják a futást, meghívják a feladatnak megfelelő alkontrollert, majd az általa visszaküldött adattal még dolgoznak egy kicsit. tehát szépen végigfut a vezérlés, mint egy event a DOM tree-ben pl.
tulajdonképpen miért van az, hogy nem lehet hierarchiákat csinálni semmiben és ezért idióta elkerülő megoldásokat kell használni, kitekert, fejreállított gondolatmenetet alkalmazva? miért van az, hogy 'hülyének nézik' a framework-ok a fejlesztőt és indokolatlanul nagy mértékben lecsökkentik a lehetőségeit?
én vagyok baromira eltévedve, hogy nem találok egy nekem tetsző keretrendszert, nem találtam meg még az igazit, vagy megtaláltam már, csak nem ismerem eléggé? másoknak vannak ilyen problémái?
segítsetek Vuknak a kisrókának! :)
Mini keretrendszerek
Ami router rendszernek nekem tetszett, az a klein és a php-router, de biztosan találsz még hasonlókat.
Nem lehet, hogy neked nem is a keretrenszerekkel, hanem a PHP-val van problémád? Nem lehet, hogy ki kellene próbálnod egy-két másik nyelvet? Mondjuk Python / Ruby / Node.js / Java / C# stb.?
Ha már Poetro is... :)
A django-t merném javasolni, egy próbát talán megér. A python egy viszonylag könnyen megtanulható nyelv, amit meg a djangoból láttam, annak alapján elég egyszerűnek tűnik. (ellenvélemény van?)
hát a zend-es form 5 osztálya
PHP-val alapvetően nincs problémám, sőt.. Python, Node.js érdekelne, de most nem azt a szakaszát élem az életemnek, hogy legyen időm foglalkozni velük (:
nagyon szeretnék megtanulni egy framework-ot, és a farvizén elmaszekolgatni, de eddig bármihez nyúltam, elfogott a viszolygás..
Azért egy egymezős form nem
Én mondjuk nem értem az 5 objektumos kifakadásod sem. Azt nem tudom, hogy Zendben mi történik, de mondjuk symfonyban mindegyik formot legenerálja a rendszer, neked csak a widgeteket/validátorokat kell lecserélni, ha nem jó amit generált. Például egy jQuery DatePickert akarsz használni, akkor lecseréled a widgetet a formodban arra, ami azt jeleníti meg és kész. Ráadásul azt a widgetet egyszer megcsináltad, továbbiakban csak a formban a beépített dátumkezelő widget helyett azt hozod létre. Symfonyban egyszerre csak egyetlen formban piszkálsz bele többnyire. Pedig ott is készül egy baseForm, egy BaseObjectForm (ez mondhatni, hgy írásvédett :-)), egy ObjectForm és ha még pluginból hozzuk létre, akkor még egy PluginObjectForm is. És természetesen a BaseForm is egy sor másik formból származik. Valószínűleg tehát itt még 5-nél is több van. De ebből én egyetlen egyet sem csináltam, hanem a Symfony generálta. És épp ez az amiért a Symfonyra esett a választásom, mert egy igazán jó és testre szabható CRUD felületet is tud generálni. Ezt a felületet ráadásul nem csak az admin/backend felületen tudom használni, hanem akár a frontenden is. Nem kis munkától megkímélem magam.
A route persze ugyanúgy működik, mint máshol, lévén hogy a PHP egy scriptnyelv. Először megnézi az elsőt, ha az nem felel meg, akkor megy a másodikra. Symfonyban van egy object route, ami megpróbálja megtalálni az objektumot, ha nem találja meg akkor a sima routehoz hasonlóan, megy tovább, és lehet hogy egy újabb object route jön, ami megint megpróbálja megtalálni a saját objektumát. Ez sajnos erőforrás zabáló, de mondjuk egy webshop-product/webshop-category/cms kombónál mit tudnál tenni? Először a cms bejegyzést, annak slugja alapján szeretném megtalálni. Aztán következne a kategória és végül a termék slug alapján történő megkeresése. Aztán ha egyik sincs, akkor megy a negyedik bejegyzésre (3 fölösleges sql lekérdezés után). Ha meg van, akkor nyilván a talált objektumot akarom megjeleníteni és odaugrik a megfelelő modulera. A fölösleges 3 sql elkerülésére létrehozhatok egy category/:slug, cms/:slug és egy product/:slug szabályt, akkor nem lesz 3 lekérdezésem, viszont csúnyább lesz az url-m :-) Nem tudom hogyan lehetne ezt úgy kategorizálni, hogy ne rontsunk a már elért eredményen.
:)
http://weblabor.hu/forumok/temak/111565#comment-86370
Ebben a hozzászólásomban írtam egy ilyet:
+ 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.
Azt tudnám ajánlani, hogy a Zendet fejetsd el(1.x túl régi, 2 túl új), Symfony2, vagy kisebb projekthez Silex.