( Yorirou | 2010. 12. 11., szo – 00:45 )

elnevezesi konvenciok: convention over configuration tervezesi mintarol mar hallottal? eppen az a trend, hogy minden ket soros valtoztatasert ne kelljen mar letrehozni egy subclasst, es aztan valahol kulon regisztralni meg egy esemenykezeloben... nem tul praktikus.

globalis $user: errol eppen folyik a diskurzus (lasd butler csoport), hogy nem igy kellene. A jovoben (Drupal 8 valoszinu) valtozni fog (csak ez nem olyan egyszeru, mint amilyennek elsore latszik).

az index.php az 22 sor jelenleg (Drupal 7 RC1). A bootstrap.inc az 3000 sor felett van, de szet van szedve nem tul nagy fuggvenyekre.

proceduralissag: a Drupal vegyes paradigmaju rendszer. Hasznal OOP elemeket, de nem sokszor hasznalja fel a PHP nyelvi elemeit (fokent a 6-os verzio). Ennek az az oka, hogy a Drupal 6-nak kompatibilisnek kellett maradnia a PHP 4-gyel (a kozosseg igenye volt, mert akkor, amikor kijott meg nagyon sok hosting nem valtott PHP 5-re), es csak bonyolitottak volna a kodot, ha a PHP 4 OOP szintaktikajat hasznaljak. Drupal 7-nel meg nem volt arra kapacitas, hogy varazsszora rajojjenek, hogy hol eri meg OOP szintaxist hasznalni, es mindent atdolgozzanak. Ahol nagyon kellett, ott megtettek, es hamarosan kiadjak. Egy csomo ember elkezdi hasznalni, varhatoan lesznek jo otleteik, aztan rajovunk kozosen, hogy mit kell meg gyurni ahhoz, hogy jobbak legyunk. Nem lesz esz nelkul agyonoopsitve az egesz (abstract class abstract class hatan). Vannak olyan rendszerek (theme rendszer), amit csak nagysagrendekkel rondabban es lassabban lehetne OOP-re atvinni. Van olyan, ami bar nagyon OOP-nek latszik, de valahogy nem akar idomulni a PHP OOP rendszerere (Form API). A fo csapasvonal jelenleg a hard dependency-k csokkentese, ezzel a flexibilitas tovabbi novelese, es a tesztelhetoseg javitasa. Itt is vigyazni kell, mert ha mozdulunk egy iranyba, azzal sertunk egy masikat, tehat at kell gondolni.
Olvasnivalo:
http://www.garfieldtech.com/blog/architectural-priorities
http://www.garfieldtech.com/blog/language-tradeoffs

Viszont ezek nem annyira egeto gondok. A legtobb webes technologiat a Drupal tamogatja elsokent (RDFa pl), biztonsag tekinteteben sincs szegyellnivalonk, contrib modulok szamaban es minosegeben vezeto CMS vagyunk. Skalazhatosagban folyamatosan javul a Drupal, hatalmas oldalakat is vigan kiszolgal. Szamos olyan technologiank van (Fields, regebbi neven CCK, vagy eppen a Views), amik komoly elonyt jelentenek mas CMS-ekkel vagy frameworkokkel szemben. SEO-rol mar nem is beszelve. A parancssor szerelmeseinek pedig ott a drush, amivel egy csomo dolgot lehet automatizalni.

Amikor egy komoly helyre valasztanak platformot, akkor nem csak azt nezik, hogy hany abstract class van benne, hanem a fenti szempontokat is figyelembe veszik. Kisebb helyeken pedig olyan aprosagok dontenek, hogy fields+views segitsegevel pillanatok alatt ossze lehet pakolni egy kozepes oldalt, akarmilyen csicsas adatprezentacioval. Ebbol a features modul segitsegevel 2 klikk modult gyartani, tehat verziozhato is nagyjabol rendesen. Ha mar jo akar lenni a ceg, akkor ir egy install profile-t hozza, aztan aegir-rel akar tobb szaz site-ot is deployolhat vele.