ugrás a tartalomhoz

Chameleon CMS

paal · 2005. Május. 3. (K), 23.47
Üdv,

A 3. Roadshow tartalmában esik szó Cservenák János által fejlesztett Chameleon portál rendszerről. Lehet erről tudni kicsit többet így, előadás előtt?

Kösz, Pali
‹ Ötleteket kérek project névhez Postuke és a Windows xp!!! Help ›
 ■
1

Chameleon CMS - a nagy monológ... :D

goshawk · 2005. Május. 4. (Sze), 22.18
Üdvözletem mindenkinek!

Nálam lehet érdeklődni a portál rendszerről, ugyanis én fejlesztem jelenleg.

Még igencsak képlékeny állapotban van az egész. A hírtelen felindulás, ami elindított a rendszer írásában olyan kérdéseket vetett fel, amelyre nem nekem kellene válaszolnom, hanem a jövőbeni felhasználóknak.

Ezért megkérnék minden olyan személyt, aki az alább felsorolt szempontokkal egyetért vagy esetleg nem ért egyet vitassuk meg itt és ha esetleg bele kívánna folyni a fejlesztésbe keressen bátran engem.

Nos a portál készítés hátteréről egy kicsit:
Pár portált már volt szerencsém kipróbálni és őszintén megvallva mindben találtam jót is és rosszat is. Ha csak a legnagyobb példákat említem, akkor ugye ott a PHPnuke, PostNuke, Drupal, Mambo. A PHPnuke és a Postnuke hasonló utakon járt, jár - mindkettőnek szerintem ugyanaz a hibája. Lassú és sok erőforrást igényelnek. A Drupal más szemléletet követ, meg vannak ennek is az előnyei és a hátrányai. Az egységes kategóriakezelő (taxonomy) egy nagy ötlet szerintem. Viszont a kezelését kicsit programozó szemléletűre tervezték ezért nem annyira érthető a rendszer mindenki számára. Illetve bizonyos modulokban olyan érdekes jelenségeket találtam, amelyre nem tudtam, hogy sírjak vagy nevessek. A legjobb példa erre, hogy a 4.5 szériában filestore néven futó modul. Szép és jó, hogy adatbázisban tároljuk magát a fájl teljes bináris kódját is de azért a MySQL nem egy Oracle. Szerintem, aki már dolgozott MySQL-el az tudja, hogy igen botor dolog oda berakni a fájlokat binárisan. Nem erre lett tervezve.

Nos lényeg a lényegben, hogy a célom egy olyan portál rendszert készíteni, amely flexibilis mind a tartalom típusához mind pedig magához a felhasználóhoz illetve az adminisztrátorhoz.
Ötvözi azon jó tulajdonságokat, amiket megtapasztaltam az általam ismert portál rendszereknél és ezt egy olyan felületté összegyúrni, ami akár egy mezei felhasználó számára is emészthető.
2

Nemértem..

pp · 2005. Május. 5. (Cs), 06.56
Kézikönyvet olvastad?

http://drupal.hu/kezikonyv/disztribuciok

A közösség által beküldött kiegészítő funkcionalitások, megjelenések (sminkek), felület fordítások és dokumentációk itt találhatóak. Jellegénél fogva nincs olyan erős irányítás alatt, mint a motor, ezért nem feltétlenül csak tökéletesen működő komponenseket találhatunk itt.


Tehát a Drupalról véleményt mondani egy modul alapján botorság. ;)

célom egy olyan portál rendszert készíteni, amely flexibilis mind a tartalom típusához mind pedig magához a felhasználóhoz illetve az adminisztrátorhoz.


Ezalatt mit értesz? Miben nyílvánul meg a felxibilitás?


pp
4

...Szerintem...

goshawk · 2005. Május. 5. (Cs), 13.24
Valamilyen szinten igazad van a dologban, csak egyet nem szabad elfelejtenünk:
A motor tényleg az eddig általam látott legjobb, viszont a motor önmagában ugye
csak egy alap. A valós működéshez kellenek a modulok, amelyekkel ugye magát a portál funkciókat valósítják meg.

