ugrás a tartalomhoz

XML/XSL alapú free CMS

zakzag · 2007. Szep. 11. (K), 01.46
Hello!

Szétnéztem a tartalomkezelő motorok között és arra a következtetésre jutottam, hogy sajnos nem igazán találok nekem megfelelőt. Nem a képességekkel van problémám, hanem inkább azzal, hogy egy olyat szeretnék használni - vagy inkább továbbfejleszteni saját célra - ami szinte teljesen xml/xsl és php alapokon nyugszik. Azt vettem észre, hogy pl. a cms.lap.hu-n található CMS-ek egyike sem ilyen. Sajnos nem volt időm végignézni az egészet, de az általam megtekintettek mind más módon működtek (azaz semmi MVC pattern megoldású xml xsl template kezelés stb nem volt egyikben sem). Örülnék, ha valaki a segítségemre lenne egy ingyenesen letölthető, xml,xsl,php5 és db alapú CMS rendszer megtalálásában. Lehet hogy nem is létezik ilyen? Az eddigi munkahelyeimen szinte mindenhol ilyennel találkoztam, csak ugye azok saját - belső - fejlesztések voltak, és azokat lenyúlni, nos, nem a legetikusabb dolog. Az hogy miért keresek ilyet talán nem is kellene említeni, de azt gondolom, hogy mivel az xml és az xsl w3c szabványok és rengeteg alkalmazás készült hozzájuk, ráadásul mind a php4-5, a Firefox, Explorer vagy magára valamit is adó platform képes ezek kezelésére, nem is szólva a folyamatos fejlesztésükről és flexibilitásukról, elég nyilvánvaló, hogy ilyen irányba kellene elindulni. Azt már emlyteni sem merem, hogy ha még egy kis AJAX támogatás is lenne benne... Jól gondolom, hogy némelyik nagyobb free CMS rendszernek még akkor kezdték a fejlesztését, amikor ezekről a technológiákról max. álmodtak az emberek? Szóval? Tud valaki segíteni?
 
1

Flux CMS & sourceforge

minczerl · 2007. Szep. 11. (K), 08.18
Ez ilyennek tűnik: Flux CMS
De keress rá a sourceforge.net-en az XSLT+CMS szóra és ott is lesz a találatok között jópár.
Sőt találtam még egyet, ez is jónak tűnik Symphony web publishing system
2

beleugatok

Fraki · 2007. Szep. 11. (K), 08.31
Először is nem tudok ilyet mondani.

Viszont hogy miért nincs (vagy ritka vagy talán tényleg nincs), az a kérdés engem érdekel, és erről már volt is vitám itt mással. Az én felfogásomban egy MCV-rendszer már egyben template-rendszer is. Egészen konkrétan semmi értelmét nem látnám, ha én mondjuk a CakePHP-s view-kat csak azért xml-ben szolgálnám ki, hogy azt még egy xsl-lel tovább fordítsam. A business logic a controller lefutásának végén lezárul, és php-változókban szolgálja ki a view-kat. Annyi és olyanfajta view-kat (JSON ajaxhoz, xhtml, rss stb.) csinálok, amennyi nekem tetszik. Ez a fajta template-elés kifejezetten támogatott, és ebben a tekintetben az xslt egy ilyen framework berkeiben elveszti a jelentőségét (különösen a nem XML-formátumok, mint pl. a népszerű JSON, vagy egyszerűen a html mellett).

Az az érzésem, hogy valamelyest megragadtál az XML-hype-ban, ami az utóbbi időkben azért alábbhagyott. Ezzel nem az XML-ről mondok véleményt, csak annyit mondok, hogy ezt is túl lehet értékelni. Pont mint az xhtml-t is (erről egyre másra jelennek meg a jó kis cikkek). Nem az XML a világ (a weben sem).
3

haha

Fraki · 2007. Szep. 11. (K), 08.32
haha! megelőztek. Nem baj, az okosságaimat fenntartom.
4

Szűk látókör

janoszen · 2007. Szep. 11. (K), 11.31
Ez igaz lehet, ha weboldalakat kell kiszolgálnod előzőleg fölgyógyított tartalmakból. Abban a pillanatban, amikor össze kell dolgoznod más rendszerekkel, más adatforrásokat behúzni, más adatlekéréseket kiszolgálni mint egy böngésző kérdését.

Nem feltétlenül jó érvelés az sem, hogy akkor írj neki Java-s applikációt, hiszen sokszor kell olyat csinálni, hogy a PHP adatbázisához kell más rendszernek hozzáférni és közvetlenül hozzányúkálni pedig... lásd middleware koncepció.

Személy szerint én is az XSLT felé fogok orientálódni, mert szerintem, alsó hangon egy kellemes transzformációs lehetőség. Ha pedig integrált rendszerekben dolgozol akkor egy nagyon jó lehetőség a más rendszerekkel való együttműködésre anélkül, hogy foglalkozni kellene minden elemnek azzal, hogy milyen lekérésről van szó.
5

