Az Orchard tartalomkezelő rendszer
Ritkán érdemes ma már webes projektet valamilyen keretrendszer nélkül elkezdeni, hiszen a problémák többségét már rengetegszer megoldották, értelmetlen tehát, hogy mi is feltaláljuk a spanyolviaszt. A néhány ASP.NET MVC alapú tartalomkezelő rendszer közül most ismerjük meg az alig több, mint egy éve a v1.0-t elért, nyílt forráskódú Orchardot, ami egyszerre CMS és az ASP.NET MVC képességeit jelentősen kibővítő, tucatnyi egyéb nyílt forráskódú projektet felhasználó framework.
A Tartalom
Az Orchard minden téren nagyon nagymértékű rugalmasságot kínál, egész működése középpontjában pedig a nagybetűs Tartalom áll. Szinte kivétel nélkül minden tartalmi elem (content item). Egy tartalmi elem tetszőleges mennyiségű, cserélgethető tartalomrészből (content part) állhat. Ezek önálló entitások, melyek tárolhatnak adatokat, ezeket szerkeszthetővé, megjeleníthetővé tehetik. Így például ha azt akarjuk, hogy a blogbejegyzések alatt legyen egy like-gomb, akkor készítünk egy tartalomrészt, mely ennek megjelenítéséért felel, és hozzácsatoljuk a BlogPost tartalomtípushoz (content type).
A
Page tartalomtípus alapértelmezett felépítése: Title Part, Common Part és Body Part tartalomrészek (mindez egy friss Orchard installáció nyitólapján)
Hasonlóképpen csatolhatunk mezőket, widgeteket tartalomtípusokhoz. Ezzel a rendszerrel egymástól független tartalomrészekből akármilyen tartalomtípust felépíthetünk.
Az már szinte csak mellékes, hogy az Orchard mind a kódban lévő sztringeket, mind a felhasználó által kezelhető tartalmakat tekintve lokalizálható. Így könnyen üzemeltethetünk többnyelvű oldalakat.
Mérnöki munka
Fejlesztőként valószínűleg (a C# nyelven íródott) forráskódból fogjuk az Orchardot futtatni és telepíteni. Ragadjuk meg az alkalmat, hogy a modulfejlesztésen túl is betekintsünk a működésébe! Egy aprólékosan, valódi szoftvermérnöki precizitással kidolgozott rendszert fogunk látni. Az egyetlen hibája talán az, hogy a nyitó kapcsos zárójelek nem külön sorban találhatók…
Az osztályok függőségeiket természetesen dependency injectionnel kapják meg, így az Orchardban lényegében minden kicserélhető. Ezen kívül is lépten-nyomon modern fejlesztői megoldásokkal és a jelenlegi legjobb gyakorlat alkalmazásával találkozunk.
Bővíthetőség
Az Orchard funkcionalitását modulokkal és témákkal bővíthetjük. Ez a kettő nagyon hasonló fogalom és nagy az átfedés; a lényeg mindenesetre az, hogy a modulok jellemzően önálló funkcionalitást (pl. tartalomrészeket) tartalmazó bővítmények, míg a témák leginkább csak CSS-t, esetleg némi HTML-t (Razor view-k formájában) tartalmaznak.
Sőt, igazából az Orchardban szinte minden modul a rendszermagot kivéve, így mi döntjük el, pontosan mennyi mindent szeretnénk használni.
A modulok gyakorlatilag MVC Area-k (az egyszerűbb témák nem, de témák is tartalmazhatnak bármit, amit a modulok, így pl. saját vezérlőket is), ha tehát az ASP.NET MVC alapjaival tisztában vagyunk, Orchard modult is tudunk írni. Érdemes azért persze legalább az Orchard alapvető fejlesztőknek nyújtott szolgáltatásaival megismerkedni, mint ami a nagyon könnyen használható dependency injection, az adatbázis-séma változtatásait végrehajtani hivatott migrációk vagy az adatelérést szolgáló service class-ok.
Na de mi van a csomagban?
Nyilván nem akarnánk mindent megírni az alapvető funkciókon túl, akármennyire is remek a keretrendszer. Az Orchard rendszermagja, illetve a beépített modulok már rengeteg funkciót tartalmaznak:
- Teljeskörű felhasználókezelés
- Sok tartalomtípus (pl. lap, blogbejegyzés)
- Címkézés
- Hozzászólások
- Minden gyakori tartalom kezelésére alkalmas mezők és részek
- Az oldal tartalmának kimentésére képes exportálás és importálás
- Keresés és indexelés
- Médiakezelő
- Több tartalmilag független weboldal hosztolása egyetlen installációból (ami így pl. kevesebb memóriát igényel, mint ha különálló installációk lennének)
- Egyszerű modultelepítés az adminfelületen
- Parancssori program, ahonnan minden lényeges adminisztrációs feladatot el tudunk végezni
- Az adminfelületen szerkeszthető események (amik pl. tartalom mentésekor, törlésekor futnak le) és ezekhez tartozó eseménykezelők (pl. e-mail küldés). Ennek segítségével pillanatok alatt beállíthatjuk például, hogy e-mail értesítést szeretnénk kapni új hozzászólásokról, blogbejegyzésekről.
- Az
AppPoolrecycle utáni hidegindítás felgyorsítása - És még rengeteg minden…
Szerencsére van választék letölthető, a közösség által fejlesztett kiegészítőkből is, így jó eséllyel nekünk már csak a frontend testreszabásával kell foglalkoznunk egy portál lefejlesztésénél. Az Orchard Gallery ugyanis jelenleg 380 modult és témát tartalmaz. Fontos megjegyezni, hogy ezek mind nyílt forráskódúak, így teljesen reklámmentesek és ingyenesek.
Nyílt forrás, közösségi döntéshozatal
Az Orchard projektet a Microsoft indította el még 2009-ben, így Microsoft alkalmazottak is fejlesztették. A projekt emellett a kezdetektől fogva nyílt forráskódú volt. 2011-ig ennek ellenére a fejlesztési irány kijelölése lényegében a Microsoft belső döntései nyomán történt, melyeket a csökkenő méretű fejlesztőgárda valósított meg.
2011 nyarán a projekt irányítását formálisan is átvette a köré gyűlt közösség: megalakult az ún. Orchard Steering Committee, mely szabadon, egy évre választott tagokból és elnökből áll. A bizottság hetente ülésezik (mivel a világ minden tájáról vannak tagjai, ez természetesen online történik), a tagok végignézik az új hibajelentéseket és az egyes csapatok vezetői beszámolnak a fejlesztés előrehaladásáról. Az új fejlesztések nagy részét most már ugyanis a külső fejlesztőkből álló feature team-ek végzik: az 1.4-es verzió például tizenhét résztvevő munkáját dicséri. Egy főállású, a Microsoft alkalmazásában álló (aki egyébként az ASP.NET MVC és Web API csapatban is tag) fejlesztője azért még van az Orchardnak.
Tetszik, hogyan tovább?
Orchard Magyarország néven van magyar weblapja is a projektnek, ahonnan magyar nyelvű segédleteket, tippeket és a magyar fordítást előtelepítve tartalmazó csomagokat tölthetünk le. Részletes (de a rendszer mérete miatt bőven nem teljeskörű) dokumentációért és a nemzetközi fórumért viszont mindenképp érdemes az orchardproject.net-et gyakran látogatni.
Az Orcharddal való ismerkedés nem egy rövid folyamat, mert rengeteg tanulnivaló van. Ha a nehéz kezdeten túljutunk, akkor viszont lassan feltárul előttünk a határtalan kreativitást támogató keretrendszer minden előnye.
A kommentekben pedig lehet kérdezni is bátran.
■
Kérdések
- miután lefordítod a programot, natív kódként fut a szerveren?
- tartalmaz beépített webszervert, vagy pedig minden IIS-en keresztül megy?
- milyen szoftverek szükségesek a Windowson kívül ahhoz, hogy ha valaki ilyen alapon szeretne dolgozni, és ezek kb. mennyibe kerülnek?
- milyen adatbázisokhoz képes kapcsolódni az orchard?
- vagy ODBC-n keresztül megy az egész, teljesen transzparensen?
- egyetemen tanítanak ASP.NET-et?
- mennyire könnyű dokumentációt találni annak, aki meg szeretné ismerni a nyelvet?
A válaszokat előre is köszönöm.You can run your downloaded
BME-n tanítanak C#-ot, gondolom ebbe valamilyen szinten az ASP.NET is bele tartozik. (Mondjuk nem vagyok tájékozott ebben, csak pár info-s tárgyat vettem fel, amikor oda jártam.)
Van ASP.NET a törzsanyagban
Válaszok.
- Nem, köztes (CIL) kódra fordul - mint a Java, amelyet a JIT-ter fordít natív kódra első indításkor. Maga a C# (mint a .NET húzónyelvve) menedzselt, erősen típusos, OOP nyelv egyébként. Sok mindenben hasonló, mint a Java,
- AFAIK IIS kell hozzá, viszont fejlesztéshez nem feltétlen szükséges.
- Visual Studio-ra biztos. Van Express Edition, de... Komoly munkára egy Prof-ba minimum érdemes beruházni. Egyébként érdemes körbenézni a VS-hez elérhető kiegészítőknél (új kedvenc pl. a Debugger Canvas), kb. a szánalom az átlag PHP-s eszközök összehasonlítva mondjuk egy VS-sel (mondjuk egy VS vs PDT Eclipse + xdebug + egyebek). Igaz, cserébe nem túl olcsó.
- Nem tudom. De ha normálisan van implementálva és az alap interface-kat használja, akkor szerintem bármely azt megvalósító adatbázissal használható.
- Nem tudom.
- Egyetem függő. C#-ot tanítanak sokfelé. Viszont ugye .NET-et nem csak C#, VB.NET vagy C++/CLI nyelven lehet kódolni (na meg egyéb technológiák, mint ASP.NET, WPF, stb.) na meg ugye az egyéb 3rd party nyelvek. C# egyébként nagyon jól kitalált, letisztult nyelv. Viszont egy átlag PHP-s rendszerhez képest mások a körülmények (pl. itt nem szokás egy hashmapba beletúrni mindent, mint ahogy PHP-nál szokás egy array-al.). Magát az ASP.NET-et viszont nem ismerem.
- MSDN marhajó. Van egy-két ritkábban használt rész, amely kevésbé van ledokumentálva, de az ritka. Inkább az az egyik kihívás még, hogy tudd, hogy mi van még a .NET-ben, mert rengeteg sok mindent nyújt még a .NET FW, vagy maga az ASP.NET is. Ezen kívül sok anyag és jó könyv érhető el még .NET témakörben valamint jó közösségi oldalak. (Pl. rengeteg kérdésemre többnyire kész megoldást találtam googleból kiindulva - esetek jó részében - a Stack Overflowon.
Amit még kiemelnék:
- Jó osztálykönyvtár, ráadásul sokat fejlődik.
- Magát a keretrendszert és a JIT-tert is folyamatosan optimalizálják.
- Jó eszközkínálat hozzá (szvsz. ez ma már fontosabb, mint maga a nyelv.)
- Edit & Continue (futás közbeni kódszerkesztés, módosítás). Ugyan a Java HotSwaptól még messze van - amit nem értek miért, hisz az infrastruktúra adott lenne hozzá - de még így is ég és föld ahhoz képest, amit PHP-ban lehet tenni. Ha valami hosszabban futó folyamat, akkor főleg.
Ami hátrány lehet:
- Szoftverre márpedig költeni kell.
- Más környezet, más szokások. (Nincs mese, meg kell ismerni, néhol szokni - egyébként sose árt valami újat megismerni).
ASP.NET-tel nincs konkrét tapasztalatom. PHP-ban webre és .NET-ben desktopra fejlesztek jelenleg nagyjából párhuzamosan. Plusz hobbiból néha Java-zok, de az kimerül általában egy Minecraft mod reszelésében.
-
Mono project
Eredetileg a Novell kezdte el fejleszteni egy ideje pedig egy belőlük kivált független csapat fejleszti tovább. Monoval lehetőség van ASP.NET alkalmazásokat Apache és Nginx alól is futtatni. Mono-hoz szintén hozzá tartozik egy saját fejlesztői környezet a MonoDevelop amiben megtalálható a Visual Studio számos szolgáltatása (pl. IntelliSense)
-
* Szerverre való deploy-nál az Orchard rendszermagja lefordul (CIL-re), a modulok viszont sima C# kódfájlok maradnak. Ezeknek a fordítását az Orchard menet közben indítja el.
* Kell hozzá IIS, de fejlesztéshez valóban elég a Visual Studio beépített webszervere (Cassini). Megjegyzem, mindenből (IIS-ből és SQL Serverből is) van ingyenes Express verzió. Viszont ha műszaki egyetemista vagy, jó eséllyel az összes teljes szoftvert letöltheted ingyen az Academic Alliance keretében.
* Ahogy Saxus mondta, VS ajánlott, de csak szűken vett fejlesztéshez. Az Orchard előrefordított változata ugyanis WebMatrixon keresztül telepíthető és futtatható, modulok és témák kódját (akár a C#-ot is, de azért legfeljebb csak a CSS-t, JS-t, HTML-t ajánlott) a beépített szerkesztőjével tudod módosítani is. Magyarán ha csak apróbb testreszabásos elvégzése a cél, elég ez is.
* Adatbázis-kezelésre az Orchard az NHibernate ORM rendszer használja. Így - elvileg - az alapértelmezett MS SQL Serveren kívül (amiből tud az adatbázist egy darab fájlban tároló SQL Server Compactot is használni) mást is támogat. Gyakorlatilag ennél azért komplexebb a dolog; azt tudom, hogy a MySQL támogatáshoz fejleszteni kellett, de valaki megcsinálta már. Ha fejleszteni kész az ember, akkor, mivel szinte bármi cserélhető, bármilyen adattárolási réteg implementálható. Mondjuk sok értelmét én nagyon nyomós ok nélkül ennek nem látnám.
* Kifejezetten ASP.NET egyetemi oktatásról nem tudok, tanfolyamok vannak. Pl. az Óbudai Egyetem Neumann karán is C# a fő nyelv.
* Dokumentációval eddig nem volt soha bajom a .NET terén (az MSDN-en fent van mindennek a dokumentációja, sok tutorial is, de amúgy is rengeteg van), az Orchard dokumentáció viszont bár jó minőségű, ami megvan, de rengeteg mindenre nem terjed ki. Szerencsére van közösségi munkavégzés e téren is, így elképzelhető, hogy hamarosan teljes API referencia is lesz.
* +1 Mono támogatása az Orchardnak elvileg van, de nem vagyok benne biztos, hogy a) teljeskörű b) megéri a pluszmunkát. Nagyon olcsón van már olyan ASP.NET hosting, ahol jól megy az Orchard (lényegében LAMP hosting árban), pedig nem fut mindenen.
Sziasztok! Lenne nekem is
Lenne nekem is pár gondolatom: A bejegyzést múltkor olvastam. Most viszont úgy pár napja olyan dolgok motoszkálnak a fejemben, hogy lehet kapitulálnom kéne :D
Először is próbáltam olyan irányba fejleszteni magam, ami közel áll a nyílt forráshoz, és a Linuxhoz. Természetesen a PHP volt az első, és az alapok után le is mondtam róla. Ezután kísérleteztem a Java-val, de itt üzemeltetési problémákba ütköztem. Tárhely szinte sehol, VPS van de nem vagyok rendszergazda és drága.
Azt szeretném kérdezni ASP.NET, és Visual Studio-t mennyi idő alatt lehet elsajátítani? Könyvek internetes anyagok mennyire találhatók? Illetve lehet e egy Orchard-ot egy sima tárhelyen úgy üzemeltetni, hogy nekem ne keljen foglalkoznom a szerveroldali dolgokkal, illetve kik szolgáltatnak Magyarországon ASP.NET tárhelyet?
Ez nagyrészt tőled függ. Én
Hát nekem elegem lett a
Nem akarok delphoi jóssá
De az is igaz, hogy bármivel kezd az ember, mindennek vannak komoly hátrányai, amikkel együtt kell élni.
Saját tapasztalat: python. Szép, jó, de túl sok szabadságot enged a programozónak, amivel esetenként könnyű visszaélni. Ráadásul elterjedt webes keretrendszerként egyedül a djangoról tudok, ami hát... finoman szólva nem a következetesség mintaképe.
Ruby. Szép, tképp szeretnivaló nyelv, de a doksija... Lehet, hogy én kerestem rossz helyen, de amikor már a kitalálójától is olvastam olyat, hogy "minek dokumentálni, ott a forráskód!"... És itt sincs túl nagy választék, ha webre akarsz fejleszteni.
Ezek mellett a PHP még mindig egész jónak tűnik, részben az OO megvalósítása, részben pl. az adatbázis driverek miatt.
(pythonhoz a mysql driver véleményem szerint egy agyrém, legalábbis a PHP-s PDO-val összevetve)
Persze mindez elég szubjektív, én meg egyiket sem használom élesben.
A Ruby doksijaval pontosan mi
Ezen felul kettonna konyv, cikk, tutorial, blog, satobbi szol a Ruby-rol. En eddig barmilyen problemaba szaladtam bele Ruby-val kapcsolatban, nem volt olyan, hogy ne talaltam volna megoldast. Illetve de, volt, amikor egyszer-parszor beneztem a szintaktikat. De hat azt barhol es barmikor el lehet kovetni, PHP-val is volt mar ilyen.
Python: regebben foglalkoztam vele, mostanaban nem annyira. Mindenesetre ma mar szerencsere a MySQL connection nem csak a MySQLdb-bol all, van SQLAlchemy is, ami egy egesz jo API-t ad tudtommal, illetve hallottam mar ActiveRecord alapu megvalositasokrol is. Nyilvan a donto tobbseguk a MySQLdb felett mukodik - de hat annak a mukodesevel tul nagy baj nincs, az API-ja meg tenyleg pocsek, ezt elismerem.
PHP: nekem ketto bajom van vele, ebbol az egyik az OOP, a masik pedig a platform maga. Az OOP-val az a gond, hogy ez utolag lett hozzaadva a nyelvhez, emiatt egy csomo eroszakolt dolog van, hogy lazan tipusos legyen, de megis OOP. A platfommal pedig a kovetkezetlenseg es az allando valtoztatgatas a bajom. Ha nem egy 3 soros PHP kodot irok, mar ki kell nyitnom a php.net-et, mert annyira illogikus az egyes fuggvenyek parameterezese. Lehet, hogy a hiba bennem van, de pl. a Ruby stdlib sokkal jobban van felepitve. Persze, most mar gorgetni kell magunk elott az egeszet.
ruby doksi
Ráadásul valahol olvastam egy olyat a nyelv atyjától/kitalálójától/fejlesztőjétől, hogy "Minek a dokumentáció? Beszéljen a forráskód!" - amiben valahol igaza van, csak így elég macerás megtanulni valamit. Úgyhogy hagytam a fenébe és elkezdtem a pythonnal játszani.
Nyomtatott könyvek nem nagyon jöhettek szóba, amit vettem, az valami hihetetlenül gagyi. Nem is tudom, megvan-e még vagy már kidobtam.
-----
PHP vs Ruby: előbbivel kapcsolatban igazad van, néha nekem is égnek áll tőle a hajam (pl. nem csak a paraméterezéssel van gond, sok esetben a függvények elnevezése sem túl következetes)
Webre fejlesztenék első
Érdekel a Visual Studio IDE, és ami benne van, mennyi idő még ki ismeri az ember.
Kapcsolodó technologiák... MSBuild, meg ami még kell hozzá. SQL Server emnnyire macera. Dokumentációs eszközök vannak e vagy vadászni kel a rosszabbnál rosszabb megoldásokat, mint pl JavaScript-hez.
A PHP-t azért nem szeretem mert nem következetes sztem. Egyszer camelCase egyszer underscore minden verzió más, plusz nekem egy kicsit gányolásnak tűnik. Maradtak volna az eredeti tervnél és kreáltak volna egy rendes OOP nyelvet aszt heló.
A php nem alkalmas oo
"A php nem alkalmas oo
ez minden interpretalt nyelv eseteben igy van, nem a php sajatossaga.
viszont ez a hatranya egyben az elonye is: mivel igy rakenyszeriti a fejlesztot a shared-nothing architechturara, ezert egy atlag php alkalmazas skalazhatova tetele abbol all, hogy a sessionoket atrakod valami elosztott rendszerbe.
ezzel szemben egy java alkalmazas szervernel kulon tudomanyag, hogy hogyan irj olyan alkalmazast ami skalazodik, es nem dependal arra, hogy minden kiszolgalast vegzo szal lokalisan ugyanazon a szerveren fut.
Tyrael
ez minden interpretalt nyelv
Ez nem ettől függ, nodejs-nél fel tudod építeni a környezetet, és az eseménykezelőkkel tudja várni a kéréseket. PHP-nél ha jól tudom a legtöbb, amit tehetsz, hogy letárolod valahova szerializáltan az aktuális állapotot, aztán visszaolvasod... Persze javíts ki, ha tévedek, nincs akkora tapasztalatom a php optimalizálásában.
Ez nem ettől függ, nodejs-nél
igen, interpretalt nyelvekben is lehet irni egy vegtelen ciklust, ahol fogadod a bejovo kapcsolatokat.
php-ban is voltak/vannak probalkozasok erre, de sajnos/szerencsere nem terjedt el tulsagosan, koszonhetoen foleg a phpban sok esetben elofordulo memoriaszivargasnak (amivel kapcsolatban rengeteget fejlodott a nyelv, pl. 5.3-ban megjelent a gc a korkorosen foglalt memoria felszabaditasara).
de ertem hogy mire gondolsz, egy csomo mas interpretalt nyelvben vannak reszmegoldasok arra, hogy alkalmazasszervert/event machine-t csinaljon az arra vetemedo (EventMachine rubyban, Twisted pythonban, etc.)
ettol fuggetlenul ezek a megoldasokan en csak nagyon specialis felhasznalasi teruleteken tartom eletkepesnek.
Tyrael
Az appszerver temakor
A Java is interpretált nyelv,
Nem gondoltam, hogy ennek
Azt írják, hogy emiatt fb-nál egy szerver óránként kb 100 kérést szolgál ki, ami azért elég gáz...
Hol írják?
Nem, ez csak egy commentben
Sejtettem
Nagyon rossz
Persze, de a forrás nem
so-so, azért ugye java (meg
de meggyőztetek, rossz döntés volt az interpretált tulajdonságot ide keverni, vannak bőven olyan megoldások, ahol interpretált nyelvben támogatott az appserver felállás.
Tyrael
.NET hosting