Huh, jó régóta készülök már ennek a cikknek a megírására, de valahogy sose tudtam rászánni magam.
Részben, mert túl sok ismerősöm, barátom foglalkozik a Drupal-al, részben mert tudom, hogy hiába is mondom el miért szar az egész, sokak továbbra is nyomni fogják.. (Persze ismerőseim egy része csak azért nyomja majd továbbra is, mert szinte csak ezt ismeri. És aki csak a kalapácsot ismeri, az hajlamos mindent szögnek nézni...)
Nemrégiben sikerült részt vennem egy-egy intenzív Drupal "sminkmesteri", valamint programozói tanfolyamon is. Maguk a tanfolyamok nagyon színvonalasak voltak, nagyon jó tematika alapján hasznosítható tudást kaptunk. Ennek ellenére, vagy talán épp ezért, hogy most már mélyebben ismerem a CMS-t mondom azt: átlagos vállalati környezetben nagyon felejtős a Drupal.
Jól látszik a CMS-en, hogy alapvetően négyes tagolása van:
Ha viszont azokkal dolgozunk, akkor már piszkosul elszakadunk a "kezelhető" fejlesztésektől: rengeteg beállítást adatbázisban itt-ott tárol a CMS, van azonban amit config file-okban, és van amit file-okból olvas fel adatbázisba. A sitebuilder-nek GUI-n kiajánlott "összekattintgatósdi" alapú "fejlesztés" piszkosul be tud kavarni. Nincs éles határ az adattartalom előállítása és a generált adatok formázása között. A tartalom előállítási-formázási folyamat szinte bármely lépésénél be lehet avatkozni akár az adattartalomba, akár a formázásba. Így viszont nagyon nehezen lehet jól átlátható, dokumentálható, fenntartható kódot előállítani. Hiszen ki itt nyúl bele, ki ott mert a CMS lehetőséget kínál bármely ponton szinte minden módosítására. Sokan ezt persze előnyként hoznák fel, azonban szerintem ez abszolúte nem előny. Ha éles határokkal rendelkezne a CMS, hogy melyik folyamat meddig és hol módosítható, sokkal kezelhetőbb, átláthatóbb "szabványkövetőbb" egyedi fejlesztéseket szülne a Drupal közösség.
Másik rész az üzemeltetés: pontosan, mivel a sitebuilder eszközökkel GUI-n összekattintgatok "fejlesztések" erősen keverednek a tiszta programkódokkal kezelhető fejlesztésektől nagyon-nagyon nehéz az egyes önálló fejlesztések egységbe foglalása, deploy-olása, önálló továbbfejlesztése. Nagyon-nagyon függ az egyedi fejlesztések működése az alap CMS-től, nem lehet annyira elkülöníteni őket, hogy egy esetleges Drupal frissítés vagy csak sitebuilder-i kattintgatás ne kavarjon be nekik. Nagyon nem egyszerű az egyes önálló fejlesztések backup-olása, visszaállítása mivel teljesen széttöredezik a hozzá kapcsolódó adattartalom és beállítási paraméterek tárolása, kezelése...
Pont ezen dolgok miatt mondom azt, hogy hobbysite-ok, nem üzleti kritikus magán vállalkozások weblapjára tökéletes mindaddig a Drupal, amíg azok csak nettó tartalommegjelenítés van (semmi alkalmazás logikát nem erőltetünk bele), és nem jár nagy presztízsveszteséggel az oldal leállása (jellemzően az utólagos "fejlesztések" "összekattintgatások" konfigurálási okai miatt).
Persze folyamatosan hallom, hogy majd a következő verzióban. Igen ám, de az 5-ös Drupal-nál ha megkérdeztem, mi ez a sok szemét 3-as, 4-es PHP verzióhoz tartozó kód benne, akkor azt hozták fel, hogy majd a 6-os Drupal lesz a bikicsunáj. A szemét régi kódrészletek egy részét persze kigyomlálták, valami folyamat elindult, de amikor felmerült, hogy az igencsak elcseszett CCK modul mivel lesz leváltva, mindenki azt mondta, hogy majd a 7-es Drupalban a field-ek. OK, bejött a 7-es, megvannak a field-ek, de korántsem hiszem, hogy ez lenne a CCK által behozott problémára a valódi megoldás. Most viszont folyamatosan azzal hitegetik az embert, hogy a nagyon-nagyon régóta fejlesztett CMS-ből végre kigyomlálják a régi gányolt programrészeket és tisztán OO 5-ös verziójú PHP kódra írják át a 8-as verziót...
Szóval szép-szép, látszik a fejlődés, de akkor is: komoly céges környezetben erősen felejtős még/már ez. Nagyon szeretnék már látni végre egy olyan free CMS-t, ami profi fejlesztési metodika alapján lett tervezve és fejlesztve, nem csak ad hoc módon összekódolva...
Részben, mert túl sok ismerősöm, barátom foglalkozik a Drupal-al, részben mert tudom, hogy hiába is mondom el miért szar az egész, sokak továbbra is nyomni fogják.. (Persze ismerőseim egy része csak azért nyomja majd továbbra is, mert szinte csak ezt ismeri. És aki csak a kalapácsot ismeri, az hajlamos mindent szögnek nézni...)
Nemrégiben sikerült részt vennem egy-egy intenzív Drupal "sminkmesteri", valamint programozói tanfolyamon is. Maguk a tanfolyamok nagyon színvonalasak voltak, nagyon jó tematika alapján hasznosítható tudást kaptunk. Ennek ellenére, vagy talán épp ezért, hogy most már mélyebben ismerem a CMS-t mondom azt: átlagos vállalati környezetben nagyon felejtős a Drupal.
Jól látszik a CMS-en, hogy alapvetően négyes tagolása van:
- Olvasó: csak a megjelentetett tartalmakat olvassa, illetve előre elkészített adatbeviteli felületeken dolgozik,
- Tartalom előállító: az olvasó számára készít új tartalmakat (cikkek, dokumentumok, stb.) a CMS által kínált eszközökkel, illetve a "sminkmesterek" és programozók által készített kiegészítésekkel,
- "Sminkmesterek": no itt kezdődik a gebasz... Elvileg ők "csak" az oldalon megjelenő adatok, információk megjelenését, layout-ját szabják testre, azonban a Drupal kezdetleges időszakában a lusta programozók úgy gondolták, jobb ha minél több dolgot a sitebuilder-ekre bíznak, annál kevesebbet kell nekik dolgozniuk,
- Programozók: ők az alaprendszer testreszabásával, funkcionális, moduláris bővítésével foglalkoznak.
Ha viszont azokkal dolgozunk, akkor már piszkosul elszakadunk a "kezelhető" fejlesztésektől: rengeteg beállítást adatbázisban itt-ott tárol a CMS, van azonban amit config file-okban, és van amit file-okból olvas fel adatbázisba. A sitebuilder-nek GUI-n kiajánlott "összekattintgatósdi" alapú "fejlesztés" piszkosul be tud kavarni. Nincs éles határ az adattartalom előállítása és a generált adatok formázása között. A tartalom előállítási-formázási folyamat szinte bármely lépésénél be lehet avatkozni akár az adattartalomba, akár a formázásba. Így viszont nagyon nehezen lehet jól átlátható, dokumentálható, fenntartható kódot előállítani. Hiszen ki itt nyúl bele, ki ott mert a CMS lehetőséget kínál bármely ponton szinte minden módosítására. Sokan ezt persze előnyként hoznák fel, azonban szerintem ez abszolúte nem előny. Ha éles határokkal rendelkezne a CMS, hogy melyik folyamat meddig és hol módosítható, sokkal kezelhetőbb, átláthatóbb "szabványkövetőbb" egyedi fejlesztéseket szülne a Drupal közösség.
Másik rész az üzemeltetés: pontosan, mivel a sitebuilder eszközökkel GUI-n összekattintgatok "fejlesztések" erősen keverednek a tiszta programkódokkal kezelhető fejlesztésektől nagyon-nagyon nehéz az egyes önálló fejlesztések egységbe foglalása, deploy-olása, önálló továbbfejlesztése. Nagyon-nagyon függ az egyedi fejlesztések működése az alap CMS-től, nem lehet annyira elkülöníteni őket, hogy egy esetleges Drupal frissítés vagy csak sitebuilder-i kattintgatás ne kavarjon be nekik. Nagyon nem egyszerű az egyes önálló fejlesztések backup-olása, visszaállítása mivel teljesen széttöredezik a hozzá kapcsolódó adattartalom és beállítási paraméterek tárolása, kezelése...
Pont ezen dolgok miatt mondom azt, hogy hobbysite-ok, nem üzleti kritikus magán vállalkozások weblapjára tökéletes mindaddig a Drupal, amíg azok csak nettó tartalommegjelenítés van (semmi alkalmazás logikát nem erőltetünk bele), és nem jár nagy presztízsveszteséggel az oldal leállása (jellemzően az utólagos "fejlesztések" "összekattintgatások" konfigurálási okai miatt).
Persze folyamatosan hallom, hogy majd a következő verzióban. Igen ám, de az 5-ös Drupal-nál ha megkérdeztem, mi ez a sok szemét 3-as, 4-es PHP verzióhoz tartozó kód benne, akkor azt hozták fel, hogy majd a 6-os Drupal lesz a bikicsunáj. A szemét régi kódrészletek egy részét persze kigyomlálták, valami folyamat elindult, de amikor felmerült, hogy az igencsak elcseszett CCK modul mivel lesz leváltva, mindenki azt mondta, hogy majd a 7-es Drupalban a field-ek. OK, bejött a 7-es, megvannak a field-ek, de korántsem hiszem, hogy ez lenne a CCK által behozott problémára a valódi megoldás. Most viszont folyamatosan azzal hitegetik az embert, hogy a nagyon-nagyon régóta fejlesztett CMS-ből végre kigyomlálják a régi gányolt programrészeket és tisztán OO 5-ös verziójú PHP kódra írják át a 8-as verziót...
Szóval szép-szép, látszik a fejlődés, de akkor is: komoly céges környezetben erősen felejtős még/már ez. Nagyon szeretnék már látni végre egy olyan free CMS-t, ami profi fejlesztési metodika alapján lett tervezve és fejlesztve, nem csak ad hoc módon összekódolva...
3 megjegyzés:
CMS Made Simple?
Hm. Köszi! Ezt még nem ismertem, leszedem megnézem mit tud.
Nos, ez alapján érdekes...
Megjegyzés küldése