Viszont ha ezek a modulok rosszul vannak kialakítva az kihat az egész összképre. Ha a leendő portál tulajdonos nem tudja egyszerűen és ésszerűen kialakítani az általa óhajtott funkciókat mert nincs rá megfelelő modul, akkor nem a modulra fog rossz szemmel nézni, hanem az egészre. Ezzel a jelenséggel nem először találkoztam szembe sajnos.


Ezalatt mit értesz? Miben nyilvánul meg a flexibilitás?


Nos ezt elég hosszadalmas lenne kifejtenem. A lényege az egésznek az, hogy úgy alakítottam ki magát a motort, hogy a mind a designt mind pedig az oldal szerkezetet egyszerűen lehessen cserélgetni vagy akár hozzárendelni tartalomtípusokhoz.
Van egy olyan nézet, amit a ti oldalatokon (www.weblabor.hu) láttam talán először megvalósulni (Drupal alapú oldalaknál).

„Úgy tervezzünk weblapot, hogy az oda látogató felhasználó a harmadik kattintásra elérje az általa keresett tartalmat!”

Erre a legjobb példa, hogy a híreknél megjelenik a hír beküldőjének előző illetve a hír csoportjának előző hírei. Illetve ez mellett még ugye ott van a felhasználók hozzászólása.

Én arra gondoltam ezt meg lehetne minden tartalom típusra valósítani keresztcsatolással is.
Mert mi van akkor ha a felhasználó például elolvas egy cikket, aminek vannak előzményei, vagy esetleg lesznek folytatásai. De lehetnek letöltések is benne vagy teljesen más típusú tartalmak is. Biztosan kíváncsi lesz az összes hozzá tartozó tartalomtípusra is. Akkor meg miért ne lehetne megjeleníteni neki ugyanazzal a mórszerrel, mint a hírek modulnál.

Magyarán amit tervezek az egy olyan rendszer, ahol magánál a tartalom írásánál el lehetne dönteni mely modulok jelenjenek meg illetve milyen paraméterekkel.

Lehet kicsit bonyolultan írtam le a dolgot és nem teljesen átlátható, de sajnos nem erősségem így 3-4 óra alvás után a kommunikáció. :D
6

Nehezen hihető

Hojtsy Gábor · 2005. Május. 5. (Cs), 14.01
Azt írod, hogy a Drupalnak jó motorja van, és a nem feltétlenül jó kiegészítők adhatnak rossz összképet. Ezzel akár egyet is érthetek, ez ugye mindig az igényeiden múlik. De ennek az indoklásnak semmi köze nincs ahhoz, hogy miért is kell új motort írni? És miért nem új kiegészítőket?

Az mondjuk egy teljesen jó indok lenne, hogy jobban bele akarod magad ásni a tartalomkezelő rendszer fejlesztésbe, szeretnéd magad is elkövetni mindazokat a hibákat, amiket mások elkövettek, vagy esetleg újakat is felfedeznél. Ez rád mindenesetre jó hatással lesz, és jó esetben (ha nyílt forrású projektet csinálsz belőle) akkor a közösségre is jó hatással lehet. De akkor nem a többi rendszer minősítésével kellene indokolni.
7

:D

goshawk · 2005. Május. 5. (Cs), 14.09
Ez kicsit Drupal fanatizmus nem? :D

Na de van benne valami, amit mondasz.
Viszont egy nagyon lényeges indokom van, amiért nem a Drupalba fejlesztek:
Ha valami olyat csinálok, amit nem lehet a motorral megoldani, akkor abba is bele kell ácsolnom. Ez viszont akkor nem lesz kompatibilis a Drupal eredeti motorjával.

Magyarán ha valamit a magon akarok változtatni, akkor azt nem biztos, hogy keresztül tudom vinni.
8

Míg nem próbálod ki, nem derül ki

