ugrás a tartalomhoz

Az Orchard tartalomkezelő rendszer

Hupiedone · 2012. Május. 21. (H), 10.00

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 AppPool recycle 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.

 
1

Kérdések

Hidvégi Gábor · 2012. Május. 28. (H), 18.37
Nem vagyok ismerős ASP.NET-es fejlesztésekben, ezért lenne pár kérdésem:
  • 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.
2

You can run your downloaded

inf3rno · 2012. Május. 28. (H), 19.13
You can run your downloaded Orchard site using IIS, WebMatrix and IIS Express, or Visual Studio and the Visual Studio Development Server. The site has already been built and can be run without additional compilation.


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.)
6

Van ASP.NET a törzsanyagban

MadBence · 2012. Május. 31. (Cs), 01.27
Van ASP.NET a törzsanyagban is (elhanyagolható szinten), de van tárgy, aminek a keretein belül ASP.NET-et részleteiben meg lehet ismerni (WebForms-t, az MVC-re egyszerűen nincs idő).
3

Válaszok.

saxus · 2012. Május. 29. (K), 04.27
Csak általánosságban a .NET-ről:

- 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.
4

-

Trudy · 2012. Május. 29. (K), 06.53
.Net-nek van ingyenes cross-platform implementációja :
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)
5

-

Hupiedone · 2012. Május. 30. (Sze), 01.03
Kiegészítve az előttem szólók válaszait:
* 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.
7

Sziasztok! Lenne nekem is

Karvaly84 · 2012. Jún. 12. (K), 11.33
Sziasztok!

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?
8

Ez nagyrészt tőled függ. Én

virág · 2012. Jún. 17. (V), 10.59
Ez nagyrészt tőled függ. Én nem tudom mennyi tapasztalatod van, mennyire ismered a C#-t, vagy pl. a C++-t. Meg mit szeretnél? Webre fejleszteni? Asztali alkalmazásokat? Mobil alkalmazásokat? Szerintem egy alap C#-s tudást eléggé gyorsan fel lehet szedni, ha van gyakorlatod más nyelvekben és hajlandó vagy olvasni, mert egy letisztult, jól dokumentált nyelv. De .NET-ben ugye egy csomó más nyelv is elérhető, bár szerintem a C# a legjobb választás. Tudtommal vannak tárhelyek Magyarországon, de tuti nincs annyi mint LAMP-hoz. Egyébként miért mondtál le a PHP-ról? A PHP egy nagyon komoly, kipróbált, jól használható nyelv, semmivel sem alacsonyabb rendű mint a C#, vagy a Java...bár vannak akik szeretnék ezt a benyomást kelteni, de ez főleg tudatlanság és roszzindulat. Szerintem.
9

Hát nekem elegem lett a

inf3rno · 2012. Jún. 17. (V), 14.46
Hát nekem elegem lett a php-ból nagyon hosszú időre, és nem tudatlanságból, vagy rosszindulatból. Egyszerűen semmilyen téren sem teljesíti azokat a dolgokat, amiket én egy nyelvtől elvárok. Most nodejs-re váltok, kíváncsi vagyok, hogy mennyivel lesz jobb, mint a php.
10

Nem akarok delphoi jóssá

eddig bírtam szó nélkül · 2012. Jún. 17. (V), 15.30
Nem akarok delphoi jóssá válni, de tartok tőle, hogy azzal is érnek majd csalódások. Ráadásul közel sem tűnik olyan elterjedtnek, mint a PHP.
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.
24

A Ruby doksijaval pontosan mi

hron84 · 2012. Júl. 3. (K), 02.51
A Ruby doksijaval pontosan mi a baj? A core doksija itten van, es szinte minden gemnek reszletes doksija van. A Ruby On Rails keretrendszernek pedig meg tobb.

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.
26

ruby doksi

eddig bírtam szó nélkül · 2012. Júl. 3. (K), 05.43
Bocs, már nem emlékszem pontosan. Rég volt, mikor kezdtem volna egy kicsit közelebbről összeismerkedni vele és mindenütt amolyan... nem is tudom, talán félkésznek nevezhető állapotú doksiféleségeket találtam.
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)
11

Webre fejlesztenék első

Karvaly84 · 2012. Jún. 17. (V), 21.14
Webre fejlesztenék első sorban, C#-ban. Régebben Visual Basic-et kiprobáltam. Magát a C#-ot sztem egy nap alatt megtanulnám, engem a .NET api érdekel föleg MVC vonatkozásban.

É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ó.
12

A php nem alkalmas oo

