CMS, Framework vagy saját fejlesztés?
Már egy ideje aktuális lenne egy saját oldal létrehozása.
Az oldal egy olyan portál lenne, ahol alapvetően egy hatalmas katalógusból lehet rendelni felhasználók által feltöltött dolgokat (apróhirdetés+webshop. mint pl.: e-bay, vatera), de kiemelt fontosságú különböző témába vágó cikkek, hírek, események magazin szerű megjelenítése is, továbbá különböző közösségi funkciók is lennének, mint például az egyes termékek, vagy eladók/vevők értékelése, egyéb párbeszédek, illetve nyílt fórum további kérdésekről nyitott eszmecserékhez.
A feladat elméleti háttere már ki van dolgozva. Ide értve az adatbázis szerkezetet, a különböző funkciók működését, a fő- és almenüpontokat és egyéb működési kérdéseket. Elkészült továbbá a komplett template is, amely szinte minden oldal részletes megjelenítését tartalmazza.
A problémát jelenleg a php kód jelenti. Lassan két hónapja próbálom megtalálni az ideális megoldást, amely megfelelő sebességet és biztonságot jelent akár többezer látogató esetén is.
Próbáltam több framework-öt is (yii, symfony, codeigniter) de ezek számomra nem tűntek túl hatékonynak. A kódjukat nézve arra jutottam, hogy ezek a programozó dolgát tényleg egyszerűsítik, cserébe viszont rengeteg ponton lassítják az oldalt.
Gondoltam arra is, hogy valamely CMS-t érdemes lenne felhasználni. Megnéztem a drupal-t kicsit közelebbről és úgy tűnik ez sem nyújt szinte semmi olyat, amivel a feladatot könnyedén megoldhatnám. Ilyen-olyan modulokat kellene letölteni, majd továbbfejleszteni és rávenni bizonyos funkciókra. Akkor inkább már framework vagy saját fejlesztés.
A fentiek alapján nekiálltam egy saját fejlesztésnek. Ezen a ponton szinte csak az MVC/OOP megoldást preferálja mindenki. Nagyjából értem, hogy ez miért jó, de itt is azt gondolom, hogy sokkal inkább a fejlesztő dolgát könnyíti meg a teljesítémény rovására. Ezért kialakítottam egy olyan egyszerű rendszert amely procedurális alapon, de mégis MVC szerint szervezve nagyjából OOP szerint, de nem php objektumokkal dolgozik. Lényegében egy könyvtár/fájl struktúra. Ez viszont tényleg csak néhány alapvető dolgot, mint például az aktuális nyelv, a választott template és a kért vezérlő irányítását jelenti.
Ti mit gondoltok, mi lenne a legjobb módszer egy igazán összetett oldal gyors kiszolgálására? Készítsek egy rakás osztályt, ami lassítja a működést, de gyorsítja az én munkámat? Válasszak egy framework-öt, amely sosem lesz olyan gyors mint egy saját fejlesztés, de könnyebb vele haladni? Vagy fejlesszek ki egy objektum orientált php rendszert, amely ugyan jól struktúrált, de mégis lassabb mint a procedurális megközelítés? Vagy maradjak a procedurális, fájl/függvény alapú megoldásnál?
Egyébként a saját fejlesztésben most ott akadtam el, hogy a template master fájljában döntsem el, hogy mi jelenjen meg, vagy a vezérlő valahogy (de hogy?) mondja meg a masternek, hogy mit mutasson?
■ Az oldal egy olyan portál lenne, ahol alapvetően egy hatalmas katalógusból lehet rendelni felhasználók által feltöltött dolgokat (apróhirdetés+webshop. mint pl.: e-bay, vatera), de kiemelt fontosságú különböző témába vágó cikkek, hírek, események magazin szerű megjelenítése is, továbbá különböző közösségi funkciók is lennének, mint például az egyes termékek, vagy eladók/vevők értékelése, egyéb párbeszédek, illetve nyílt fórum további kérdésekről nyitott eszmecserékhez.
A feladat elméleti háttere már ki van dolgozva. Ide értve az adatbázis szerkezetet, a különböző funkciók működését, a fő- és almenüpontokat és egyéb működési kérdéseket. Elkészült továbbá a komplett template is, amely szinte minden oldal részletes megjelenítését tartalmazza.
A problémát jelenleg a php kód jelenti. Lassan két hónapja próbálom megtalálni az ideális megoldást, amely megfelelő sebességet és biztonságot jelent akár többezer látogató esetén is.
Próbáltam több framework-öt is (yii, symfony, codeigniter) de ezek számomra nem tűntek túl hatékonynak. A kódjukat nézve arra jutottam, hogy ezek a programozó dolgát tényleg egyszerűsítik, cserébe viszont rengeteg ponton lassítják az oldalt.
Gondoltam arra is, hogy valamely CMS-t érdemes lenne felhasználni. Megnéztem a drupal-t kicsit közelebbről és úgy tűnik ez sem nyújt szinte semmi olyat, amivel a feladatot könnyedén megoldhatnám. Ilyen-olyan modulokat kellene letölteni, majd továbbfejleszteni és rávenni bizonyos funkciókra. Akkor inkább már framework vagy saját fejlesztés.
A fentiek alapján nekiálltam egy saját fejlesztésnek. Ezen a ponton szinte csak az MVC/OOP megoldást preferálja mindenki. Nagyjából értem, hogy ez miért jó, de itt is azt gondolom, hogy sokkal inkább a fejlesztő dolgát könnyíti meg a teljesítémény rovására. Ezért kialakítottam egy olyan egyszerű rendszert amely procedurális alapon, de mégis MVC szerint szervezve nagyjából OOP szerint, de nem php objektumokkal dolgozik. Lényegében egy könyvtár/fájl struktúra. Ez viszont tényleg csak néhány alapvető dolgot, mint például az aktuális nyelv, a választott template és a kért vezérlő irányítását jelenti.
Ti mit gondoltok, mi lenne a legjobb módszer egy igazán összetett oldal gyors kiszolgálására? Készítsek egy rakás osztályt, ami lassítja a működést, de gyorsítja az én munkámat? Válasszak egy framework-öt, amely sosem lesz olyan gyors mint egy saját fejlesztés, de könnyebb vele haladni? Vagy fejlesszek ki egy objektum orientált php rendszert, amely ugyan jól struktúrált, de mégis lassabb mint a procedurális megközelítés? Vagy maradjak a procedurális, fájl/függvény alapú megoldásnál?
Egyébként a saját fejlesztésben most ott akadtam el, hogy a template master fájljában döntsem el, hogy mi jelenjen meg, vagy a vezérlő valahogy (de hogy?) mondja meg a masternek, hogy mit mutasson?
Pénz = idő
Inkább a template betöltésén aggódnék, mert általában ott veszít a legtöbb sebességet egy weboldal betöltése. Érdemes lefuttatni a Google által kifejlesztett (online) PageSpeed programot, meg fogsz lepődni mennyi lehet spórolni csak a megfelelő beállításokkal, akár a betöltési idő 70%-át is (!!!):
http://pagespeed.googlelabs.com/
Szóval a sebesség miatt nem aggódnék a php kód esetében, mert az általában nehezen észrevehető különbséget produkál, ha esetleg pontosan kiméred a betöltés sebességét, akkor lehet valamennyi különbség. Meg nyilván függ a tárhelyed kapacitásától is, de az szintén nem php kérdés.
Viszont ennél sokkal fontosabb kérdés, hogy milyen gyorsan tudsz haladni a programozással, mert nyilván annál hamarabb kezd pénzt termelni a weblapod, és minél több fejlesztést tudsz csinálni, annál funkcionálisabb lesz az oldalad, és annál több visszatérő látogatód lesz, ami megint csak a pénzt termeli.
Az általad felvázolt kőbaltás megoldás nyilván elég gyors, egyszerű, és átlátható. Azonban el fog telni 1-2 év, és rájössz, hogy néhány új funkció leprogramozása napokba vagy akár hetekbe is beletelik, jóllehet ugyan ezt egy megfelelően felépített oop-s rendszerben vagy keretrendszerben egy délelőtt alatt meg tudtad volna csinálni.
Szóval szerintem inkább most tanuld meg a megfelelő technikákat. Ha esetleg nem tetszenek a framework-ök, akkor is legalább tanuld meg az oop-s mvc-s technikákat, de előbb utóbb nem árt egy framework használata. Pl. próbáld ki a zend-et, amelyet a php fejlesztői csinálnak, az az egyik legnépszerűbb, de van aki másra esküszik.
Most pár nap vagy pár hét tanulással később hónapokat vagy akár éveket is nyerhetsz a fejlesztésben! A most tanulásra fordított idő később sokszorosan megtérül.
Összegezve: mindenképpen saját fejlesztésben / frameworkben gondolkodj, de csak akkor, ha hajlandó vagy kitanulni a megfelelő technikákat. Meglévő CMS rendszerrel tapasztalatom szerint nem érdemes ilyen bonyolult rendszerbe kezdeni, mert lehet, hogy alapvető elgondolásokat máshogy szeretnél. Szóval lehet, hogy az egészet át kellene írni ahhoz, hogy neked jó legyen, annak meg már nincs értelme. Én is azért kezdtem el php-t és a kapcsolódó technikákat kitanulni, mert voltak olyan problémák, amelyeket nem tudtam egy meglévő cms rendszerrel megoldani, vagy csak óriási munka árán lehetett volna.
Ami kimaradt
Ugyanakkor összetett desktop és szerver alkalmazások fejlesztése után kicsit ágyúval-verébre esetnek tartom a php-s objektumrendszert, hiszen végülis egy-egy oldal "legenerálása" a feladat, lehetőleg nagyon rövid idő alatt. Ehhez objektumokat példányosítani nem sok értelmét látom. Az kétségtelenül igaz, hogy a saját dolgomat könnyítem meg ezzel. Sajnos arra vonatkozóan nem találtam hiteles mérési eredményeket, hogy egy komplexebb feladat objektum alapon mennyivel lassabb mint procedurálisan.
Ugyanakkor mint említettem nézegettem framework-öket, és pl. a codeigniter forráskódjában számos helyen találkoztam szerintem felesleges bonyolítással. Egy példa: include előtt mindig ellenőrzi, hogy fizikailag létezik-e a fájl és olvasható-e. Csak ezután include-olja. Egy jól tervezett rendszer esetén ez egy baromság, hiszen ha nincs meg az include akkor amúgy is vége a történetnek. És még számtalan ilyen apró dolog van ami nem tetszik.
De ha már itt tartunk egy dolog a mai napig nem világos az MVC tekintve. Melyik rész az ami meghatározza, hogy az aktuális page milyen elemekből épüljön fel? A controller vagy a view? Ha a view, akkor ez azt jelenti, hogy minden controllernek kell legalább egy, de inkább több view fájl, ami összességében rengeteg. Ki győzi ezt karbantartani? Ha a controller mondja meg a tartalom "blokkokat", akkor ezt milyen módon tudatja a view-val? Egyszerűen include-olja ami kell? Ez komplexebb oldalnál nem megy.
Számos példát láttam arra, hogy a (master) view közepén van egy sima echo $content. De ha a content több elemből kell felépüljön és esetleg több controller alapján, akkor mi van?
Megmondon őszintén kicsit most kifogott rajtam ez a view-controller témakör, mert szinte mindenhol csak egy adott rendszerhez van tutorial, vagy általános formában szinte csak hello world van, ami nagyon kevés.
Sebesség
Ez engem is érdekel,
miért éppen php?
Ezt a belassulás dolgot nem
Examiner.com
C
De ha a content több elemből
Általában a controllerek egy kérést kapnak, amit validálnak, ha valid, akkor végrehajtják, aztán vagy válaszolnak valamit, vagy nem. Ha van válasz, akkor annak tartalmát a view kell, hogy összerakja a controllernek ahhoz semmi köze. Az egyes részeket helperek rakják össze. Szóval mindig csak egy controllert hívsz. Ha több controllerben szerepel ugyanaz a rész, akkor azt ki kell emelni controller helperbe. Ha a viewoknak van közös része, akkor azt meg view helperbe kell kiemelni. Az optimalizálásnál a válasz egyes részeit, amit a helperek visszaadnak érdemes ugyanúgy kesselni, mint magát a teljes választ. Kb ennyi, amit tudok a témáról.
ennek így mi értelme?
Végülis a fő kérdésem az, hogy egy-egy előállított oldal felépítését miként lehet MVC-OOP alapján hatékonyan megoldani úgy, hogy az adott oldalon többféle tartalmi blokk van? Például a nyitólapon szeretném látni a két legfrisebb cikket (cikk controller), a legnépszerűbb top 10 terméket (katalógus controller), az új felhasználókat (users controller), a legfrisebb véleményeket (fórum controller) stb. A katalógusban meg az aktuális témakörhöz tartozó legfrisebb cikket (katalógus + cikkek controller).
Lényegében egy jól használható, moduláris view rendszert szeretnék, amely többféle template-et támogat. Itt azt is megjegyezném, hogy pl. a template rendszereket (smarty) sem tartom jó ötletnek, hiszen maga php is egy template nyelv. Így mi szükség újabb rétegre?
A template rendszereknek
Ahogy én látom ezek a dolgok, amiket leírtál nem kapcsolódnak szorosan az egyes controllerekhez. A controllerek szerintem inkább csak egy külső hozzáférési felületet adnak az alkalmazásnak. Mondjuk a cikk lekérésnél nem küldesz űrlapot, csak egy listát vársz, szóval a controller nem csinál kb semmit, csak a view rész a dolgozik. Szóval mondjuk a két legfrissebb cikk lekérésénél példányosítasz egy cikk view helpert, ami visszaad neked egy html részletet a két legfrissebb cikkről. De ha ugyanúgy a két legfrissebb cikket akarod lekérni, csak mondjuk nem a tartalmi részre, hanem bal oldalra a menü alá, akkor ugyanazt a cikk view helpert hívod meg, csak más kinézetre vonatkozó paraméterekkel. Én legalábbis így képzelem el.
Szóval a controllerek a public rész, ami a külső hozzáférést intézi, a helperek meg a private rész, ami a belső hozzáféréseket intézi. Mondjuk az alapján, amit írtál a legtöbb rendszerben ez nem különül el ennyire élesen.
most még inkább zavaros
Tehát adott egy url query mondjuk simán a nyitólapra. Ezen a ponton elvileg a controller-hez kerül a vezérlés, amely azonban így nem csinál mást, mint behívja a nyitólap view-t. És ebben a view-ban van ezek szerint meghatározva, hogy a fent felsorolt komponensek jelenjenek meg. Így a view-ból egyszerű függvény (helper) hívásokkal beillesztjük a szükséges blokkokat. A függvények meg a model rétegből lehívják a konkrét tartalmat. Tehát mi a szerepe a controllernek azon kívül, hogy include 'nyitolap_view.php' ?
A controller validálja a
A helpernek egyébként azért nem jó a függvény, mert az rontja az újrafelhasználhatóságot. Sztem sokszor előfordul, hogy helper osztályokból örököltetnek, mondjuk listáknál a rendezéssel kapcsolatos kódokat, vagy ilyesmiket. Annyira mondjuk nem folytam bele a témába. Egy időben én is gondolkodtam saját CMS-en, de most már nem látom sok értelmét. Rengeteg idő egy használható rendszert fejleszteni (főleg egyedül).
Hmm, lehet, hogy amiről én
és ezt így hogy?
Egyébént meg azt gondolom, hogy a helperek használata felborítja az egységességet. Valahogy már az elnevezés is azt sugallja, hogy jó ez az oop-mvc, de mindig szükség van külső "segítségre", mankókra, melyek nélkül nem oldalható meg hatékonyan a feladat. Így viszont megette a fene az elméletet.
Nem tudom, hogy érdemes-e külön topicot indítani, ezért egyelőre itt kérdezem meg, hogy végülis milyen módon építenél fel egy moduláris vezérlést, ahol bármely oldalon bármely funkció egy-egy szelete megjelenhet?
Én odáig eljutottam, hogy az url elemzése révén beazonosítom, hogy melyik "page" kell: főoldal, katalógus, magazin stb. Itt arra gondoltam, hogy akár ezeken belül is lehetnek további aloldalak, melyeket egyszerű path-ként azonosítok, pl.: katalogus/ujhirdetes, magazin/hirek. És ezekhez mind-mind készítek egy-egy "page" php-t, a view alatt és itt határozom meg lényegében az oldal tartalmát.
Talán egyszerűbb, ha a könyvtárszerkezetet vázolom:
- wwwroot
--- app
----- core.php
----- data.php
----- auth.php
----- ........
--- lang
------ hu
--------- home.php
--------- catalog.php
--------- .....
------ en
--------- home.php
--------- catalog.php
--- view
------ mytheme
--------- page
------------ catalog
--------------- add.php
------------ magazine
--------------- news.php
------------ catalog.php
------------ magazine.php
------------ home.php
--------- style
------------ master.css
--------- script
------------ master.js
--------- master.php
--- config.php
--- index.php
És ezt úgy gondoltam, hogy a view/mytheme/master.php-t tölti be az index, miután egy "globális" config tömbben beállítok egy csomó mindent, ami kell. Ezután a master.php tartalmazza azt ami minden oldalra kell + egy include-ot a kért oldalra, pl.: include 'page/magazine/news.php". És mivel az oldal-t a view alá raktam, ezért itt minden okom megvan arra, hogy az oldal tartalmát vizuálisan is rögtön itt összeállítsam. A page oldalak meg az "app" alatt lévő "helperek" függvényeit hívják. Az "app" include-okat meg már az index.php megcsinálja - csak ami kell!
Vélemények?
Egy ilyennél pl abba kell
Ha már mindenképp külön mappát akarsz minden controllernek, akkor a catalog.php-t berakhatnád a catalog mappába index.php néven. A lang-nál elég erős a redundancia, nem tudom, hogy az a rész pontosan mit csinálna, de nem hiszem, hogy így kéne megoldani. :-)
érdekes, hogy említetted
-- include 'view/theme/page/' . $validurl . '.php';
-- AMI:
-- include 'view/theme/page/magazine.php'
-- VAGY:
-- include 'view/theme/page/magazine/news.php'
És persze van egy validáló tömb, amiben tételesen fel vannak sorolva a "page"-ek, így tehát: array('magazine', 'magazine/news' ...), de itt már csak a belsőleg használt angol nevek!
A gondom az url fordításnál a "controller"-nek átadott paraméterekkel van jelenleg, hiszen ezeket is le kéne fordítani, de ez már rengeteg bejegyzés. pl: magazine/news/cars -> magazine/news/autok, ahol a cars/autok egy sima filter. Ezekből meg nyilván rengeteg lehet.
Hát én a különböző nyelvű
szerintem mindegy
A kérdés az, hogy miután tudod a nyelvet a további url elemeket mind le kell-e fordítani, vagy csak a vezérlőig és a továbbiakat hagyjuk meg angolul? pl.: domain.com/hu/magazin/hirek/autok/legfrisebb query-ben a "magazin/hirek" már meghatározza az oldalt, az "autok/legfrisebb" meg további paraméter, a tartalom előállításához (model-nek adjuk majd át).
Nyilván érdemes végig lefordítani, csak ettől most egy kicsit megijedtem, mert ebből rengeteg lesz, hiszen ide tartoznak pl. a különböző rendezések, egyéb táblázat filterek is. Az viszont hülyén néz ki, hogy: domain.com/hu/magazin/hirek/cars/news.
Most hogy így beszélünk róla kezd letisztulni a dolog. Kell a fordítás mindenhez. Már csak azt kell kitalálni, hogy milyen formában. Talán az lesz a legjobb, ha a vezérlő tölti be a hozzá tartozó paraméterek nyelvi fordítását és a további url elemzést maga végzi. Így csak annyit töltünk be, amennyi feltétlenül kell.
block action
én a saját mvc-mben ezt úgy oldottam meg hogy vannak ún block-actionok a controlleren (igazából ugyanolyanok mint egy rendes action, csak "block_" prefix-szel)
amiket egy pl twig-be exportált
(pl fejlécben egy user_panel, vagy oldalsáv modulok stb)
Pénzes megoldások -> ingyenes
hol találok megfelelőt?
Mivel én magam elég nagy rendszereket fejlesztek más környezetben ezért végül úgy voltam vele, hogy mi ez a php nekem, seperc alatt összerakom a rendszert. Aztán szembesültem azzal, hogy ez egészen más világ, másféle fejlesztői gondolkodás szükséges. Így nekiláttam tervezni és tanulni, de ma már szinte mindenhol a kész rendszerek mennek. Ez nem is lenne baj, de valahogy egyik sem az igazi.
Én zenddel fogok gányolni nem
szerintem túl nagy
Hát jó, csak amíg gondolkodsz
oké, hogy idő, de mégis
Yepp, én csak azt mondom,
MVC, ki hogyan
Kb. 3 éve ismerkedtem meg az MVC-vel. Azóta ezen szemlélet mentén próbáltam építkezni. Az utolsó fejlesztésem kapcsán (amin most dolgozom) gondoltam, hogy megint más megközelítésben állnék neki a kérdésnek (ez fél éven belül talán a 4. féle megoldás lesz :-)).
Ennek okán elkezdtem kicsit keresgélni MVC témában; a meglévő ismereteimet bővítendő. Azt látom, hogy ahány ember, annyiféle értelmezése van az MVC-nek. Van ahol azt írják, hogy az MVC felépítés esetén a VIEW csak és kizárólag a CONTROLLER-től fogad adatokat, melyeket meg kell jeleníteni. Másik cikk azt írja, hogy ennek éppen ellenkezője az igazi, azaz a VIEW csak és kizárólag a MODEL-től fogad adatokat, a CONTROLLER nem közvetítő ezen rétegek között. Egy másik értelmezés esetén a CONTROLLER nem csinál mást csak a tényleges felhasználói aktivitásra reagál, tehát a MODEL objektum mind a VIEW, mind a CONTROLLER esetén át van adva "saját használatra". Így egy sima lekérdezés esetén a CONTROLLER nem is csinál semmit (csak update, stb. műveletek esetén).
Őszintén megmondom, hogy a magam részéről jó iránynak tartom ezt a szétválasztást, de azért egyre inkább vannak fenntartásaim. Az vitathatatlan, hogy miért jó irány az egyes logikai egységek szétválasztása.
A probléma viszont az, hogy éppen a WEB az, ami a legtöbb gondot okozza ezzel kapcsolatban. Mert míg egy desktop alkalmazásnál nem kell azzal foglalkozni, hogy a felhasználó meghamisíthatja a UI-t (max. ha crack-eli a progit), addig itt -- mivel minden szöveges kommunikáción alapszik -- minden esetben újra kell építeni a felhasználói felületet, ami felesleges köröket jelent minden egyes oldaltöltésnél.
Újra kell építeni egy menüt, amiben be kell jelölni, hogy melyik az éppen kiválasztott elem. Ez egy AJAX webalkalmazás esetén a kliens, azaz JS dolga. Míg egy nem AJAX rendszer esetén minden egyes oldaltöltésnél kell egy menüösszerakó rutin, aminek valamelyik pontján egy programrész megmondja például az URL alapján, hogy melyik a kiválasztott menüelem*. De itt már jön is a szívás, hogy validáljuk a menü ID-t, megfelelő-e (típus, érték), stb.
Ennek okán hiába az MVC, ha olyan köröket kell futni, ami teljes mértékben felesleges és az ember gondolkodik, hogy akkor mit hova toljon be. Ez nagyjából a helper téma, amit fentebb is boncolgattok.
Ebből is látszik, hogy a WEB-et olyan módon akarjuk használni, mint egy desktop alkalmazás, de alapjában véve nem erre lettek kitalálva az építőkövek. Annó az MVC is ugye a GUI alkalmazások esetén jelent meg, de ott minden marad a memóriában, nem kell újraépíteni az egyes oldaltöltéseknél az egész UI-t. Ez AJAX esetén nagyjából megvalósul, de ott is kérdés, hogy mit hogyan oldjunk meg. Ha desktop like megoldásban gondolkodunk, akkor ott a PHP (vagy bármilyen backend) ténylegesen csak adatot szolgáltat. Ha pedig ez így van, akkor elértünk oda mint a DOS-os időkben, hogy kézzel kell összerakni a UI-t, igaz JS segítségével.
Egyre inkább kezdek kiábrándulni ebből a honlapkészítős témából, mert már tényleg olyan módon használjuk az egészet, aminek köze sincsen ahhoz, amire annó kitalálták.
Tartom, hogy a HTML, CSS alapvetően dokumentumok leírására való és nem online alkalmazások fejlesztésére. A szöveges alapú protokollok és az egész WEB működése sok sebből vérzik, ha alkalmazásokat akarunk írni.
Így pedig már nem csodálkozom azon, hogy nem tudjuk eldönteni egy WEB-es fejlesztés esetén, hogy MVC-ben mit hogyan. Mert nem ilyen közegbe, nem ilyen technológóiai környezetre lett kitalálva az MVC...
* Éppen tegnap futottam bele ebbe. Ha a menü elemei adatok, akkor azt a model rétegnek kell prezentálnia. Hogy melyik az aktív menüelem, ezt ki lehet olvasni az URL-ből. De ha a modelnek átadjuk az URL-t feldolgozásra, akkor már sérül a logikai szétválasztás. Mert a modellnek -- szerintem -- nem kell tudnia, hogy mi az az URL. Ekkor jött a következő lépés, hogy a menü objektumnak legyen egy setActive() metódusa, melyet a controller rétegben hívok meg az egyes action-öknél.
tökéletes megfogalmazás
Én emiatt végső soron arra jutottam, hogy a php feladata egyszerűen annyi, hogy egy oldalt előállít. Így talán a legegyszerűbb megoldás lesz a legcélravezetőbb, mégpedig az, hogy mindent úgy kellene szervezni, hogy amint egy-egy eleme az oldalnak előállítható állítsuk is elő és menjünk tovább. Ne szarakodjuk minenféle oop-mvc paradigmákkal, csak akkor ha ez az oldal előállítását megkönnyíti.
Sajnos azonban ezzel úgy tűnik net-szerte egyedül vagyok. Mindenhol a desktop alkalmazás gondolatait igyekeznek görcsösen átültetni webre és mint ahogy te is írtad, ez nem igazán célravezető. Mi a francnak példányosítsunk 3-4 osztályt, töltsünk be egy rakás "helpert" meg egyebet mondjuk egy menü előállításához, amit egy sima array-ből is felépíthetnénk pillanatok alatt?
Komolyan elgondolkodtam azon, hogy csupán hobbiból indítok egy open-source projektet web-framework témában a fentiek alapján. Persze ez lenne így százmilliomodik framework, de mivel ilyen működést egyik létezőnél sem találtam, talán lenne értelme.
Oldal előállítása
Kezelhetnénk az oldal egyes részeit is objektumokként, header, footer, sidebar, stb, de itt megint az lesz a gond, hogy ha nagyon eltérő elemek vannak az egyes aloldalakon, akkor igen nagy káosz lesz.
Most egy olyan megoldást alkalmazok, hogy van egy egyszerű függvény, mely a renderTemplate() nevet viseli, ezt fogja használni a VIEW objektum. Lesznek VIEW objektumok és minden egyes aloldalhoz lesznek fő .tpl-ek majd ezek include-olnak kisebb template-eket, mint pl. header, categoryMenu, stb.
És akkor itt jönnek az olyan kérdések, mint amit az előző kommentben is feszegettem, hogy egy menüelem aktív állapotát mi állítsa be, ha el akarjuk fedni azt, hogy milyen formában érkezik az összehasonlítás alapját képező menüID. Most egy SEF URL router működik a rendszerben, mely a request objektumban állítja be az adatokat. Ha nem SEF URL-t kezelő router van, sima GET paraméterekben jönnek az adatok, a végén akkor is a request objektumon keresztül lehet elérni a paramétereket. De mivel szeretném a modellt függetleníteni attól, hogy van olyan, hogy request objektum, ezért kénytelen vagyok a kontroller beiktatásával beállítani a modellben az aktív státuszt.
Szóval én arra jutottam, hogy hiába az OOP, hiába az MVC és egyéb megoldások, a WEB működése okán szinte képtelenség "tiszta" kódbázist létrehozni (ahol nem kell előbb-utóbb valami áthidaló megoldást kitalálni egy-egy funkció megvalósítása esetén).
Amit te írsz az lényegében visszavezet az alapokhoz, mármint a PHP alapvető működéséhez, hogy vannak a HTML blokkok, meg vannak az egyéb szerver oldali, dinamikus részek, amik végül HTML kódot állítanak elő, csak nem kézi, hanem gépi erővel (ciklusok, feltételek).
Én szerettem volna egy "tiszta" szerver oldali megközelítéssel dolgozni, de egyre inkább azt látom, hogy nem lehet, mert nem elég csak a szerver oldali (business logic) dolgokkal foglalkozni, olyan szintű bemeneti szűrést és olyan szintű felesleges köröket kell lefutni a stateless környezet miatt, ami túlbonyolítja az egészet. AJAX környezet kicsit jobb ilyen tekintetben, de ott meg jönnek más problémás esetek.
A WEB linkelt dokumentumok halmaza, melyekbe beágyazunk ilyen-olyan egyéb médiákat, nem pedig alkalmazásplatform. Lehet ez utóbbinak is használni, de akkor megkapjuk azt a sok szívást, amivel nap, mint nap dolgunk van.
Nem emlékszem pontosan, de talán a dinamikus szerver oldali nyelveknek az alapja az volt, hogy ne kelljen kézzel legyártani sok-sok HTML oldalt, amiben sok a redundancia, ha változik valami, akkor ne kelljen ezer helyen módosítani. Nem pedig az, hogy online alkalmazásokat írjunk, ahol igen komoly a kétirányú kommunikáció. Elősorban publikálásra, nem kétirányú interakcióra termett a WEB annó. De legalábbis nem olyan mértékű interakcióra, mint azt ma csináljuk.
A WEB jóság, mert egy igen kellemes környezet (interaktivitás, változatos megjelenés), de a technológiai alapok egyre inkább szorongatják a fejlesztőket. Ezt mondom már mióta és ahogyan látom, nem vagyok egyedül ezzel a meglátással...
Update: annó valamelyik topicban írta valaki (MVC volt a téma), hogy érdemes a modellt úgy kialakítani, hogy nem támaszkodunk arra, hogy WEB-en fog működni a rendszer. Tehát nincsenek WEB-es jellegű függőségek, pl. a modell nem használ $_GET-et és hasonlókat.
Most visszapillantottam a kódra, amit tegnap írtam, valamint arra, amit fentebb írtam, hogy a request objektumot nem akartam megismertetni a modell objektummal, mert hogy ők ne tudjanak egymásról, az előbb leírt logikai elválasztás okán.
De ez a logika már ott bukik, hogy a modellnek vissza kell adni egy-egy kategória link-jét, amihez ismerni kell az URL struktúrát. Hiába a router objektum, amit kedvünk szerint cserélhetünk, így vagy SEF vagy sima GET paraméter alapú URL-ünk van, ha a modell állítja elő az URL-eket pl. a kategóriákhoz, akkor nem lehet végső soron szépen megvalósítani a szétválaszást, mert a modellbe bele kell vinni az URL logikát.
Ezt vagy úgy lehetne feloldani, hogy képezünk egy olyan réteget a modellen belül, ami egy közbülső réteg, de ez meg már olyan szintű bonyolítás, ami felesleges egy kisebb oldalnál. Vagy áttoljuk a kontorllerbe, így meg kezdődik a hackelés.
Én úgy érzem, hogy nem igazán lehet ezzel a közeggel "tiszta" kódbázist létrehozni, ahol ténylegesen elkülönül minden. Vagy ha igen, akkor olyan szintű rétegezés és objektumhalmaz jön létre, ami teljes mértékben indokolatlan, tekintve a folyamatos oldaltöltést és az így újra és újra felépülő programlogikát.
Tehát kijelenthetjük, hogy a WEB stateless mivolta az, ami a legtöbb problémát okozza ha alkalmazásokat akarunk írni WEB-es alapokon.
Nem véletlenül írtam azt a közelmúltban az egyik topicban, hogy ha ilyen módon akarjuk a WEB-et használni a jövőben (de már a jelenben is), akkor kellenek az új technológiai alapok, nem pedig a mostani foltozgatása, ami még több szopáshoz vezet...
Rendszeresen elolvasom a
Tessenek már elfogadni, hogy a web != desktop! Teljesen más környezet. Másmilyen jellegű problémákkal kell megküzdened. Más eszközök állnak a rendelkezésedre. A felmerülő problémákra a rendelkezésedre álló eszközökkel kell reagálnod.
Miért kellene egy webalkalmazásnak (igen létezik ez a kategória) ugyanúgy [b]működnie[b] mint egy asztali alkalmazásnak?
Direkt visszaolvastam most néhány megnyilvánulásodat és arra jutottam, hogy minden problémád abból adódik, hogy egy asztali alkalmazás működését akarod ráerőltetni egy arra (szerinted is) alkalmatlan környezetre.
Kívülről úgy látom, hogy a számodra két út van. Az egyszerűbb hogy felhagysz a webes fejlesztéssel és elfogadod, hogy számodra ez nem pálya. A másik, lényegesen embert próbálóbb megoldás, hogy nézőpontot váltasz, és nem próbálsz meg "széllel szembe vizelni", és a végén "megsértődni", hogy a cipődre ment.
Remélem ez utóbbit választod!
Norbertnek igaza van abban,
Maguk a sirámok szerintem is feleslegesek, mivel a helyzeten lehetséges változtatni, csak persze időt kell rászánni.
Re
Re
A web nem desktop, ez így van. Viszont a WEB most már közel sem az, ami volt 15 évvel ezelőtt. A háttértechnológiai meg kisebb hackeket leszámítva (értem ez alatt a HTML5-öt is) maradt ugyanaz. Holott az igények jelentős mértékben változtak, sőt olyan irányt vettek, amit szerintem senki nem gondolt volna 15 évvel ezelőtt.
Ebből nekem logikusan az következne, hogy a HTML-t kidobjuk HTTP-stől együtt és nem FF X-et, meg Chrome X-t fejlesztgetünk, mely fejlesztés során toljuk a számmarketinget, hanem megteremtjük a ma és a honlap WEB-jének tehcnológiai alapjait.
Úgy látszik, hogy ez csak nekem ennyire egyértelmű gondolatmenet.
Nem kell egy webalkalmazásnak úgy működnie, mint egy asztalinak, de könyörgöm, amivel ma webalkalmazásokat készítünk azokat az építőköveket nem erre találták ki, hanem láncolt dokumentumok publikálásra.
Építkezzünk abból, ami van. Ok, de akkor ez mellett meg foglalkozzunk azzal, hogy legyen is valami fejlődés, érdemi előrelépés az igények fényében. Ezt írtam fentebb. Ha nem JS motorokat írnánk ezerrel, hogy a jQuery szésebesen fusson, akkor lehetne új alapokat teremteni a ma WEB-jének, ami tegnap még a honlap WEB-je volt.
Tudom, nekem vannak csak olyan idealisztikus gondolataim, hogy emberek képesek távlatokban gondolkoni, nem a pillantnyi érdekeik mentén.
Az én kis naív fejemben olyan gondolatok születnek meg, ha én a WEB jövőjét nézem, hogy a Google, a Facebook, a Microsoft, az Apple, az IBM, a Cisco meg még számos nagy név összeül és kigondolják, hogy mit is lehetne kezdeni a WEB-bel, hogy az jó is legyen. Mert ha ezt tennék, akkor nem kardoskodna az Apple a HTML5 mellett és az Adobe ellen, stb. Nyerhetne ebből mindenki, csak el kellene felejteni azt a gondolkodást, hogy most akkor benyomok egy új cuccot a köztudatba és én vagyok a császár. Ez ideik oráig működik, pénzt lehet vele keresni, de értéket teremteni nem. Az értékteremtés pedig az egész közösség érdeke lenne.
Tudom, túl naív vagyok...
Ami pedig a két utat illeti. Egyfelül a WEB és a programozás nekem már évek óta ténykérdés, hogy egy kedves hobbi, nem pedig hivatás, aminek sok-sok éven át hittem. Jelenleg még pénzért csinálom, de 5 év múlva már biztosan nem fogom és nem is leszek nagyon a web közelében. Ha másik utat kellene választanom, akkor inkább nekiállnék felépíteni az új WEB-et, de legalábbis elkezdeni megszervezni a közösséget, akik ezen dolog iránt elkötelezettek és úgy vélik, hogy a HTTP, HTML, stb. nem megfelelő eszközei a ma és honlap WEB-jének. De nem teszem. Méghozzá azért nem, mert vannak az életben számomra sokkal értékesebb dolgok, amikre sokkal szívesebben áldozok időt és energiát. De ez már nagyon off, nem idevaló téma.
minden esetben újra kell
A php-nél sajnos nem csak a felhasználói felületet, hanem mindent. A felhasználói felület újraépítését ajax-al el lehet kerülni, viszont én még nem találkoztam igazán jó megoldással ebben a témakörben. Nekem a silverlight ami tetszett, de nem volt még időm mélyebben tanulmányozni.
Hát az, hogy egy menüpont aktív e, a view réteg egy állapota, és a model-nek szerintem nem sok köze van hozzá. Szóval szerintem ezzel kapcsolatban az van, hogy a view kirajzoláskor elkéri az urlt (nem is fontos, hogy a controllertől, lehet egy központi kéréssel kapcsolatos adatokat tároló objektum), aztán elemzi, hogy melyik menüpont aktív, majd elkéri a menüpontokat a model-től és végül kirajzolja azokat.
Az én felfogásomban úgy van, hogy minden kommunikál mindennel, csak az nem mindegy, hogy mikor. Elsőre a controller megcsináltatja a modellel az update jellegű dolgokat, aztán letárolja, amit visszakap ezzel kapcsolatban. Utána a view elkezdi kirajzolni az eredményt. Ezzel kapcsolatban elkéri a controllertől a kéréssel kapcsolatos információkat (url, update eredményessége, stb...), aztán meg elkéri a modeltől az adatokat a lap kirajzolásához. Utána meg visszaadja a választ.
VIEW, mint megjelenítés
Ha ezt a feladatot áttesszük a VIEW feladatkörébe, akkor kell egy view helper, ami függésben van a rendszer olyan részeivel, amit el szeretnék (mármint én) kerülni.
Update: de ha azt nézzük, úgy vizsgáljuk, ahogyan te is írod (desktop alkalmazás megközelítésében), hogy az aktív kategória megjelenítés az valójában egy VIEW-ban történt változás (ami végülis semmi egyéb programrészt nem érint; tekintsünk el az esetleges egyéb műveletektől, ami lehet pl. egy tooltip megjelentés), akkor igen, a VIEW-nak meg kell kapnia a menü előállításához szükséges adatokat a MODEL-től (közvetlenül vagy a CONTROLLER közreműködésével; végülis mindegy, én az utóbbira szavazok egyébként), majd magának eldönteni, hogy mit is jelzünk aktívnak.
A jelen környezetben a probléma végülis pont az, hogy újra fel kell építeni az egész környezetet, mind a programlogika, mind a UI tekintetében. Ez pedig nem kis szopás...
Hát az, nyilvánvaló, hogy a
Kár, hogy ...
Hmmm én arra lennék kíváncsi,
Irónia?
Nem, tényleg érdekel, hogy mi
Szerintem jócskán hozzájárul
..
ahogy latom akiknek az mvc-vel gondja van a controllert nem tudja hova tenni. a contoroller azert is kell a view es a model koze, mert a layout-ot igy tudod fuggetleniteni az alkalmazastol es konnyen modosithatova/cserelhetove tenni.
szerintem.
Menü vs. Model
Ennek okán a helper téma élő lehet, de akkor az a VIEW része, aminek a modell adja az adatokat.
Ahogyan kiveséztük, desktop megközelítésben a VIEW feladata, hogy állapotot váltson, amikor egy kattintás történik egy menüpontra. Ez pl. egy AJAX rendszer esetén nem is probléma, de AJAX nélkül újra fel kell építeni a felhasználói felületet, a kattintást érvényre kell juttatni a VIEW-ban is (meg business logic szinten is). És itt jön a kérdés, hogy mit hogyan.
Én a VIEW-t annak értelmeztem, aminek írva vagyon, azaz nézet, ami adatokat kap és _azt_ jeleníti meg egy meghatározott módon. Tehát én úgy értelmeztem, hogy a menü kiválaszottsága a menü adathalmazhoz (modell) logikailag hozzátartozó flag, így ezt a VIEW kapja, nem pedig "kisakkozza". A VIEW helperek meg csak arra valók, hogy az egyes VIEW szinten ismétlődő, vagy bonyolúltabb (ciklus, elágazás) műveleteket becsomagolja, azaz újrahasznosíthatóvá teszi, nem pedig arra, hogy kifelé kommunikáljon. Persze ez is csak egy megközelítés.
Ahogyan fentebb is írtam, ahány cikk, ahány programozó, annyiféle értelmezése van az MVC-nek.
Végkövetkeztetésként megintcsak oda tudok kilyukadni, hogy HTML+PHP alapon nem kéne alkalmazásokat fejleszteni, mert csak a szopás van vele. Az AJAX meg ugye más fronton ad megoldandó feladatokat.
Végkövetkeztetésként
akkor ne tedd :) alternativat is tudsz mondani?
egyebkent ez a PHP+HTML eleg erdekes kiragadas, mert python, ruby es tarsaik is html-t hasznalnak a megjelenitesre es request alapu kommunikaciot alap esetben. de pl android sdk-val is van lehetoseg hogy a GUI html legyen es js-el hivod meg a java metodusokat. ugyhogy eleg szeles korben hodit a html. szerintem.
a menudologhoz meg annyit, hogy nezd meg pl a yii framework hogy oldotta meg. ott van egy CMenu nevezetu helper, aminek egy tombformajaban atadod az elemeket es o a request-bol megallapitja az aktiv elememet es bejeloli ha akarod. tehat a model-nek nem kell tudnia melyik az aktiv elem.
Tudtam ...
Korábban már hangot adtam annak, hogy a HTML, CSS és alapjában véve a stateless HTTP is arra való, hogy egymással linkelt dokumentumokat jelenítsünk meg.
Annó ezt is kifejtettem az egyik topicban. Ahol a felhasználó is előállíthatja a tartalmat (ilyen a blog is), szűrheti, rendszerezheti azt, ott már alkalmazásról beszélünk, nem pedig honlapról. Az alkalmazásnak egészen más technológiai alapok kellenek, mint egy szöveges tartalomnak, mely némi kiegészítést tartalmaz (képek, zenét, videók, stb.).
Mi lenne a megoldás? Én nem tudom, mert nem én terveztem a WEB-et. De az belátható, hogy egy dokumentumok leírására létrehozott közeg nem alkalmas arra (csak erős hackeléssel), amit ma WEB-ként értelmezünk. Persze működik, eddig is működött, de ahogy látszik, nagyon nem jó megközelítés online alkalmazások megvalósítására.
A HTML+CSS használata GUI kialakítására már alapvetően hibás megközelítés (mert nem erre termett), a Hypertext Transfer Protocol (stateless mivolta miatt) megintcsak hibás megközelítés online alkalmazásokhoz.
Tehát, mi lenne a megoldás? Az hogy terveznek az okosok olyan protokoll(oka)t, olyan technológiákat, amivel valóban platformfüggetlen megjelenítés érhető el és támogatja azt, amit ma elvárnak a WEB-től, hogy online alkalmazásokat tudjunk építeni; szopás nélkül.
És ha már itt tartunk, akkor erőteljesen újra kellene gondolni, hogy mit is akarunk valójában a WEB-től? Mert a browser ugye alapvetően szöveges dokumentumok megjelenítésére lett kitalálva nem pedig online alkalmazások futtatására.
Alternatívát egyébként nem nekem kellene mondani, hanem azoknak, akik évek óta az (X)HTML, CSS és egyéb ma WEB technológiákként értelmezett dolgok fejlesztésén munkálkodtak...
A Web mi vagyunk: te, én, a
Így van
Amúgy meg nagyon szívesen részt vennék dolgok felépítésében, ha látnám azt, hogy van értelme bármit is csinálni. Számtalanszor leírtam itt a véleményemet, de eddig J. Ádám kivételével még senki nem keresett meg, hogy dolgozzunk, gondolkodjunk együtt...
Abba gondolj bele, hogy jelen
Szóval a jó hír, hogy a jelenlegi helyzeten lehet változtatni. Nem könnyű, de lehet tenni sokmindent, és lehet a mostani alapokra építkezve is jó dolgokat összehozni.
Én is már jeleztem itt párszor a Weblaboron, hogy a HTML nem jó alap, váltani kéne. Úgy gondolom, hogy egy adat alapú web több szempontból is előnnyel járna a mostani, dokumentum alapú webbel szemben, például könnyebben felírhatnánk az adatok közti összefüggéseket, így pontosabb kereséseket tehetnénk lehetővé.
Ezt XML alapon tudnám elképzelni, mivel ez egy nagyon jól támogatott technológia, platformfüggetlen, és minden kliens (amibe beletartoznak a böngészők mellett a keresőrobotok is) maga dönthetné el, hogy ezeket az adatokat hogyan jeleníti meg, akár HTML segítségével, akár egy Flash animációval, de a döntés mindenképp az övék. Ez a megközelítés egyébként meglehetősen leegyszerűsítené a szerveroldali kódot.
Jómagam írtam már egy (jórészt) kliensoldali JS könyvtárat, ami XSL transformációk segítségével HTML-t állít elő az XML-ekből, kiegészítve URL kezeléssel, valamint azzal, hogy egy kérésre csak az oldal megváltozott részeinek adatait küldi ki. Ez egy jó alap, erre már lehet építkezni.
Lehet, hogy maga a HTTP stateless, de szerveroldalon megoldható az állapotok tárolása, magyarul ott kell elkészíteni egy jó scriptet, ami ezt megoldja - bár hozzá kell tenni, hogy nagyon szükségszerű magának a protokollnak a cseréje vagy frissítése is.
Ha van egy működő dolog, akkor azt már lehet promótálni, és ehhez nem hiszem, hogy olyan sok fejlesztő szükséges.
+1
...
En nyitott vagyok egy ilyesfajta beszelgetesre, sor mellett vagy a nelkul
Udv
Sanyi
ez érdekel engem is!
Mint ahogyan az MVC ...
Ahogyan írtam, ha a klasszikus desktop logikát vesszük, akkor valóban, a VIEW dolga megkeresni, hogy melyik menüpont aktív (van-e egyáltalán aktív menüpont).
"szopás nélkül"
szerintem felejtsd el a desktop logikat webes fejlesztesnel :)
Egyszerű
Valójában minden szopásként értelmezhető, amit azért kell csinálni, mert a WEB működése stateless. Így meg elég sok mindent bele lehet pakolni a kapba, kinek mi van éppen terítéken...
Ha elfelejtem a desktop logikát fejlesztésnél, akkor mit is kellene szem előtt tartanom? Azt, hogy egy szemétdombon kell várat építeni? Mert ezt csináljuk...
Most akkor döntsük el, hogy alkalmazásokat akarunk fejleszteni, vagy csak valami hasonlót. Ha csak bohóckodunk, akkor mehet minden úgy ahogyan most van. Ha értelmes logikákat akarunk felépíteni, akkor meg dobjanak már össze végre valami olyan környezet a nagyok, ami nem csak immel-ámmal alkalmas online működésű alkalmazások létrehozására.
"az oldaltöltés utáni
amennyiben kulonbozik a view akkor desktop alkalmazasnal is ujra kell epitened a gui-t, nem? a webesnel is csak akkor kell. az adatok escapelese szinten olyan amit desktop alkalmazasnal is el kellene vegezni, nem?
"Ha értelmes logikákat akarunk felépíteni, akkor meg dobjanak már össze végre valami olyan környezet a nagyok, ami nem csak immel-ámmal alkalmas online működésű alkalmazások létrehozására."
idonkent velem elofordul, hogy azt hiszem mindenki hulye csak en nem. aztan raebredek hogy a dolog forditva igaz. :)
Re
Nem hülyézek én senkit, de egy dokumentum leírására kitalált felületet nem kéne alkalmazások írására használni. Ez józan paraszti ész kérdése, nem az, hogy ki mekkora IT zseni...
egy dokumentum leírására
Ez igaz, de amíg nincs alternatíva (a Flash lehetne, de nincs hozzá ingyenes vagy elérhető árú szerkesztő), addig ebből kell kihozni a legjobbat.
Amíg nincsen alternatíva...
Flex
Valamint már létezik több eszköz, aminek Flash a kimenete és ingyenes. Ilyen a Haxe, a Ming, MTASC és még létezik számos egyéb eszköz. Ráadásul igyenes IDE-k is vannak például Eclipse alapon, valamint például az igencsak kellemes FlashDevelop.
De nem támaszkodhatom az
kiirod a usernek, hogy kapcsolja be.
nem alkalmazast irsz benne, hanem annak a megjeleniteset bizod ra. es amiota kitalaltak, azert fejlodott is egy kicsit.
a hibauzenet megjelenitesenel, nem igazan van plusz feladat a layout ujraepitesevel. ugyanabba a view-ba egy feltelellel megjelenited a hibauzenetet ha van olyan. ezzel az ajax nelkuli formanl kell csak az escape, nem teljesen ertem hogy mire gondolsz.
Re
Igen, GUI-t hozok létre egy olyan valamivel, amit nem erre terveztek. Ez pedig nem jó, nagyon nem jó irány.
AJAX esetén a GUI változatlan, a háttérben megy a munka, majd vagy lesz egy új részGUI kirajzolás vagy nem, csak kapok egy-két hibaüzenetet. AJAX nélkül _mindent_ újra kell kezdeni a szerver oldalon és még kimeneti escape is kell a form input mezők esetén.
De egyébként innentől már nem konstruktív a dolog részemről, mert nekem van gondom a platformmal és az elvekkel, ezeket a köröket meg már soxor megjártam itt...
kiirod a usernek, hogy
Aztán magyarázhatod a megrendelődnek, miért nem tudják a keresők indexelni az oldalad, emiatt senki sem találja meg, s így veszteséget termel. Szóval itt nincs választási lehetőség, AJAX nélkül is működnie kell.
Pár dolog
Escapelni mindig kell! Ezt jobb, ha ökölszabálynak veszed. A felhasználók nemcsak a rendszerre (code injection), hanem egymásra (XSS) is veszélyt jelenthetnek, és a fejlesztő felelőssége megvédeni mind a rendszert, mind a felhasználókat. Ezért szükség van, mind a bemenetet, mind a kimenetet escapelni.
Vannak szabályok, amiket betartva nyugodtan megírhatsz egy oldalt úgy, hogy az javascript nélkül is működik, és javascripttel/AJAX-szal csupán csak hatékonyabb, jobb felhasználói élményt ad. Ilyen pl, hogy a linkekre, formokra aggathatsz eseménykezelőket javascripttel, amelyek nélkül a rendszered vígan kiszolgálja a felhasználókat, viszont őket használva nem kell folyamatosan mindig újra és újra betölteni az egész oldalt.
Ebben van igazságod, ugyanakkor már régen túlhaladtunk azon a ponton, ahol ez még számított vagy sem. Most az a kérdés, hogy mit és hogyan lehet mégis megoldani ezen a platformon, illetve hogyan lehet magát a platformot tovább fejleszteni, hogy mégis alkalmas legyen rá.
Azt kicsit erős kijelentésnek érzem, hogy szemétdombon kellene várat építened, de elhiszem, hogy sokkal ingatagabbnak érzed a webes megoldásokat a desktopalkalmazások fejlesztése után.
Nos, a menüelemek adatnak
A logikádban ott van a gubanc, hogy nem csak a model dolgozhat adatokkal, hanem a view és a controller is. Mondjuk ha XML-t vársz, akkor a controller azt validálhatja XSD-vel. A te logikád szerint ezt az xsd fájlt a modeltől kéne elkérnie. Ugyanúgy ha a view beszúr egy sablont a model-hez kéne nyúlnia...
Logika
Az XML-es példád esetén mit várunk XML-ben? És azt melyik rétegnek címezzük?
A menü adatait visszaadni
Az XML-es példánál mondjuk bejönnek egy cikk adatai:
Re
XML-es példád rávilágít arra, hogy validáció alatt két dolgot értünk. Mert ezek szerint a kontroller feladata egy formai validáció (mondjuk, hogy egy GET paraméter szám-e), míg a modell dolga, hogy validálja a kapott adatokat érték szerint. Ez nekem csak most vált így el, eddig úgy gondoltam, hogy a kétféle validáció egyetlen folyamat (és réteg) feladata. De ezek szerint nem.
A szám-e a kapott GET paraméter az jó példa? Tehát ha a kontroller azt látja, hogy számot várunk, de [a-z] tartományból érkezett mondjuk egy 5 karakteres string, akkor egyből dob egy olyan nézetet, ami a bemeneti adat hibájára utaló üzenetet jelenít meg. Így a modell csak azt validálja majd (ha odáig eljut a folyamat), hogy a kapott szám értékkel van-e az adatbázisban rekord és lehet-e egyébként vele műveletet végezni; pl. komment hozzáadása egy blogbejegyzéshez?
Yepp, valahogy így gondolom.
Maradjunk a számos példádnál:
ujrahasznositas es dry
Én biztosan nem így
Én úgy csinálnám, hogy minden űrlaphoz létrehoznék egy Form objektumot, ami tárolja, hogy milyen input-nál milyen típusok és egyéb paraméterek vannak, a típusokat meg a Model mezőiből is tudná szedni, vagy mondjuk olyan dolgoknál, mint a captcha kód külön meg lehetne adni neki a típust.
Re
Tegnap éppen azon gondolkodtam, hogy szétválasztom a validálást, a formai validálás marad a kontrollerben, az érték szintű validálás pedig a modellben. De akkor azt mondod, hogy az eddigi logikám (a te második példád) megfelelő megközelítés?
Nyilvánvaló, hogyha két kódot
Mondjuk nézzük meg a jogosultság ellenőrzést.
Csinálhatod azt, hogy beteszed minden egyes controllerbe a jogosultság ellenőrzés meghívását, valahogy így:
Érdekes gondolatok
Sok mindent írtatok már pro és kontra az MVC és az OOP, meg úgy általában a web platform tekintetében. A fentiek alapján én most úgy látom, hogy adott egy platform, amely elsősorban "dokumentum publikációt" valósít meg és nem többet. A szerver oldalon - mondjuk php-val - csupán a dokumentumok összeállítása a feladat a kérések alapján.
A php kód szervezését ezek alapján a dokumentum építés alapelvei alapján kell megvalósítani. Így tehát az OOP és MVC paradigmák minden áron történő implementálását talán jogosan érzem erős túlzásnak. Elméleti síkon persze törekedni kell ezen koncepciók követésére, de ez sokkal inkább szervezési mintsem gyakorlati kérdés.
A dolog nyitját abban látom, hogy az MVC-t nem kód szinten, csupán mappa és fájlszinten érdemes elkülöníteni. Így tehát a php-t mint szerver oldali nyelvet az MVC minden komponensében bátran használjuk.
Az adatáramlás és kódszervezés kérdésében pedig a válasz szerintem az, hogy mindent ott kezelünk, ahol ez a "dokumentum" előállítása során első alkalommal szükséges. Ha több helyen szükséges valamilyen kódrész, azt kiemeljük "helperbe".
Egy nagyon egyszerű példa a fentiekre:
- index.php: url értelmezés (authentikáció, nyelv meghatározás, theme meghatározás, paraméterek elkülönítése) és master view betöltése.
- master.php (view): (x)html, amely tartalmaz minden olyan elemet, ami minden oldalon azonos (fejléc, logo, főmenü). A főmenü aktív elemét vagy az index-ben, vagy itt határozzuk meg. Lehetnek olyan állandó elemek, melyek bizonyos esetekben mégsem kellenek: ezeket vagy itt sima if alapján, vagy a content view-kban töltjük be.
Ezután a master view content részében egyszerű include-al betöltjük a kért oldalnak megfelelő view-t. A
- valamiview.php: Meghatározza az oldal tartalmi részét. Bizonyos esetekben olyan elemeket is tartalmaz, melyeket más view-k is használnak. Ezeket a megosztott elemeket külön fájlban tároljuk és hívjuk mondjuk "snippet"-nek.
Minden view fájl közvetlenül hívja a lekérdező és műveleti funkciókat az "app" mappából. Itt az állományokat úgy szervezzük, hogy lehetőség szerint minél kevesebb függvény legyen egy fájlban. Ha az oop elvekre gondolunk, tekintsük az app fájlokat osztálynak, a függvényeket statikus metódusoknak. Mivel egy app.php include-olhat másik app.php-t, ezért az "öröklődés" is megoldható elvi szinten.
A MVC alapján az app-ok nem feltétlenül kell, hogy adatkezelést valósítsanak meg közvetlenül. Erre létrehozhatunk egy "data" könyvtárat és az itt elhelyezett fájlokban oldjuk meg az adatkezelési kérdéseket.
Ábra(!):
-- index.php -> master.php -> view.php <- app.php <- data.php
Extraként, ha fájl alapon gondolkodunk, viszonylag egyszerűen megoldható a nyelvi verziók kezelése is, hiszen elegendő a view/app/data (MVC) állományoknak megfelelő nyelvi fájlok létrehozása, melyek közül csak azokat töltjük be (automatikusan) amire szükség van.
Én tehát azt gondolom, hogy a meglévő feltételek alapján felesleges MVC/OOP kódoláson erőlködni, mert pl. amint "helper" kell már semmi értelme a szervezési erőfeszítéseknek. Márpedig, mint fent láttuk "helper" mindig kell.
Persze lehet, hogy tök hülye vagyok. Ez esetben örülnék egy rövid tutorialnak a témában.
Én a következő módon állítom
- feldolgozom az URL-t, megállapítom, hogy milyen oldalsablon tartozik hozzá
- inicializálom az alapobjektumokat (singletonok, pl. adatbáziskapcsolódás, sablonfunkciók)
- a központi tartalmi blokkhoz nem szorosan kapcsolódó egyéb részek (pl. legfrissebb cikkek) lekérdezéseit itt futtatom
- futtatom az adott sablonhoz tartozó php fájlt
- ebben a php-ben végzem el a bejövő adatok feldolgozását (pl. űrlap adatainak mentése)
- az URL-ben megkapott paraméterek alapján futtatom a központi tartalmi blokkhoz tartozó lekérdezéseket
- minden lekérdezés eredményét egy központi indexelt tömbbe pakolom
- ezt a tömböt átadom a php sablonkezelőnek (Smarty), ahol összeállítom a kész XML-t vagy HTML-t
nem biztos, hogy jól értem
Az utolsó két pont szerint előbb előállítod a tartalmat, ezt elmented a memóriába, majd átadod feldolgozásra a smarty-nak, ami előállítja a végleges dokumentumot?
Ezt én a fentiek alapján felesleges bonyolításnak látom. Ha már tudod, hogy mit kell megjeleníteni, akkor miért nem jeleníted meg? Miért kell átadni egy "külső" template rendszernek, mikor a php maga is "template" rendszer? Mi a konkrét akadálya annak, hogy az előállított tartalmakat rögtön megjelenítsd?
Nem kötözködni akarok, csak nem tudom, hogy mi az ami ezt a fajta megoldást tényleg indokolja?
Mit értesz sablon alatt? Egy
Ezt a sablont a saját rendszeremen belül definiálom, és hozzá tudom rendelni az egyes url-ekhez, pl. a hirek.html sablontípusa: "cikkgyujto".
A smarty valóban valamennyire lassítja a programot, én leginkább megszokásból használom, meg hogy biztosan elkülönüljön a megjelenítés a php kódtól, valamint egyszerű a szintaktikája. Amióta áttértem XML-re, azóta a foreach-nél bonyolultabb dolog nem került bele (minden megjelenítési logika XSLT-ben van), szóval igazából tényleg abszolút fölösleges.
Összegzés
Tehát a végkövetkeztetés az, hogy a webfejlesztés ma már nem honlapok, azaz hypertext dokumentumok létrehozása, de nem is a klasszikus értelemben vett szoftverfejlesztés. Egy olyan hibrid közeg, aminek megvannak a szépségei és sok-sok buktatója.
várnám, hogy az új igényekhez
Másrészt szerintem natív támogatást kéne nyújtania a böngészőknek, hogy alkalmazásokat fejlesszünk, és az alkalmazáshoz widgetszerűen lehessen komponenseket hozzáadni (pl. egyszerű beviteli mezőtől a skinezett listboxig), amelyeket objektumokként lehetne (Javascriptből) vezérelni. Ezeket az objektumokat előre le lehetne fordítani, hogy gyorsabban fussanak.
Ezeket az igényeket kéne összeírni, és elkészíteni a specifikációt, amivel már oda lehet állni egy nagyobb cég vagy szervezet (pl. Mozilla) elé, hogy íme, ezt szeretnénk, segítsetek a megvalósításban.
Mozilla Prism XUL
Milyen kár, hogy egyelőre
Zend Framework
MVC szerkezet, jogosultság kezelés, űrlap készítés és validálás, cache, ... minden megoldható ZF alatt.
Egy keretrendszernél fontos, hogy sokan használják, legyenek igények, hibajegyek, javaslatok. A hivatalos Manual-on kívül legyen elegendő Tutorial, amiből a kezdő kimazsolázhatja a számára szükséges információt.
ITT egy PHP framework összehasonlító oldal.
A ZF előtt CakePHP-val fejlesztettem. A ZF kissé nehezebb, de több dolog van megírva benne.
Az ASP.NET is jó megoldás, de a tárhely drágább, saját v. virtuális szervernél a windows op. rendszer díjakat is bele kell számolni.
Saját keretrendszert szerintem nem érdemes írni, amikor vannak kész megoldások, amihez X+1 fejlesztő hozzátette a tudását.
Meg tudnád fogalmazni, milyen
ZF
Ezek szerint félreérthető volt a kommentem. (?) Pont arról írtam, hogy egy ismert, elterjedt keretrendszerrel érdemes fejleszteni. PHP környezetben a Zend Framework-t javasoltam.
Üdv, Zsolt
Nem, egyáltalán nem volt
Hátrány
miért éppen framework
Szerintem az OOP/MVC framework-ök a fejlesztők dolgát talán megkönnyítik, de a teljesítményt rontják. Kicsit úgy érzem, hogy "ha nem értesz a fejlesztéshez, tanulj meg egy keretrendszert" gondolat mentén választják az emberek ezeket. Ugyanakkor mindenhonnét azt hallom, hogy saját rendszer fejlesztése felesleges, mert vannak már jól kidolgozott rendszerek. De egy konkrét oldal konkrét megvalósításához valahogy mégsem találtam olyat, amivel a 0-ról viszonylag rövid idő alatt megoldható a feladat. A zend-el is csupán annyi a gond, hogy kell hozzá legalább 1 év mire az ember tényleg kitanulja. És ekkor megtanultál egy konkrét rendszert, de általánosan fejleszteni még mindig nem tudsz. Ha gondod van, problémába ütközöl türelmetlenül várhatod míg valaki megoldja helyetted és belerakja a rendszerbe. Vagy te magad megoldod és "belgányolsz" a hivatalosba.
Windows desktop-on ugye ott a .NET, ami szerintem az egyik legtökéletesebb fejlesztési platform jelenleg. Nincsenek ellentmondások, minden egyértelmű és világos, pedig szinte bármely nyelven fejleszthetsz hozzá. Ilyen miért nincs webre? (jó, oké, lehet asp.net-ben is fejleszteni...tudom)
A zend-el is csupán annyi a
egy ev alatt egy uj programnyelvet meg lehet tanulni, nem egy keretrendszer hasznalatat. ha neked a zend tanulasi ideje egy evnek tunik, akkor szerintem nezz masik szakma utan.
a rakas felesleges dolgot a jobb frameworkok csak szukseg eseten toltik be, igy egy jobb framework eseteben nincs lassulas.
ez is erdekes egy godolat. ugy erzed hogy egy ev egy keretrendszer megtanulasa, de szerinted aki nem tud fejleszteni az hasznalja :) altalaban pont azok nem tudjak a keretrendszereket alkalmazni es megerteni, akik gyengek a fejlesztesben es a sajat gondolatmenetukbol ha ki kell mozdulniuk akkor mar elakadnak.
szerintem.
érdekes gondolatok
Köszi szépen amúgy, hogy felhívtad a figyelmem a szakmaváltás esetleges időszerűségére. Megmondom őszintén én magam is egyre többet gondolkodom ezen, bár csupán azért, mert 15 év fejlesztés után kicsit unom már a banánt.
Mutass nekem bármilyen framework-ot és kb. 1 óra alatt írok egy listát azokról az elemekről, melyek minden esetben felesleges köröket jelentenek. De végülis nem az a lényeg, hogy én mit tekintek feleslegesnek, mert egy kész rendszer szempontjából az egyes részeknek nyilván van értelmük, de jellemzően csak a rendszer felépítése miatt.
Azt változatlanul tartom, hogy a keretrendszer használata a fejlesztők 99%-ának annyit jelent, hogy "ezt sem kell megoldanom, hiszen már megvan" és ez az esetek túlnyomó részében egyenlő azzal, hogy nem is foglalkoznak vele, nem is értik egy-egy rész működését. Persze nyilván te az 1% kivételbe tartozol, aki a pl. a Zend minden egyes soráról meg tudná mondani, hogy mit csinál, miért és hogyan?
Mindegy, ne is menjünk el ilyen irányba, mert semmi értelme.
Mutass nekem bármilyen
a legtobb rendszer mogotti fejlesztocsapat tobbnyire orul az ilyen eszreveteleknek es ha jogos amit irsz, akkor lehet forkolni.
napi par oraban el lehet sajatitani eleg rovid ido alatt az alapokat es utana akar melohelyen is be lehet mutatni, aztan belevagni vele egy projectbe es azalatt megtanul az ember sokmindent.
en nem hiszem hogy a 99% ilyen, de vannak ilyenek is. bar ennyi erovel azt is nezhetnem hogy a php egyes gyari fuggvenyei mogott milyen C kod van, ahelyett hogy hasznalom oket.
nem hasznalom a zend frameworkot, ugyhogy a jelenlegi verziorol eleg szegenyes ismeretekkel rendelkezem.
Azt változatlanul tartom,
Az, hogy egy framework-ben
De. Ezért egy "echo helló világ" projekthez nem javaslom. Viszont egy 80-100 táblás weboldalnál már kellhet az összes funkció. Különösen ha átlátható rendszert akarsz készíteni.
Az eredeti kérdésedre a symfonynak van megoldása. Ott ugyanis vannak sfActions és sfComponents osztályok. Van template és van layout. A layoutot az sfActions osztályban tudod beállítani az egyes funkciókra. Ezek amik meghívhatóak az url alapján. Például egy cms oldal, a cms/show/kapcsolat url-en érhető el, ami a kapcsolat nevű tartalmat jeleníti meg.
Igen ám, de te szeretnél ezen a képernyőn is megjeleníteni egy jobb oldali sávot, ami mondjuk tartalmaz egy hírlevél feliratkozást, vagy bármit. Akkor a kapcsolatnak egy olyan layoutot állítasz be, ami tartalmazza a megjelenítést, és tartalmaz egy jobb oldali sávot. A jobb oldali sávban pedig behívod a szükséges komponenst (include_component): megírod az hírlevél sfCmponents osztályába a logikát és kirakod egy templatbe, ami így bekerül a layout jobb oldali sávjába.
Ha belegondolsz, olyan 5-6 féle layoutot kell gyártanod: egy olyat, amin van jobb és baloldali sáv, egy olyat, amin csak jobb oldali van, vagy csak baloldali van, vagy épp egyik sincs. És néha teljesen más dolgok jelenhetnek meg rajta, de nagyjából 5-6-nál több variáció már erősen hatással lesz a felhasználóra is. 5-6 layout felett erősen korrigál a 0 felé a késztetés a visszatérésre, hiszen ki akar visszatérni egy {}olyan oldalra, ahol semmit sem talál meg...
Teljes mértékben egyetértek
Azt nem hiszem, hogy a html (css, js) használhatatlan lenne és szükség volna valami másra. A legnagyobb ereje pont az egyszerűségében van, talán ezért támogatott olyan sok platformon. A bonyolult dolgokat szerintem jobb szerver oldalon tartani. Persze megértem az igényt egy okosabb szabványra, de gondoljatok bele ha azt kellene hackelni, hogy az 'ie adatbázismotorja mit csinál másképp'.. Az most hogy a szerver és kliens között csak adatok mászkálnak még nem tenné egyszerűbbé az alkalmazást, max szerver oldalon, de a kliens ennyivel bonyolultabbá is válna.
desktop alkalmazások.. szerintem inkább (nagyon)vékonykliens.
de hogy az eredeti kérdésre is válaszoljak.
-az egyik dolog ami szükséges az az hogy az url mindig tükrözze az alkalmazás használatának az állapotát. milyen nyelven használom, hol vagyok, mit csinálok, milyen vezérlő paramétereket használok (szűrésre bármire). ezek mindig csak url és get paraméter párosban szerepeljenek. (ha elküldöm valakinek, azt lássa mint én ..persze csak ha megvan hozzá a jogosultsága ez viszont session-ben van tárolva)
-ha olyan kérést küldök a szervernek ami adatokat módosít az menjen post-ban vagy bárhogy de utána legyen egy redirect a frissítések okozta galibák elkerülése végett. post után sosincs tartalommegjelenítés.
MVC példa. legyen fordítóprogram.
Model :: az alkalmazás logikáját valósítja meg.
-keresés
-fordítás felvétele
-fordítás törlése
-fordítás módosítása
-szótár (egy részének) elemeinek visszaadása
View :: kimenet generálása
-keresőform
-fordítás megjelenítése
-elemek listájának megjelenítése
-oldal vázának megjelenítése
Controller :: vezérlés
-mit akarunk éppen csinálni
-milyen adatok vesznek részt a mókában
-milyen model(eke)t, milyen view(ka)t használunk, ezeknek mely metódusait hívjuk meg
Oldal felépítése. Contenido CMS-t volt szerencsém használni, a kód elég fura :) de a logikája szerintem igen jó.
eszerint
-vannak layoutok: html váz, amiben modulokat helyezhetünk el.
-vannak modulok: dinamikus tartalomért felelős alkalmazások (menü, cikk, ajánló, galéria, stb)
-vannak template-ek: layoutok és modulok összerendelése
-jön egy kérés
-template meghatározása
-résztvevő modulok, azok bemeneteinek meghatározása
-modulok meghívása
-kimenetek bepakolása layout-ba
-viszon'látásra
nem teljes a példa, de dolgozni is kell valamikor. én kb így képzelem a dolgot.
az MVC legnagyobb erénye talán, hogy a hármasból bármelyiket lecserélve működhet a dolog, bármelyiket fel lehet használni más kontextusban is. ha olyan kódot írsz hogy észreveszed ezen tulajdonságokat és elámulsz, na akkor programozol MVC-ben :)
nagyjából értem
A kérdés még mindig az, hogy "ki" dönti el, hogy mi jelenjen meg az oldalon? Megpróbálom világosabban:
- adott az url
- ez alapján eldöntjük (index.php-ban?), hogy melyik controller melyik metódusát kell meghívni.
- A meghívott controller metódus eldönti, hogy minek kell látszania a page-en.
- A betöltendő oldal elemeket (modulokat) betöltjük és így előáll az adott tartalom-rész.
- Eddig a pontig tehát controller alapján tudjuk, hogy mit kellene megjeleníteni, sőt akár már a konkrét tartalom is megvan.
- Be kellene tölteni egy layout-ot (vagy view-t), amiben viszont már szerepelnie kell minden "placeholder"-nek, amire szükség van.
- Ez azt jelenti, hogy minden lehetséges elrendezéshez kell egy konkrét layout.
- Ha így van akkor viszont simán lehetne layout alapján előállítani a tartalmat és így átrakni a vezérlést a view részbe.
"-kimenetek bepakolása layout-ba"
Lényegében ez az a pont ami számomra nem egyértelmű, hogy konkrétan hogyan történik? Mit hívunk meg miből, mit include-olunk és hol?
Ez azt jelenti, hogy minden
Ha neked minden egyes menüpontod másképp néz ki, akkor igen. De én még nem láttam olyan oldalt, ahol 5-6 layout ne lett volna elég.
Van egy url: http://weblabor.hu/forumok/temak/108734/hozzaszolas/123456
forumok action, temak metódusa, a többi meg a paraméter. Ez jeleniti meg a hozzászólást a témában. Ez egyetlen sor a layoutban: "echo $sf_data" Mivel ez a függvény mindenképp lefut és legenerálja ezt a változót, és eldönti hogy ezt a 2 hasábos (jobb oldali kicsit vékonyabb) layoutot jeleníti meg. A layoutban a jobb oldali divben szerepel néhány komponens hívás: "könyvajánló", "cikkajánló", "Friss blogmarkok", "Friss csiripek", stb. Ezek megjelenhetnek egy másik layoutban is, így egyetlen függvényhívás mindegyik (include_component). A komponens meg ugyanúgy néz ki, mint az action (más helyeken ezt hívják controllernek), csak ez nem az url alapján hívódik meg, hanem egy helper hívja meg. De ugyanúgy van neki vezérlő része (components class), és templatje(i). Ez a symfony.
Na de ez az, amit nem találsz meg a CakePHP-ban, pedig nagyon kéne. Ott azt tudod megcsinálni hogy az app_controller osztályban előállítod az adatokat és kirakod a layoutba. Mindet egy helyre beömlesztve. Gyönyörű szép spagetti kód kialakítása szinte kötelező.
De én még nem láttam olyan
Akkor gondolom nem látogattál még hírportálokat. Azokon általában 10-20 alatt nem áll meg az elrendezések száma. Azért tudom, mert az utóbbi 5 évben ezeket csinálom.
Ok :-) De azért az itt
Ha most megnézzük az origot, ott persze más a helyzet. De azért nem az az oldal, amiről elmondhatja bárki, hogy jól kiismeri magát rajta. Szerintem akik írják, talán, de én jó ha 4-5 layoutból megoldanám azt, amit láttam eddig belőle. Persze az a tizede sincs, az oldal minden funkciójának. De gondolom, hogy van aki nézi azt a részét is, mert biztos leállítanák, ha nem lenne érdeklődő :-)
Amúgy ha egy-egy layout
tehát semmi sem akadályozza meg a kollégát olyan rendszer kialakításában amiben 'sublayout'-ok is vannak
Ha több fejlesztő
Contenido-t csak távolról
a layout ha úgy tetszik egy grid amiben placeholderek vannak a modul kimenetek számára
"-kimenetek bepakolása layout-ba" - modul kimenetek elhelyezése az oldal struktúrában.
a Template elnevezés valóban
ahogy gondolom a hozzászólásaid alapján az egyik fő problémád az, hogy a megjelenő tartalom generálásának a sorrendjét csak úgy tudod elképzelni ahogy azok a html kódban egymást követik.
hagy ajánljam ezt :)
nem 'include' van, hanem 'set'.
és csak a program futásának legeslegvégén van echo és fetch(). ez ugye azért is jó, mert a program futása közben bárhol nyomhatsz egy header() függvényt, vagy akármi..
nem egészen
Egyre inkább azt látom, hogy a vezérlést át kellene az aktuális view-nak (layoutnak?), amely szépen sorban betöltené a megfelelő helyekre ami szükséges. Tehát a layout mondaná meg, hogy mit kell megjeleníteni. Az elején az url alapján csak azt kellene eldönteni, hogy melyik view kell. Az egyes helyekre betöltött "modulok" meg tovább értelmeznék a maradék url paramétert és aszerint jelenítenék meg a saját tartalmukat mondjuk a kért sorrendben.
Tehát szerintem nagy vonalakban elég egy index.php -> page_<id>.php, amely többféle view<id>.php-t include-olna és ezek az egységek hívnának meg különféle funkciókat a model részből. Valahogy így:
- index //melyik page kell?
--- page1 //layout file, a view részben
----- view1 //egy "önnműködő" blokk a layout-on belül
-------- include 'magazine/news.php'
-------- magazineGetNews(2) //legfrisebb 2 hír
----- view2
-------- include 'catalog/items.php'
-------- catalogGetLast(10) //legújabb 10 hirdetés
----- view3
-------- include 'community/entries.php'
-------- communityGetEntry(5) //legutóbbi 5 hozzászólás
Így az egyes view fájlokat bármelyik page-en be lehet tölteni, akár úgy is, hogy pl. paraméterek alapján különböző sorrendben jeleníti meg a tartalmat a különböző page-eken.
azt hiszem értem a logikádat.
először az a kérdés merült fel bennem, hogy mi van olyankor ha view1, view2, view3 közös adatokon dolgozik? de végülis lehet azt csinálni hogy ilyenkor a felettük lévő szinten jön létre a közös adat..
mi van akkor ha view3-ban submitolnak egy formot? hogyan küldök redirectet? ob_* függvények használatával (pl a page-ben) ez sem okoz gondot.
belekötni nem tudok. én az OOP-t nem áldoznám fel a teljesítmény oltárán.. de a te projekted azt csinálsz amit akarsz :)
további magyarázat
Az viszont jó kérdés, hogy mi történik akkor, ha valamely view-ban form-ot küldök. Szerintem egyszerűen ugyanaz a page jön be és csak a kérdéses view rész tartalma változik majd meg. A redirect megoldható úgy, hogy a post-ra meghívom a küldő view feldolgozóját, majd ezután redirect az eredeti page-re.
A php OOP-vel az a gondom, hogy .NET után nem tűnik túl kiforrottnak. Lenne még mit fejleszteni rajta. Így tehát számomra csak felesleges bonyolításnak tűnik ahhoz képest, hogy szinte minden megoldható procedurálisan és sokkal jobb teljesítménnyel. Ez persze semmiképpen nem jelent ész nélküli gányolást, inkább erőteljesebb szervezési szemléletet.
Egyébként meg lehet, hogy megoldom inkább asp.net-el. Most néztem meg egy kicsit részletesebben a MS féle ASP MVC 3-at és nem tűnik rossznak. Azt olvastam, hogy pl. a stackoverflow.com is ezzel készült, ami egy eléggé látogatott, mégis gyors site.
ps.: Túl vagyunk a 100. hozzászóláson! Ezt nem gondoltam volna :)
A helyedben én is asp.net-tel
ezt is tanulni kell
Nincs pénz benne...
Egységes keretrendszer
Egyrészt a PHP egy sokkal vadabb jószág, mint a C# vagy a JAVA. Messze könnyebb vele elkezdeni dolgozni az elején, viszont pont a rugalmassága, szabályozatlansága miatt sokkal nagyobb fegyelmet igényel, és jobban meg kell tanulni vele bánni hosszútávon, különben csak gányol az ember.
A fentieknek köszönhető, hogy a PHP ökoszisztémája rettentő módon kiterjedt és sokszínű, amiatt sincs egységes keretrendszer. Ha valaki vállalkozik arra, hogy egy olyan keretrendszert alakítson ki, ami megőrzi a PHP rugalmasságát, az abban a helyzetben találja magát, hogy olyan szinten kell túlgeneralizálnia mindent, ami nagyon durván az olvashatóság és a teljesítmény rovására megy. Túl rugalmas jószág a PHP ahhoz, hogy egységes keretrendszert lehessen építeni vele, viszont így megmarad a lehetősége az embernek, hogy a feladathoz válasszon keretrendszert, és adott esetben, ha értelme van, akkor keverje őket.
Ugyanígy a PHP rugalmassága az oka annak is, hogy nincsenek letisztult módszerek.
Természetesen meg lehet ezt fogni szarkasztikusan is, és azt mondani, hogy a PHP átgondolatlan, ami látszik az API- és függvénykönyvtár következetlenségén, és emiatt egy hatalmas katyvasz az egész, de azért kiismerhető ez a katyvasz.
Mindehhez én hozzátenném, hogy a PHP mind a mai napig a stateless HTTP protokollhoz igazodik, és nem egy általános célú szkriptnyelv, éppen ezért nincs valódi alkalmazásszerver sem hozzá, és nem igazán hatékony daemonokat írni vele.
Ez gyakorlatilag ugyanaz a
Nálam egy kérés életciklusa ez (elméletben):
(a hibaüzeneteket mindig a front-controller vagy a controller kezeli le)
Az a helyzet, hogy annyit
Köszi :)
Hónapok óta keresek valami használható leírást, útmutatót, hogy tképp mi is az az MVC és a gyakorlatban ezt hogyan lehet megvalósítani. Ebből a beszélgetésből többet tudtam meg a témáról, mint a korábban talált, sokszor egymásnak is ellentmondó anyagokból összesen.
el is kezdted?
Hát ha van kedved... Egyelőre
Egyelőre annyi történt, hogy összeírtam 20 osztályt, meg hogy azok mit csinálnak. Az a koncepcióm, hogy több Tear(projekt) van (mondjuk frontend, backend), amiknek eltérő a felületük, és egymástól is tudnak átvenni Controllereket. Amikor egy kérés megy, akkor a domain (vagy url) alapján választ egy Tear-t a Bootstrap, és létrehoz belőle egy példányt. Az adott Tear hozza létre a Session és Request osztályokat, így mondjuk a backend-nél beállítható, hogy full máshol tárolja az adminok session adatait, mint a szimpla felhasználókéit.
A Request azt csinálja, hogy elkéri a Session-től a Controller-t, amit éppen használni akar, és meghívja rajta az Action-t. Mivel a Session-ben tárolódnak a jogok, ezért csak ő tudja, hogy milyen Controller-t adhat ki és milyet nem. Mondjuk ha nincs meg a jogosultság egy kérésnél, akkor ErrorController-t ad ki a Session a Request-nek.
Innentől meg hagyományos MVC, talán annyi különbséggel, hogy én jobb szeretek minden Action-nek külön osztályt csinálni, mert úgy egyenként be lehet tölteni őket, és nem kell egy Controller-nél az összes Action-t feleslegesen befordítani.
(A Tear-t nem biztos, hogy jól értelmezem, elvileg az a Controllerek összessége, szóval mondjuk ha van egy publikus része az oldalnak, az is egy Tear, meg az a része is egy Tear, amit csak az adminok láthatnak...)
Egyelőre ennyi, ahogy felépíteném, annyi apró gond van, hogy most a diplomámat írom, és napi 10+ órákat kísérletezek, hétvégén meg szöveget szerkesztek ugyanennyit, szóval időm az nagyon nincs... Majd dobj egy emailt, aztán konzultálunk a továbbiakról, meg hogy te hogy képzeled el a rendszert.
egész másképp kezdtem hozzá
Eddig megvan a központi vezérlés, a router logika, a page-ek és view-k kezelése, valamint a nyelvi verziók és különböző template-ek támogatása.
Ez persze merőben más megközelítés, mint amit te vázoltál, ezért nem hiszem, hogy érdemes lenne együttműködni, hacsak téged nem érdekel az én megoldásom.
"Ez persze merőben más
Jah, egyetértek. Hát sok sikert hozzá.
Hát úgy látom hiába
Azért elárulhatnád hogy mi késztetett a procedurális megoldásra?
És hogyan lesz MVC, ha prodecurális? Például ebből a model hogy lesz? Minden adatbázis tábládhoz külön eljárásokat írsz? Amik aztán közös eljárásokat használnak? Gondolod hogy attól lassúbb lesz egy projekt, mert az egészet becsomagolod egy classba? Én nem hiszem hogy maguk az osztályok legenerálása az, amitől lassú mondjuk egy symfonys projekt. Inkább attól hogy van benne 4000 fájl, aminek a felét/negyedét be is tölti. Persze azt a 1-2000 fájlt Te is létre fogod hozni, mivel ugyanúgy szükséges lesz bizonyos feladatokat szétválasztanod. pl:
- valamilyen biztonságos db függvényeket.
- routing függvényeket
- paraméterek kezelését segítő függvényeket.
- formokat és annak mezőit létrehozó függvényeket (erre már mindenképp egy/több osztály a legideálisabb)
- felhasználói üzenetkezelést kezelő függvényeket
- admin felületet generáló függvényeket
- és még sorolhatnám
Persze írhatsz egy darab index.php fájlt is...
Aztán miután elkészülsz a projekttel és szeretnéd máshová is eladni, kezdheted elölről, mert ott egy kicsit mást is kértek.
Beleszólhat egy (majdnem) teljesen zöldfülű?
Úgy gondolom, nem attól lesz valami objektum orientált, hogy egyetlen class-ba csomagolod. Ha pedig sok osztályod van, amiket minden egyes, a web szerverhez érkező kérésnél példányosítani kell, az már okoz némi overheadet. Megsaccolni sem tudom, mennyit lassít, de valamennyit biztosan. Ha pedig nagy forgalmú oldalt veszünk alapul, akár a felhasználók által is érzékelhető mértékű lehet(ne) az eltérés.
Ezt azért nem kellett volna. ;)
Az OOP kitalálása előtt is volt számítástechnika, léteztek nagy projectek, ott sem kellett mindent újraírni, ha máshová akartad eladni a rendszert.
De még1x: tévedés joga fenntartva! :)
Overhead...
Ahogy megvan annak is az overheadje, hogy a kismillió eljárást be kell nyalni, és memóriában tartani.
Az objektumorientáltság egyik értelme az, hogy az entitásokat és a velük végzett műveleteket egy helyen tartod, ebbe beleértve a különböző validációkat, amiket procedurális alapon, ha defenzív módon programozol, akkor neked kell minden egyes függvény esetén meghívnod, mert abból nem sokat tudsz megállapítani, hogy van egy array típusú változód. Objektumorientált módszertant alkalmazva az objektum-osztályok validációját elvégzi a Zend engine, és nem neked kell erre kódot írnod.
Egy dologban biztos vagyok: objektumorientáltan könnyebb, gyorsabb, biztonságosabb érzés dolgozni, és a procedurális módszerhez viszonyított időkülönbözetet fel lehet használni arra, hogy az ember optimalizálással és refaktorálással foglalkozzon, és adott idő alatt közel ugyanolyan sebességű és erőforrás-igényű rendszert kapjon.
Az objektumorientáltságnak nem a rendszer működése szempontjából van feltétlenül értelme, hanem inkább a fejlesztési folyamat részéről, és annak a gyorsításában, mert versenyhelyzet van a világban: aki hamarabb készít működő rendszert, az hamarabb tud szolgáltatni, hamarabb jut pénzhez, és hamarabb tud reagálni a változásokra is. Röviden: jó eséllyel életképesebb lesz üzletileg, mint a versenytársai. Cserébe lehet, hogy nem lesz annyi oka lengetni az e-péniszét, mint a csődbejutó versenytársnak.
Az objektumorientáltságnak
Attól, hogy objektumorientáltan programozol, nem fogsz gyorsabban dolgozni, procedurálisan is el lehet készíteni ugyanazt, ugyanannyi kódból.
Mégis miért kéne?
Az osztályok használatának mellőzése alatt nem azt értem, hogy az összes függvényt bevágjuk egy file-ba és kész. Ennek így tényleg semmi értelme.
Ellenben ha megoldjuk a funkció csoportok létrehozását fájl alapon, akkor lényegében ott vagyunk mintha osztályokkal dolgoznánk. Csak azt töltjük be, amire feltétlenül szükség van.
Emlékeim szerint php alatt is javasolt az 1 osztály / 1 file megoldás alkalmazása. Namost ha ezt osztály alapon betartjuk, akkor fájl alapon, függvényekkel pontosan ugyanezt szeparációt megvalósíthatjuk. Mésgem kell példányosítanunk objektumokat.
Hát az 1 osztály 1 fájl
beszólhat :-)
Pedig minden más megvalósítható procedurálisan is. :-) Például javascriptben úgy is készül egy objektum, hogy egy függvényt példányosítasz.
Még a statikus függvényeknél is?
Nagy projektek? Szerintem a legtöbb OOP nélküli "nagy projekt" egy hétvégén összedobható. Elég régi dolog ez az OOP. De amúgy igazad van, nem feltétlen kell amiatt újraírni. Csak kérdés, hogy hogy emeled ki a különböző funkciókat. Hogyan tudod megoldani azt, hogy egy funkciót felülírsz, ám utána egy javítás ne csak az épp aktuális projektet javítsa. Ha egy aránylag kicsi és egyetlen projektben gondolkozol, akkor nem kell OOP, és nem kell MVC se. De akkor meg azért nem érdemes vele küzdened, mert a 90%-át legenerálja bármelyik MVC keretrendszer.
Nagy projektek? Szerintem a
Ezt a kijelentésedet betudom fiatal korodnak, tapasztalatlanságodnak. :)
Persze ha te egy hétvége alatt összedobsz egy komplett vállalatirányítási rendszert a 80-as évek elején létező eszközökkel, akkor elhiszem, hogy igazad van.
MVC attól lesz, hogy
Én úgy vagyok vele, hogy php alatt elsőbbséget kell, hogy élvezzen a teljesítmény minden mással szemben. Kivéve persze a biztonságot!
Másrészt meg az OOP számomra inkább szervezési kérdés mint nyelvi. Tehát azt vallom, hogy egy jól szervezett "függvénytár" és hozzá tartozó vezérlő logika könnyen lehet, hogy közelebb van a tényleges OOP-hoz, mint egy rakás nyelvi osztály.
Az MVC meg ott van, hogy a vezérlés, az adatkezelés és a megjelenítés határozottan elkülönül nálam is. Vannak különböző template-ek, ezek alatt master fájlok, page és view fájlok. És egyik sem valósít meg semmilyen működési funkciót, csupán a megjelenítést végzi.
De inkább bemásolom ide az index.php jelenlegi - közel sem teljes! - tartalmát (az authenticate részt most raktam bele, csak úgy a teszt kedvéért - ezért ez nyilván még csak gyenge "demo"):
offtopic(?)
Meg tudnád mondani, miért include-okkal indítod a kódot, miért nem require-t v. inkább require_once-t használsz? Van valami konkrét oka vagy csak a megszokás?
csak megszokás
A *_once függvények viszont ha jól tudom lassabak mert ellenőrzik a korábbi betöltéseket is. Ezeket itt ezért nem használom. Mert felesleges ellenőrizni, hiszen az index-ben vagyunk.
Igen, én is úgy tudom, hogy
Tankjú!
Én nem úgy állok hozzá, hogy
persze, hogy könnyebb
Elentétben egy sokrétű desktop alkalmazással a php számomra egy igen egyszerű terület. Ahhoz képest amiket .NET alatt fejlesztetek egy oldal legenerálása számomra gyerekjátéknak tűnik. A nyelvi elemek, konvenciók és technikák elsajátítása, illetve működésük megértése jelent némi tanulni valót, de végső soron minden futás során egyetlen egy darab oldalt kell legyártani - a lehető leggyorsabban.
Én azt mondom, hogy ehhez tökéletesen elég kell, hogy legyen a különböző állományok "összeépítése" egy layoutban. Az összeépítéshez kíváló eszköz a php függvénytár - objektumok nélkül.
Szívesen venném, ha közzétennél egy-egy részt az általad megvalósított osztály alapú vezérlésből, mert így talán megértem végre, hogy mégis szükség van osztályokra valamiért.
Egyébként meg az életemet semmiképpen nem nehezíti a saját megoldásom sem most, sem később, hiszen én készítem. Ezen kívül kellőképpen moduláris a dolog ahhoz, hogy a továbbfejlesztés is könnyedén megoldható legyen.
Mégvalami. Erősen elgondolkodtam azon, hogy a php-s frontend mellett .NET (C#) backend-et készítek, ami így tökéletes desktop admin program lehet és php feladata kizárólag a megjelenítés lesz.
Dinamikus honlap
Így igencsak helytálló a te megközelítésed, hogy a PHP-t annak értelmezed, ami.
Update: éppen a napokban gondolkodtam azon, hogy egy link előállítása a rendszer mely részének a feladata (M-V-C)? Aztán végül visszanyúlva a desktop alkalmazások logikájához, valamint, hogy a kérdés hogyan van megoldva JS esetén, arra jutottam, hogy a nézet feladata. Mert egy link valójában nem más, mint egy eseménykezelő. És ugye itt látszik, hogy miért is érdekes játék HTML frontend-del, stateless HTTP protokoll segítségével alkalmazásokat gyártani...
+1 :) A linkek tényleg a
A linkek tényleg a View-hoz tartoznak. Elgondolkodtam kicsit a php-t hívó vezérlő elemeket, pl a lineket lehet remote action-nek tekinteni, mert végülis egy action-t vált ki a szerver oldalon. Ugyanígy az űrlapok is ilyenek. Végülis maga a php szempontjából View réteg is felépíthető MVC szerint, ahogy mondjuk extjs csinálja a gridekkel. Ott is vannak adatok, controllerek (amiknek egy része kérést küld a szerver felé), meg view, amit ténylegesen látunk.
Én sem hiszem, hogy a php oop kifejezetten szükséges, én is csak azért használom, mert objektum orientáltan tudok csak programozni, nem tudom strukturálisan hogyan szokták szervezni a kódot, és nem is szeretném megtanulni. Nekem ez így bőven jó. Kisebb munkáknál a strukturális programozás is megfelel, mert minek túlbonyolítani, a kérdés meg csak annyi, hogy kinek mi a kisebb munka... :-)
Másrészt meg az OOP számomra
ezzel nem értek egyet
Szóval ez számomra nem szempont.
A gondot az okozta, hogy nem
Hát most vagy a kollégával volt a baj, vagy a kóddal... Legalábbis én úgy olvastam, hogy az a jó kód, aminél ránézésre a változónevekből látod, hogy mit csinál...
Nálam ez a felállás...
Az alapvető problémám az OOP-vel, hogy szerintem fölösleges a weben ahol annyi a feladat, hogy generáljunk valami html-t, hiszen a következő requestre úgyis elveszítünk mindent és generáljuk elölről. Természetesen a procedurális programozásnak is megvannak a hátrányai, de ha megfelelően strukturáljuk a kódot akkor az is könnyen átlátható és jóval rövidebb, mint az OOP kód. A OOP előnyét a team munkánál látom, biztos könnyebb több embernek kezelni, viszont ez is csak logikus elrendezés kérdése.
Nálam kb így működik:
- index.php - ide fut be minden, ez van csak a web rootban
- config.php - környezet meghatározása, db kapcsolat, DEFINEok
- init.php - a minden oldalfutás során szükséges teendők elvégzése (COOKIE, SESSION ellenőrzések, jogosultságok (vengéd vagy tag vagy admin), url struktúra feldolgozása, majd az includeok kezelése és engedélyezése)
- functions_helper.php - közösen használt globális függvények (adatbázis / cache kezelése, input/output kezelések és whitelist stb)
- functions_global.php - az oldallal kapcsolatos általános függvények, természetesen célszerű minél több újrahasznosítható (paraméterezhető) kódot írni (általános felhasználói információk lekérése, login, kommentezés, oldallapozás, email küldés stb)
- functions_[aloldal].php - az aloldalak / modulok függvényei, csak az adott aloldalon tölt be
- [aloldal].css, [aloldal].js, ha szükséges, csak az adott aloldalon tölt be
- [aloldal].php - egyedi oldal vagy újrahasznosítható modul - a fenti függvények segítségével lekéri az információt és megjeleníti azt
Persze biztos gányolás(nak tűnik), de nekem nagyon bevált. Minden új oldal/sablon önállóan él és használhatja a globális adatokat. Nagyon egyszerű új funkciókat beépíteni az oldalba, mintha egy nagyon apró önálló php/mysql oldalt raknék össze. Ha egy aloldal túl bonyolult akkor lehet akár al al aloldalakat (modulokat) csinálni amíg kellően egyszerűvé nem válik. Akkor jó, ha 1-2 képernyőre ráfér a teljes kód.
Az egyes modulok különállóságából és egyszerűségéből következik, hogy minden egyes DB query-t agyonoptimalizálhatok / indexelhetek / cachelhetek, nem vagyok semmiben megkötve - kb üres is a slow query logom.
Van egy 3 szintű memória vagy fájl cache (mindegyik lehet lejárati idővel vagy anélkül, de azonosító alapján bármikor újrakérhető):
- minden egyes adatbázis kérés
- komplett modul vagy oldal
- generált html kódrészlet
Bár undorító, de az adatbázisomban is előfordulhat, hogy 1-1 dolgot több táblában is letárolok (csak ha úgysem változtatható). Ez egy csúnya kompromisszum, viszont így a legkomplexebb query is maximum egy db JOIN -t használ, azért ez nem rossz ha megnézel egy alapszintű drupál vagy joomla oldalgenerálást.
Persze a legjobb query az amit le se futtatunk, nálam átlagosan 95% jön cacheből - a memória meg olcsó és gyors.
Ha megnő a szerveren load akkor pl. automatikusan kikapcsol a kép és videó feltöltés / konvertálás vagy az elemek kommentezése, de ez eddig nem fordult elő (sajnos) :)
Ha mindent "szabályosan" csinálnék akkor már legalább 2 szerveren csücsülne az alkalmazás. Egyelőre bejött.
Weben
Azért szerencsére vannak alkalmazásszerverek, ahol nem ennyiből áll a dolog, azaz nem egy CGI szerű meghívás történik, hanem az alkalmazás folyamatosan fut, és igazából minden egyes új bejövő kapcsolat csak egy újabb függvény meghívását eredményezi. Léteznek ilyen rendszerek Java, Erlang, Python, és újabban a Node.js térnyerésével JavaScript alatt is. Ezekben az alkalmazás folyamatosan fut, és a bejövő kérések, mint egyfajta események történnek, azaz egy új szál nyílik az alkalmazáson belül, aminek van kapcsolata a többi vele párhuzamosan futó szállal, valamint természetesen a folyamatosan futó alkalmazással, ami tárolhat rengeteg prezisztens információt.
hogy jön ez ide?
akkor én sem vagyok már egyedül
A nyelvkezelést és a különböző tempalate-ek támogatását hogyan oldottad meg?
Sehogy...
Az init-et csak az átláthatóság miatt vettem külön, az az egy include nem oszt nem szoroz, APC vagy xcache amúgy is kell. Nézd meg a drupal include struktúrát, ha ennyit include-olsz akkor kezdhetsz aggódni :)
Érdekes volt Rasmus php előadásában, hogy megemlítette neki is jobban tetszett a régi procedurális programozás, mint ugyanazt megcsinálni 5x annyi OO kódban. :)
Ezt is érdemes megnézni - ha a php atyja a procedurális megközelítést szereti akkor nekem is megfelel. :)
Pontosan így látom én is, és
Semmiképp ne legyen saját,
PHPDoc
Meg még
CMS-t - ha muszáj - lehet értelme sajátot fejleszteni, de framework-öt nemigazán. Előbbit is csak ritka esetben.
Vitatkoznék. Mind
Nem csak az a CMS, amihez plugin bővíthetőség, sablononozhatóság és komplex admin felület jár, és nem csak az a framework, ami minden problémát lefed és lehetőséget biztosít a plugin alapú bövíthetőségre, módosíthatóságra.
Persze egy szint felett nem feltétlenül van értelme framework-öt írni, CMS-t egy adott framework-re alapozva annál inkább.
Én is
Valójában a fw, amit én kétlem, hogy volna értelme, azért, mert találtam egy olyat, amit most már különösebb gond nélkül, kedvem szerint alakítok (CodeIgniter). Így a fejlesztés rabszolgarészét megírták már helyettem, ami meg nem tetszik / jobbat tudok, azt átírom én. És ez nem ágyú, egész pici, "villámgyors" kis rendszer.
CMS-t viszont - őszintén szólva - szívesebben írok egy adott célra, mint felhasználjak meglévőt. Persze ez sokszor lényegesen több munka, és nem biztos, hogy megéri. És rengeteget kell biztonsági kérdésekkel bajlódni, ezért nem (sem) ajánlom másoknak, mert ha feltörik, csak magát szidhatja.
És rengeteget kell biztonsági
A népszerű cms-eket is érdemes ismerni ilyen szempontból, mert a robotok rápróbálkoznak a biztonsági réseikre. Szóval az ember sehogy nem ússza meg, hogy tisztában legyen a biztonsági kérdésekkel. Ilyen szempontból egy kevésbé tapasztalt fejlesztő, vagy az adott cms-t kevésbé ismerő akár öngólt is lőhet.
Fw kérdésben amúgy hasznos olvasmány: http://jtechlog.blogspot.hu/2011/05/miert-ne-fejlesszunk-sajat.html
Nagyon más
Nemrég talán PP-vel vitáztunk egy hosszabbat erről, ő érvelt azzal is, hogy igen, a népszerű CMS-ekre írnak robotokat is, de a rendszert több ezren fejlesztik, nem te egyedül. Így a robotnak sokkal nehezebb dolga van, mint az egyszemélyes projekt esetén. Erre mondtam én, hogy igen, de az ismeretlen CMS-re meg nem írnak robotot. Ezek vélemények, mindenkinek magának kell eldönteni, hogy mi a számára jobb.
Én itt a wl-en már számtalan olyan "beléptetőrendszert" láttam, amit egy óvodás is feltörne, ezért okosabbnak tartom nem reklámozni a suszterkedést. Persze tisztelet a kivételnek!, van nyilván nem egy fejlesztő (itt), aki nagyon jól meg tud írni ilyesmit.
Sajnos nem megy át a
A biztonság nem rendszer, hanem állapot kérdése, és nem függ attól, hogy népszerű, vagy ismeretlen CMS-t használsz.
"az ismeretlen CMS-re meg nem írnak robotot"
Mint írtam korábban is az évrendszered itt bukik, mert az ismert sérülékenységekre, amelyek egy webes alkalmazásban előfordulhatnak írnak robotokat. Ha igazad lenne, akkor a saját fejlesztésű, vagy zárt rendszereket nem találnák meg a SPAM robotok(gondolom ezt nem állítod, de szeretnék rámutatni az érvelésed hibájára). És ahogy a SPAM robotok megtalálják, meg fogják találni egyéb robotok is.
pp
Átjött az
Nem találtam azt a témát, belinkeltem volna, mert nem ennyi volt, ezt csak emlékezetből emeltem ki.
Ott is azzal érveltem, hogy egy olyan CMS-re, amit többmillió oldalon használnak, "jobban megéri" botot írni, mint ismeretlenekre. Ismert sérülékenység lehet számomra is ismert.
De mindegy, nem akarom ezt újrakezdeni, különbözik a véleményünk és kész. Itt (fentebb) pont azt az igazságodat (is) kívántam hangsúlyozni, hogy többezer fejlesztő többet tud általában, mint egy.
Off: Látom nem szereted, ha hivatkozok rád. Ez is átjött. :)
A cikk jó, de a kommentekkel
A mienk egy céleszköz, ami annyit tud, hogy a rendszerünkben generált adatokat megjeleníti, a keretrendszerek pedig általános feladatmegoldásra lettek kitalálva. Nyilvánvaló, ha ismerik őket eléggé, sok mindent gyorsan és hatékonyan meg lehet velük oldani.
Ez alapján inkább azt
Igaz
Már miért? Elég rossz
Például szükség esetén hogy
Az egyetlen igazán komoly probléma az egész témakörrel, hogy egy harmadik féltől függsz, akire kevés vagy nulla ráhatásod van.
Például szükség esetén hogy
Sehogy. Keretrendszert nem skálázunk, csak rendszert. És ha a rendszer úgy van megírva, hogy nem lehet skálázni, akkor az a fejlesztő hibája, nem a keretrendszeré, amit használ. Vagy a keretrendszer alkalmatlan arra, amire választotta, tehát a fejlesztő hibája.
Ennyire az adott rendszertől/nyelvtől stb is függsz, amire fejlesztesz. Vannak azért olyan keretrendszerek, amik belátható időn belül nem lesznek kivezetve. Hogy mást ne mondjak, nagy bankok sorra térnek át nyílt forrású keretrendszerekre, hogy csökkentsék a vendor függőségüket.
Plusz jól kitalált architektúrával és sw tervezéssel elérhető, hogy viszonylag fájdalommentesen leválasztható legyen az alkalmazás a keretrendszerről. Hogy visszadobjam eléd a kalapácsod, amit előszerettel dobálsz: erre való az OOP, a SOLID principles, design patterns stb :)
Sehogy. Keretrendszert nem
Nézd meg az ext.js komboboxának objektumhiearchiáját! Nyolcszoros objektumöröklődés, nyolcszoros mixin öröklődés, hat szükséges alaposztály, ez őrülten bonyolult! És mindez a következő funkcióhoz:
1, rakjunk ki egy beviteli mezőt
2, mellé rakjunk ki egy képet (lefelé mutató nyilacska)
3, ha bármelyikre kattintunk, nyíljon meg egy lista.
4, ha bármit kiválasztok vagy beírok, egy űrlapmező értékét állítsa be
Egyébként OOP, SOLID elvnek megfelel, tökéletes. Csak lassú.
Nagyon sokminden csak utólag, akár évek múlva derül ki, akkorra látod át az egészet.
Az ext.js esetében mégsem
Az ext.js kliensben fut, azt skálázni sose fogod tudni. Ha lassú, akkor lassú.
Lehet js-ben lassít a nagyfokú öröklődés, nem tudom. De akkor legalább van hova fejlődjön az engine-nek :) Ebben az esetben a UI designernek jár a fekete pont, nem feltétlenül az eszköznek. Meg a tervezőnek/architectnek, aki kiválasztotta az eszközt, és fejlesztés/production közben derült ki, hogy ez nem megfelelő a célokra.
Nagyon sokminden csak utólag, akár évek múlva derül ki, akkorra látod át az egészet.
Nagyjából azért lehet látni, hogy hol fog a terhelés jelentkezni, és hogy azt hogy lehet értelmesen kezelni. Plusz terheléses tesztek készítése (sok felkiáltójel). De ahogy mondtam is, ha lazán csatolod a rendszered komponenseit, vagyis értelmesen tervezel (és jó tesztjeid vannak), akkor menet közben lehet redesignolni, hogy jobban kielégítse az igényeket. Ha egy összedrótozott spagetti kódhalom az egész, akkor ez egy baromi drága mutatvány.
Végül írtatok nulláról egy
Én extjs3-at használtam, de nem voltam elégedett vele. A fa kirajzolója a rakat szorosan csatolt osztályból állt, egyáltalán nem volt használható általános célra. A drag&drop-ot is csak nagy nehézségek árán tudtam belőni arra, amire használni akartam. A vége csúfos kudarc lett... Szóval extjs-t szerintem csak akkor érdemes használni, ha minden benne van a példákban, amire szükséged van. Ha bármi egyedit akarsz, akkor gubanc lesz, mert ilyesmire nincs felkészítve. A nyolcszoros öröklődés meg szerintem tervezési hibára utal, én legalábbis nem tudom elképzelni, hogy bármi indokolna ilyesmit...
Igen, száz százalékig saját
Mert a kész rendszert meg
Az Ext.js-ről máshonnan is
Egyébként meg persze, kivételek minden alól vannak. Valamint hozzá kell azért tenni, hogy István írása főleg java frameworkökről szól.
Egyébként az egyszerre nagy
Azért választottuk az ext.js-t, mert úgy tűnt, ezzel legalább a megjelenítéssel nem kell foglalkozni, a példaprogramok alapján jónak tűnt, csak hát abból nem szabad kiindulni, ahol van mondjuk három űrlapelem, az persze gyors lesz.
Ez melyik verziója az
Négy fő verzió van, négyszer
A legjobb, hogy az ext.js alapkoncepciója jó, csak nem javascriptben, hanem natívan kéne megvalósítani.
Hát ha a böngészőkbe be lenne
premature optimalization
Az esetek nagy részében nem a PHP futtatása hanem az adatbázis műveletek szoktak a lassítani.
Ha a PHP kód lassú még mindig ott van a lehetőség hogy megméred, hogy mi a lassú és azt optmalizálod és nem előre a vakvilágba.
Vagy fordítva
Persze minden adatbázist el lehet rontani annyira, hogy számottevően lassú legyen, de aki így elrontja, az többnyire PHP vonalon sem zseni...
Nem tudom pontosan milyen
Azt én sem tudom,
Egyébként meg többnyire ugye valamilyen osztály(oka)t használsz "adatbázisozni", config fájlokkal, stb., ezek betöltése valószínűleg máris több, mint a lekérdezés idelye. Így, ha a kommunikáció idejét egyiknek sem tulajdonítjuk (vagy fele-fele), akkor is a PHP a "lassabb".
Míg a PHP-ben konvertálgatsz és HTML-t gyártasz, ugyanezt min. kétszer elvégzed.
De ha valaki "nagy mérőember" eldöntené, ill. felhomályosítana, megköszönném.
Ez sokmindentől függ, például
Na igen
Csak azért írtam, mert
Ez is igaz
elég nagy hülyeséget kell adatbázis-oldalon csinálni ahhoz, hogy látványosan lassabb legyen; de én is valaki hozzáértőbb véleményét is várnám már, hátha én tévedek.
Ha jól tudom ezt a fájl
Szerintem a page cache-re
Ami pedig az sql-t illeti, ha gépen belül van, használhatsz unix socketet, az elég gyors (gyakorlatilag kernelen belüli adatcsere). Hogy ennél mennyivel lassabb a tcp, az már erősen hálózatfüggő. De nyilván a tcp-nek, illetve a sok, nagy rekordmennyiséggel dolgozó adatbázisműveleteknek megvan az overheadje. Többek között ez az értelme a tárolt eljárásoknak is. Értelemszerűen sokkal gyorsabb, ha nem kell berángatni az adatokat adatbázisból, megrágni, aztán visszadobálni. Szóval ha ez tűnik a szűk keresztmetszetnek, érdemes ebbe az irányba gondolkodni. De a webes rendszerek nagy részénél szerintem nem ez a helyzet. Ha lassú a query, az jellemzően inkább user error.
Én konkrétan erre gondoltam:
A stored procedure egyébként nekem is bejön, gyorsabb, ad egy felületet az adatbázis elérésére, amire akár teszteket is írhatsz.
Mi MySQL-ben használtunk
Amiatt is sajnálom, mert a speciális jogosultságkezelésnek hála jóval biztonságosabb a lekérdezéseket tárolt eljárásban futtatni, mintha bele lennének "égetve" (lazán vagy szorosan) a kedvenc szerveroldali nyelvünkben készített programunkba.
Más a helyzet Postgresql-ben, ott több nyelven is lehet tárolt eljárásokat írni, ráadásul tudomásom szerint ezeket belső bájtkódra fordítja a rendszer, így gyorsabb lesz, mint n darab SQL hívás mondjuk PHP-ből.
Hát ja, mysql-nek még van
Attól függ, ha inkább csak
Result cache?
Találtam ilyet, amivel
http://mydebugger.com/
Mindjárt megnézem, hogy milyen...
Úgy néz ki a mysql tárolt
A pgsql-nél meg küzdök a szolgáltatóval, hogy ugyanmár ne us-en collation-nel kelljen dolgoznom... Nem is tudom melyik a szánalmasabb...
Arra gondoltam, hogy
A másik, hogy sokkal többet kéne alapoznom a triggerekre, mert bizonyos problémákat könnyebb megoldani velük, mint nélkülük... Ha csak ennél a példánál maradok, van egy permission_cache, amiben a felhasználók jogai vannak, és, amit frissítek, ha változik valakinek a szerepköre. Jelen esetben végig kéne járni az összes olyan felhasználót, aki kikerült a szerepkörből, és az összes olyat, aki bekerült a szerepkörbe. Hát ez trigger nélkül rémálom ... Egyelőre még próbálkozom, de lehetséges, hogy a megfelelő eszköztár birtokában mégiscsak lehet használható kódot csinálni mysql tárolt eljárásban is. Mondjuk nem lehet összehasonlítani semmilyen fejlett nyelvvel sem, szóval ha megcsinálják nekem a collation beállítást, akkor biztosan váltok pgsql-re.
Jó, akkor itt a mysql meg is
http://stackoverflow.com/questions/12638686/mysql-very-slow-loop
Nem lehet sok kicsi ciklust használni benne, mert baromi lassú egy normál nyelvhez képest, az ember meg azért használná, hogy gyorsabb legyen a kódja...
A pgsql-ben még reménykedem, hátha abban gyorsabbak a tárolt eljárások...
26 sec?
MySql:
Azt nem lehet mondani a pg-re se, hogy gyors. De azért nincs a fele sem. Összehasonlítva pl a javaval, ami ugyanezen a gépen ~31M loop/sec/core sebességgel tekeri ugyanezt a for ciklust, azért igen jelentős a különbség. Ok, java itt már natívban tolja, de akkor is.
De hozzá kell tenni, hogy a tárolt eljárás nem erre való, hanem arra, hogy ne kelljen nagy mennyiségű adatot áthúzni a programba és egyszerű műveleteket helyben el tudj végezni rajta. Kíváncsiságból lehet megnézem majd ezt oracle-n is, ha lesz rá kis időm a héten és nem felejtem el.
A teljesség igénye
Ja hát elég lassú. Végülis
each core on 100%
Ezt így hogy? :)
Triggerekkel azért óvatosan.
Kipróbálom, aztán meglátom.
Nem is a trigger debugolására
Amíg teljesen egy rétegben
Ezt hogy érted? Hogyhogy
A trigger - ha egy dologról beszélünk - egy adatbázisbeli esemény hatására fut le.
Mondjuk be van állítva, hogy adott táblából való törléskor fusson. Bemész SQL-ből, kiadsz egy DELETE parancsot. Lefut a trigger is. Közöd nem volt tárolt eljáráshoz, a triggered mégis lefutott.
Mit értek félre?
Azt, hogy a tárolt eljárás
offtopic - stackoverflow
Van egy értelmes, sokakat foglalkoztató, valóban szakmai téma, erre jön a nagyokos "moderátor" és lezárja, mondván, nem ideillő...
Valami hasonlóba egyszer én is belefutottam, azóta amennyire lehet, kerülöm a lapcsaládot. Pedig jó hely lehetne. :(
Hát ja, néha kicsit túllőnek
Azt kell mondjam, nem
Hogy ne vesszen el a tartalom, van aki gyűjti a törölt kérdéseket.
Én ezt értem, azt viszont
Technikailag kivitelezhető lenne, igény azt hiszem, bőven lenne rá.
Valahogy olyan érzésem van, hogy ezek amolyan cezaromániás dolgok. OK, hogy a flame-et megállítják, de az értelmes, szakmai vitákat teljesen lelőni...
Máshol még nem találtam ennyi IT szakembert egy helyen, mint azon a lapcsaládon.
(a linket köszi! :) )
Én megértem. Az oldal valóban
Tény hogy rengeteg a jó szakember. Van egyébként egy chat funkció is, ott is találni sok segítőkész hozzáértőt és ott nincs megkötve a kezed. Ha jól emlékszem, az épp azért lett létrehozva, mert volt igény a hagyományos diskurzusra is.
Hát igen
include(), require()játszik. Ha nem így lenne, akkor a fw-k legtöbbjében (is) lenne. Vagy én vagyok tudatlan?Az az érzésem, nagyon messzire elmentünk a szőrszálhasogatásban (már kezdjük túlbonyolítani), de szeretnék tisztán látni.
Hát szerintem nem sokban.
Akkor megállapodhatunk
Szerk.: Ezzel nem akarom azt mondani, hogy adatbázis-vonalon nem kell optimalizálni, sőt!
Én nem tudom, szerintem
szerk:
Konkrétat nem nagyon találtam, kb ezeket hozták fel, amiket felsoroltunk: IO, network latency, stb... Szóval szerintem konfiguráció függő, és nem lehet kijelenteni, hogy php-nél vagy mysql-nál van minden esetben. Esetleg egy profilerrel le lehet mérni egy adott oldalon. Azt hiszem ezt meg is csinálom valamikor a hétvégén az egyiknél, kíváncsi vagyok mit dob xdebug...
Egész érdekes dolgokat lehet
http://www.ohloh.net/p/boomerang-js
Ez egy apró js, ami méri az oldal betöltődését a felhasználónál, és visszaküldi az adatokat a szervernek...
Ez is egész hasznos kis pdf:
http://ilia.ws/files/zendcon2012_bottlenecks.pdf
Mondjuk azt már tudtam eddig is, hogy tájékozatlan vagyok a témában...
Blog
Na hát nem az a hétvége lett,
Az sql lekérés 1-2 msec összesen a microtime szerint, viszont itthon sokkal gyorsabb, mint éles szerveren terhelés alatt. Csak az autoload 300 msec-et elvisz a 200 osztállyal, mert nincs APC itthon.
Az automatikus parsolás rekordokról objektum gráfra szintén 300msec-et elvisz. Ezek ketten kiteszik az összidő felét. Érdekes módon a html generálás objektumokkal nem számottevő, pedig az ember azt gondolná, hogy a dom fa építés sokkal lassabb, mint a sablonozás...
Összességében nekem az jön le, hogy az adatmozgatás az, ami rengeteget fogyaszt. Egyrészt a fájlok beolvasása, másrészt az adatbázisból kiolvasás, és az automatikus átalakítás data transfer objectekre és hasonlókra. Ebben a kódban sokszor csinálom, hogy kiolvasok egy csomó rekordot, áttranszformálom őket mapping adatok alapján objektumokra ill. stringről más típusokra, aztán egy újabb sql-hez meg visszatranszformálom őket paraméter tömbre. Ennek nagyon magas a költsége, úgyhogy a stored procedure fix, hogy nagyon sokat fog hozni a sebességen. A másik, hogyha az éles szerveren külön gépen van az sql szerver, akkor szintén sokat hoz majd a stored procedure. A fájloknál jobb, ha nagyobb csomagokba teszem az osztályokat, ehhez majd írok egy csomagolót, ami névterenként egyberakja őket, és a fontos osztályoknál egyben betöltöm a teljes névteret. Ami még feltűnt, hogy a router-nél ellenőrzöm a fájlok meglétét, és ha nincsenek meg, akkor átírom a 404.jpg-re a képeket. Ez jó nagy hülyeség, inkább a dispatch alatt kellene lekezelnem az olyan kéréseket, amik képekre vonatkoztak. Hasznos dolog ez az xdebug...
Vannak vicces dolgok, láttam
Kicsit kozmetikázva ugyan, de
Magyarázat:
- ahol Class, Function, Args, stb vannak az a metódushívás vagy hívások, nincs minden logolva, tehát nettó php runtime
- ahol 5 jegyű hexa kód van (pl. ff576, sql query md5-je), az adatbázislekérés [ érintett sorok / lekérdezés ideje ] statisztikai adat a sor elején.
Hozzáteszem: a db szerver 9 ms-es ping időre van, tehát van némi overhead a nem helyi lokáció miatt.
Mindent mérek, így gyönyörűen látni a botleneckeket. Ja és előre is optimalizálok, mert van olyan, amiről már az elején tudom, hogy sok rekorddal csúnyán elszállhat a lekérdezési idő.
Én is valami ilyesmire
No, grabbeltem egy éles
Tehát 600 msec az adatbázis,
Egyszerű webshop, saját
Itt gondolom
Na igen
Tőlem aztán DB időnek is hívhatjuk a fetch-elést, mivel úgyis majd' minden query után kell, tehát kb. úgy lehet spórolni rajta, ha magán a query-n spórolsz (darabra).
De érdekes felvetés a stored proc is ebből a szempontból.
ExtJS, Sencha és a többiek
Vannak nagyon általános komponensek, amik kifejezetten arra készültek, hogy továbbépítsed, ilyen pl. a TriggerField. (mező amihez tartozik egy lenyíló akármi, ami lehet combobox, dátummező, színpaletta vagy tetszőlegesen egyedi megoldás) Illetve vannak nagyon konkrét komponensek, amik sebesség, hatékonyság miatt nehezen (vagy szinte egyáltalán nem) írhatóak felül, ilyen pl. a TreePanel. Ám, ha mégis ebbe az irányba szeretnél elmenni, akkor is, van lehetőséged tetszőleges Store készítésére és tetszőlegesen módosíthatod a DataView-ot is. Bármit fel lehet építeni, csak tisztába kell lenni vele, hogy mi a helyes irány.
Az Ext.Observer illetve az Ext.Element ugyanúgy megtalálható a Sencha Touch-ban is, és akkor a sebességről egy kis videó: http://www.youtube.com/watch?v=wCn3R3-XxBU
Vagy itt egy másik: http://www.youtube.com/watch?v=CvX241gK6gc
Nagyon könnyű az ExtJS-ben rossz kódot írni, sokkal könnyebb, mint JQuery-ben, mert maga a rendszer sokkal nagyobb, de ez nem az Ext hibája.
Egyszerűen nem látom, hogy
Minden kikapcsolható
Viszont azt nehezen hiszem el, hogy amikor egy/néhány programozó mindent a nulláról újraír, akkor hasonló precizitással építi fel az alapokat, mint azt az ExtJS esetén tették.
"Viszont azt nehezen hiszem
Ezzel nem értek egyet.
1. Ők is fejlesztők és lehet hogy a kis egyedi fejlesztés nagyobb tudással készül.
2. Ahogy minden keretrendszer az ExtJS is általánosított, vagyis nincs kihegyezve egy konkrét feladatra. Az egyedi rendszer adott esetben csak azt szolgálja ki amit ki kell, így egyszerűbb kód készül melyet könnyebb tesztelni is és javítani is. (persze csak ha nem vérPistike a fejlesztő).
Welcome! :)
Véleményem szerint pont a kliens oldali keretrendszerek esetén problémás a tesztelés, amikor elkészült az ExtJS 4-es, akkor azzal reklámozták be, hogy több mint 20 böngészővel működik. (nem tudom, hogy ez mennyire igaz, de jól hangzik:)
Semmiképpen sem mondom, hogy az ExtJS az egyetlen irány, de az biztos, hogy JS keretrendszer nélkül komoly webes alkalmazásokat építeni nagy butaság.
több mint 20 böngészővel
Hát ha működik a Chrome és a Firefox legutóbbi 10 verziójával, akkor már meg is van a 20.
:)
Alapvetően egyetértek. Nekem