Hojtsy Gábor · 2005. Május. 5. (Cs), 14.27
Vannak ugye a követelmények. Vannak. Namost ezekkel eléggé szisztematikusan lehet ellenőrizni, hogy (több alkalmasnak látszó rendszert megtekintve) melyik rendszerben mit kellene változtatni, hogy működjön. Én nem tartom Drupal fanatikusnak magam, nem is szeretnélek meggyőzni arról, hogy Drupalt használj, csak arra próbáltam rávilágítani, hogy az indoklásod nem kerek.

Ha találsz egy nyílt rendszert, ami majdnem jó, akkor nem az a válasz, hogy újat kezdünk, mert teljesen jót nem találtunk, hanem megnézzük, hogy a meglévő rendszer illeszthető-e módosítások nélkül, konfigurálással, saját fejlesztéssel. Ha nem, akkor forkolhatunk, ha ezt a licenc megengedi. Ha ez sem megy, és egy olyan rendszert sem találtunk, ami jó kiindulási alap, akkor lehet tiszta lappal indulni.

Oktatási/tanulási célból persze teljesen más kérdések merülnek fel, ha éppen egy ilyen rendszer kialakításán keresztül akar valaki okosodni. Csak akkor érdemes felismerni, hogy ez irányítja az elsődleges szempontokat, és a fenti munkaoptimalizálás ezért lett félretéve. Az, hogy bármelyik felsorolt rendszer alkalmatlan lenne a testreszabásra, azt szerintem mindegyik fejlesztője egyenként kikérné magának. Persze különböző szinten mindegyik alkalmas a testreszabásra. A leírásodból viszont úgy tűnik, hogy nem értékelted azt, hogy mégis mit kellene testreszabni, és ez hogyan valósítható meg, hanem valamilyen (ráadásul külön telepített kiegészítő) funkcionalitás alapján úgy döntöttél, hogy ezzel nem érdemes foglalkozni.
10

Nagyon sok problémára van

littleBoy · 2005. Május. 5. (Cs), 15.37
Nagyon sok problémára van több elérhető OpenSrc megoldás-pl CMS-, ezek javarészt úgy keletkeztek hogy megnézték a fejlesztők hogy milyen elérhető megoldások vannak az adott problémára majd ha az nemtetszett nekik készítettek egy másik megoldást. Vannak voltak lesznek olyanok akik ezt jelezték a fejlesztőknek vagy csatlakoztak hozzájuk. Tehát azért mert valaki máshogy lát valait és inkább új megoldást gyárt a már meglévők foltozgatása helyet az nem rossz, az idő és a felhasználók majd eldönti melyik mire mennyire alkalmas. Így volt ez eddig is, és nem hinnám hogy idén tavasszal fog ez megváltozni... Nem tudom hogyha ha az informatikus társadalom nem lenne ennyire kreatív és megmeradt volna mindenre egy megoldásnál jobb lett volna-e az élet, de ebben az esetben akkor néhány amerikai Operációsrendszerfejlesztő cég miböl élne meg most:)
Üdv:(K)
11

Nem vitatható

Hojtsy Gábor · 2005. Május. 5. (Cs), 16.12
Én arra próbáltam rámutatni egészen röviden megfogalmazva, hogy tisztában kell lennünk azzal, hogy mik motiválják a választásainkat, különösen, ha elszántak vagyunk, hogy indokokat adjunk. Azzal nem értek egyet, hogy az első hozzászólásban vázolt indokok alátámasztják az új CMS fejlesztését, azzal viszont természetesen semmi problémám nincs, hogy valaki új CMS-t fejleszt, én is tettem már, amikor arra volt szükség.
3

MySQL vs. Oracle