inf3rno · 2012. Jún. 17. (V), 23.04
A php nem alkalmas oo nyelvnek, mert minden lekéréskor felépíti az egész környezetet, és csak utána kezd el foglalkozni magának az oldalnak a generálásával. Ha tényleg oo szemléletben akarod leprogramozni az oldalt sok kicsi osztállyal, akkor rengeteg felesleges munkát fog végezni a szervered. Nyilván egy méret felett túlterhelt lesz, aztán kezdhetsz azzal szórakozni, hogy hogyan osszad szét a funkciókat az egyes gépek között. Ha jól tudom java-ban viszont sokkal egyszerűbb fürtözni (bár ehhez már tényleg nem értek). Kisebb forgalmú oldalakhoz jó a php, ha van egy normális keretrendszered.
13

"A php nem alkalmas oo

Tyrael · 2012. Jún. 18. (H), 11.06
"A php nem alkalmas oo nyelvnek, mert minden lekéréskor felépíti az egész környezetet, és csak utána kezd el foglalkozni magának az oldalnak a generálásával."
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
14

ez minden interpretalt nyelv

inf3rno · 2012. Jún. 18. (H), 14.40
ez minden interpretalt nyelv eseteben igy van, nem a php sajatossaga.

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.
18

Ez nem ettől függ, nodejs-nél

Tyrael · 2012. Jún. 18. (H), 17.55
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.

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
25

Az appszerver temakor

hron84 · 2012. Júl. 3. (K), 02.54
Az appszerver temakor egyaltalan nem az ordogtol valo. Rubyban pl. van olyan is, hogy a Ruby-s webszerver (full HTTP szerver) fogadja a kereseket, es az elore felbootolt appnak, mint modulnak kuldi tovabb. Ezzel megsporolja az interpretacio koltseget, ami nem elhanyagolhato, ha a kodbazis nagy.
15

A Java is interpretált nyelv,

Joó Ádám · 2012. Jún. 18. (H), 16.46
A Java is interpretált nyelv, nem látom, ennek mi köze a shared nothinghoz.
16

Nem gondoltam, hogy ennek

inf3rno · 2012. Jún. 18. (H), 17.14
Nem gondoltam, hogy ennek nevet is adnak... :-)
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...
17

Hol írják?

Hidvégi Gábor · 2012. Jún. 18. (H), 17.45
Ezt hivatalos facebook oldalon olvastad? Azt ugye tudod, hogy az fb nem közvetlenül a php scripteket futtatja (bár magát a rendszert abban írták)?
19

Nem, ez csak egy commentben

inf3rno · 2012. Jún. 18. (H), 18.04
Nem, ez csak egy commentben volt valahol, hogy megvolt, hogy mekkora a fb gépparkja, meg a forgalma, és abból kiszámolta a gyerek, hogy ez átlagosan kb 100 lekérés/óra/gép. Most ebben nem tudom, hogy mennyi az igazság, de kíváncsi vagyok rá... (Egyelőre nem cáfolta senki.)
21

Sejtettem

Hidvégi Gábor · 2012. Jún. 18. (H), 18.44
Nem kell mindent készpénznek venni, amit interneten olvasol : )
22

Nagyon rossz

Poetro · 2012. Jún. 18. (H), 20.51
Az nagyon rossz aránynak tűnik. Ez azt jelenti, hogy egy gép 2400 kérést szolgál ki naponta... Azért ennek legalább 50-500 szorosát kellene minimum teljesítenie egy gépnek.
23

Persze, de a forrás nem

inf3rno · 2012. Jún. 18. (H), 20.56
Persze, de a forrás nem hiteles...
20

so-so, azért ugye java (meg

Tyrael · 2012. Jún. 18. (H), 18.11
so-so, azért ugye java (meg .net) esetében többnyire már az előfordított köztes bytekóddal dolgozik a virtuális gép.

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
27

.NET hosting

Hupiedone · 2012. Júl. 19. (Cs), 12.26
.NET-et is rengeteg helyen lehet már hostolni, LAMP árban is (bár ezalatt nem csak magyar szolgáltatókat értek: abból kevés van és relatíve drágák is). Viszont nem mindegy, mit akarsz rajta futtatni. Míg PHP-ben az a jó, hogy még a leggaagyibb szolgáltatónál is kapsz 32, vagy éppen 64 mega RAM-ot, és ebbe egy baromi nagy alkalmazás is belefér ASP.NET-nél könnyen lehet szűk keresztmetszet a RAM. Orchardnak kell legalább 256MB, és ennyit nem mindenhol adnak. Személyesen jó tapasztalataim vannak a Gearhost-tal (http://gearhost.com/) és mondták, hogy a Cytaniumot (http://www.cytanium.com/) is szereti az Orchard (ez utóbbi lényegesen olcsóbb, de persze kevesebbet is tud, mint a Gearhost).