nem biztos, hogy azonnal "szűk a látókör"...

virág · 2007. Szep. 11. (K), 11.45
Mindent lehet jól és rosszul, jó helyen és rossz helyen is használni...az XSLT-t is. Vegyük pl. a Microsoft Sharepoint-ot (2007-es) ami elvileg full XSLT-ben csinálja az ún. webpartok megjelnését, struktúráját. Ami jó. Ami jó? Lenne ehhez egy-két megjegyzésem... ez egy olyan rendszer lett (nem csak emiatt a dolog miatt)amit az egész világon 54 darab ember képes átlátni (vagy kevesebb), nem beszélve egyéb hátrányoktól - pl. sebesség, de ne ragadjak le ennél a példánál. Tavaly volt dolgom egy CMS-el (PHP) a nevét nem írom le, egy cég saját fejlesztésű CMS-e volt. XSLT-vel és XML-el oldottak meg benne mindent amire úgy gondolták, hogy dejó lesz az nekik. Először én is el voltam ragadtatva attól (kb. 1 órát tartott ez az öröm), hogy fú mindent OOP csináltak meg és hmm, micsoda modern szemléletek zsúfolódtak itten össze. Utána lassan előjöttek a hibák, korlátok és a megnyúlt fejlsztési idők is - mivel a kedves fejlesztők a saját szemléletükbe úgy belebonyolódtak, hogy egy spagettistál szerű alrendszert sikerült beburkolniuk egy látszólag szép objektum rendszerbe - brr. Égnek állt a hajunk. Szóval, szerintem óvatosan azzal a "szűk látókör" jelzővel. Az XSLT ettől még jó, de nem is erről van szó hanem a felhasználási módokról és a tudásról.
6

Szvsz

inf · 2007. Szep. 11. (K), 16.02
Én is csak támogatni tudom az előzőleg hozzászólókat, persze mindnet meg lehet így is csinálni, viszont a legtöbb helyen csak bonyolítja a munkát, az előnyeit meg lehet phpvel pótolni. Gondolok itt mondjuk egy oldal kinézetének a váltására. Szerver oldali nyelvvel is ugyanolyan egyszerűen át lehet írni egy változót, ami a színt adja, és kirajzolni az oldalt, mint XSLTvel. Én egyedül arra tervezem, hogy használom az XSLTt, hogy hozzászólásokat, és cikkeket formázzak meg vele, mert ott tényleg számít, hogy csak a tartalmat mentsük el. (persze ott a BBCODE is, viszont az XSLTvel az ellenőrzés szerintem nagyon jól megoldható azzal, ha egy a user jogainak megfelelő XSLTt gyártok le, amin átfuttatom a bejövő XMLt, és csak a megengedett részek mennek tovább. Ezen túl igazából annyiban kell foglalkozni a dologgal, hogy hosszt nézünk, és mentünk.
7

Én sem...

janoszen · 2007. Szep. 11. (K), 19.08
Én sem támogatom hogy egy egyszerű 5 oldalas HTML lapnak XSLT alapot adjunk, ágyúval verébre. Csak bántotta a szemem a nem belegondolás, hiszen valószínűleg - legalábbis feltételezem - a kérdező nem véletlenül akart pont ilyen képességekkel bíró CMS-t. Személy szerint én most több olyan dologban is dolgozom, ahol elkerülhetetlen több (tucat) rendszer együttműködése és ennek csak egy része a webes megjelenés.
8

félreértés

Fraki · 2007. Szep. 11. (K), 20.07
Én elsősorban a template-elésről beszéltem, az xslt elsődleges webes alkalmazásáról. Ennek fényében értendő, amit mondtam, komplex rendszerek kommunikáljanak xml-ben, ezzel semmi gond nincsen. De itt a webről van szó, úgyhogy értelemszerűen webes kliensek kiszolgálása a lényeg. És alátámasztva látom az állításomat azzal a ténnyel, hogy az xslt tényleg látványosan nincs felkapva a CMS-sek és webes frameworkök világában. (Tkp. csak magyarázatot adtam erre a tényre.)

A kérdező említi az AJAX-ot, hát ott sincs felkapva az XML, ellenben fel van kapva helyette más.

Sőt, a fővonulat, az XHTML is a látszat ellenére eléggé megfeneklett stádiumban van.

S ismétlem, nem az XSLT vagy az XML világát bírálom ezzel, én is érdeklődöm a téma iránt, sőt nem is tartom hülyeségnek adott esetben egy XSLT-t bevonni bárhova, mert elegáns dolog; az az állításom csupán, hogy template-elés kérdésében, hiába elegáns és w3c, a kérdező túlértékeli a fontosságát, ami az ismert körülményből is látszik (bár ő ezt furcsállja), másrészt abból, hogy a sablonozás kérdését az architektúra köszöni szépen, megoldja.