Bártházi András · 2005. Május. 5. (Cs), 07.37
A MySQL valóban nem egy Oracle, de a tapasztalataim azt mutatják, hogy az egyszerű lekérdezéseket illetően sokkal gyorsabb. Én "dolgoztam már MySQLlel", s nem tudom, hogy botor dolog lenne-e berakni a fájlokat binárisan. Szerintem megvan a létjogosultsága, s azt erős túlzásnak tartom, hogy botor dolog lenne (értsd, tökmindegy, hogy fájlrendszerbe, vagy adatbázisba pakolod a fájlt). Szóval ez nem volt jó példa. És ahogy PP is írja, ez egy cserélhető, nem a rendszer részét képező modul, ha nem tetszik, nem kell használni. Pont a fájlkezelést illetően van a Drupalban több modul is, hogy a különböző igényeket kielégítse.

Mit tartasz a Drupal hátrányának a felhasználó és az adminisztrátor szempontjából? Nekem jó tapasztalataim vannak vele, egyedül a programozását sikerült felfognom nehezebben, a webes felülete szerintem eléggé áttekinthetőre és logikusra sikerült. De ha nem, lehet rajta változtatni :).

-boogie-
5

Re MySQL vs. Oracle

goshawk · 2005. Május. 5. (Cs), 13.35
Nem igazán értem ezt hogy értetted.
Szerintem megvan a létjogosultsága, s azt erős túlzásnak tartom, hogy botor dolog lenne (értsd, tökmindegy, hogy fájlrendszerbe, vagy adatbázisba pakolod a fájlt).


Nem azt mondom, hogy a fájlokat nem kell tárolni, ez nem botor dolog. Viszont az igen, hogy a teljes letöltés kezelő modul MySQL adatbázisba rakja a bináris tartalmat is. Erre jelenleg nem optimális a MySQL. Nem erre lett tervezve.

Ott van a rég bevált jó módszer, amikor feltöltöm a fájlt a fájlrendszer adott pontjára. Ez a módszer nem csak, hogy erőforrásilag kevesebbet igényel de optimálisabb is.

Elég ha arra gondolunk, hogy ha a fájl az adatbázis szerverben van benne fizikailag, akkor letöltéskor ugye a memóriába kerül a fájl teljes tartalma, ami akár lehet elég nagy is. Ez minden csak nem erőforrás gazdaságos.

Ja és ugye az adatbázisos fájltárolós módszernek van egy fájlméret határa is ha jól emlékszem (gondolom nem véletlenül).
Ezzel viszont megakadályozza a felhasználót, hogy bármilyen fájlt feltöltsön.
9

Én legjobban azt szeretem a

littleBoy · 2005. Május. 5. (Cs), 15.13
Én legjobban azt szeretem a MySQL-ben hogy ha egyszerre szeretnék kezelni vele ezerpárszáz lekérdezést akkor hogy ez jól működjön nem árt a libThread és kernel forrásába belejavítgatni. Szintén csodás dolog hogy egy mysqld kb 10-12 mega ramot eszik konstans és ha ebböl van nekem 1000 db-om..... míg egy Oracle elestén azt mondom neked van ennyi és az nem fog többet enni. Szintén aranyosak a nagy(több megás SQL Resultok kezelése) -pl: fileok, ezért van gondolom ilyen esetekben filméret korlát(de egy filmeket tartalmazó tábla esetén mit mond egy ASVA -Audióvizuális Művek Szerzői Jogait Védő Közhasznú Alapitvány). A több százezer rekordot tartalmazó táblákban a keresések is. Mindezek mellet én MySQL fun-nak tekintem magam mert olyan kis aranyos, de szvsz mindig meg kell nézni mit mire használunk. Értem ezelett azt is hogy nagy terheléshez nagy táblákhoz, nagy visszatérési értékek esetében lehet nem az teljesít jobban ami a kissebb terheléseknél nagyon jó eredményeket produkál. De gondolom aki egy ingyenes CMS rendszert használ nem akar Oracle-ra költeni... Tehát a lényeg: Próbáljunk meg mindnet arra használni amire való, és ha valamit már kinőttünk akkor nagyobbat kell venni és kész.

Üdv:(K)