sYs-mini roadmap

Tekintve, hogy a sYs-mini és aD-mini rendszerek fejlesztése a legvégső fázisában tart, úgy láttam helyesnek, ha már publikálás előtt nyilvánossá teszem a sYs-mini fejlesztési útját felvázoló anyagot. A legutolsó publikus verzió óta jelentős változásokon ment át a rendszer, de ezeket itt és most nem fogom ismertetni - ahol szükséges, ott utalások lesznek ezekre a változásokra.

v0.5 - „Addict”

• Sablonozó: A use konstansok szintaktikája legyen parser-barát, használjon rövidített docblock formátumot. Ezen felül szükséges lesz a use-t kibővíteni egy include direktívával is, ami lehetővé fogja tenni, hogy az épp feldolgozott JS vagy CSS fájl határozza meg saját függőségeit (ez egyszerű replace még mindig).
• Bővítmény osztály bevezetése: A libekhez nagyban hasonlító osztályok, elvbeli különbségük csupán annyi, hogy ezek belső libként foghatóak fel, azaz a rendszer szerves részét képezhetik, de opcionálisak. Kezelésük legyen egységes.
• Könyvtár struktúrák: Rögzíteni kell az eddig kialakult legalapvetőbb könyvtárak struktúráját, a rendszerosztályok számára további tagolás bevezetése szükséges.
• Jogosultságok: Új jogosultsági rendszer kialakítása szükséges. Ahol lehet, az ellenőrzéseket a legmélyebb szintekig érdemes megvalósítani, hogy külön ellenőrzés csak speciális esetben legyen szükséges. A jogosultsági rendszer síkjai legyenek: futási környezet (hatáskör), vezérlő (tárgy), művelet. Jogosultsági szabály egyelőre csak felhasználóhoz legyen köthető.
• Adminisztrációs felület: Kerüljön véglegesítésre az alapértelmezett adminisztrációs alkalmazás a megfelelő ExtJS API-k létrehozásával, úgyis mint: Admin UI, Application Context, User Settings. A meglévő felületet szükséges lesz áttervezni. Szükséges lesz modulárisabb fejlesztési mintát bevezetni, azt a lehető legjobban támogatni (a template rendszerre támaszkodva). Az új fejlesztési mintában a JS fájlok beállításai váljanak el a programkódoktól (itt az új use include megoldásra lehet majd támaszkodni).

v0.6 - „Flowers”

Újdonságok, továbbfejlesztések:

• API Standard (új): Kidolgozni az API-kra vonatkozó standardokat, bevezetni a megfelelő osztályokat és dokumentációban rögzíteni azokat az elveket és módszereket, amelyek alapján egy új API kivitelezésre kerülhet. A kialakításnál kapjon hangsúlyt a hordozhatóság!
• Alkalmazás rendszerosztály: Az alkalmazás kezelje saját erőforrásait, az alá tartozó vezérlők regisztrálják ezeket az erőforrásokat. Az alkalmazás elsődlegesen regisztrálni legyen köteles saját névterét, és a névtér alatt használt könyvtárait.
• Alkalmazás névtér osztály (új): Gondoskodjon az alkalmazások névtereivel kapcsolatos megkötések maradéktalan betartatásáról:
  • A névtér azonosítója URI formában kerül megadásra.
  • A névtér gyökere a default alkalmazás.
  • A névterek egymásba ágyazhatóak, de nem létező névtérhez nem tartozhat gyermek névtér.
  • Egy alkalmazás névterében kötelezően léteznie kell az alábbi könyvtáraknak: cache, logs, models, services, views, controls.
  • Az alkalmazás névterében lévő könyvtár nem jelenti azt, hogy a könyvtár valóban az alkalmazás könyvtárán belül helyezkedik el, de a könyvtárnak léteznie kell az elérési útban (ha nem létezik, a rendszer megkísérli létrehozni 0777 jogosultsággal).
• Session API: A meglévő Session alrendszer standardizálásával és kibővítésével.
• User API: A meglévő User alrendszer bőkezű átalakításával és standardizálásával.
• Resources API: A meglévő Resource osztályok bevonásával, erőforrás kezelő osztályok kialakításával. Az erőforrás kezelő osztályok valósíthassanak meg PHP Stream Wrapper-t. Implementálandóak az alábbi wrapperek is:
  • Ctx: Szigorúan az adott környezet névterében lévő fájlokat teszi elérhetővé.
  • App: Az adott alkalmazás névterében lévő fájlt ér el - amennyiben a megadott névtér-relatív útvonalban a fájl nem létezik, a magasabb szintű névtérben keresi azt - csak akkor keletkezik hiba, ha a fájl egyik szülő névtérben sem létezik. Az ilyen jellegű korábbi fájl eléréseket erre a megoldásra kell cserélni.
  • Core: Csak a rendszer gyökérkövtárán belül elhelyezett fájlokat éri el. Általánosan alkalmazandó biztonsági okok miatt (külső összeférhetetlenség elkerülése).
  • Cache: Az aktuális futási környezethez tartozó cache könyvtáron belüli tartalmakat éri el.
• ClassLoader API (új): A meglévő megoldások összevonásával, javításával, jelentős optimalizálásával valósuljon meg az egységes osztály betöltés - egyszer s mindenkorra.
• HTTP API (új): Valósuljon meg a rendszer futási környezetéhez tartozó HTTP request és response rendszerelemek egységes felületen történő elérése, legyen lehetőség külső (valós) és belső (virtuális) request-ek létrehozására a factory pattern alapján. Ebben az API-ban kapjon helyet a jelenleg is létező, de önálló életet élő Router és a Request osztályok, valamint az URL-ek formázásáért felelős eljárás. Az új API-nak támogatnia kell a CRUD pattern alkalmazásonként eltérő alkalmazását is. A Router osztály a lentebb tárgyalt bővítmény osztályokat használja a jelenlegi Model alapú megoldás helyett.
• Widget API: A meglévő API standardizálása és áttekintése szükséges. A Widget API a sYstem Context API hatáskörébe tartozzon.
• XHTML API (új): Az új API-ban kerüljön összevonásra a jelenlegi sablonkezelő és a Fields alrendszer.
• XML API (új): Kerüljön kialakításra egy erős XML támogatást megvalósító API, amely egyszerűen és könnyen teszi lehetővé az átjárást a SimpleXML és a DOM osztályok közt, valamint támogassa az XSL osztály használatát.
• JSON API (új): A PHP natív JSON eljárásait és néhány ide tartozó segéd eljárást fogjon csokorba az új felület.
• RSS API (új): Az XML API-ra épülve támogassa RSS-ek összeállítását.
• Sitemap XML API (új): Tegye egyszerűvé és szabványossá a Sitemap XML-ek kezelését.
• Views API (új): A jelenleg meglévő View osztály alapmegoldásain túllépve támogassa központilag megjelenítési nézetek létrehozását, betöltését, példányosítását az egyes alkalmazások számára. A megoldáson keresztül valósuljon meg az XHTML, XML, JSON, RSS, és Sitemap XML API-k elérése.
• sYstem Context API (új): Az új API biztosítson lehetőséget alkalmazásnévterek szabványos kialakítására, ezen névterek futási környezethez rendelésére, alkalmazások kezelésére (lekérdezés, futtatás, kilépés). Foglalja magába a Widget, Views, Session, User, Resources, HTTP API-kat, támaszkodjon a ClassLoader API-ra. Tegye lehetővé az aktuális futási környezethez tartozó alkalmazás lekérdezését. Az egyes alkalmazások névtér szerinti azonosításánál ne legyen szükséges az alkalmazás osztályok betöltésére!
• sYstem Engine API (új): A meglévő Engine, Config, osztályok bevonásával és standardizálásával legyenek egységesen elérhetőek a kritikus fontosságú adatok és folyamatindítási eljárások. Az új API támaszkodjon a ClassLoader API-ra, és rendkívül gyorsan határozza meg a felhasználó által kért futási környezetet.
• Model alrendszer: Jelenleg nem standardizált, de általánosan használt eljárások standardizálása.

Optimalizáció:

• Utils osztályok bevezetése: A sehova nem tartozó függvényeket a functions.php-ből ilyen osztályokba kell átcsoportosítani, mivel a jelenlegi gyűjtemény kezd szétfolyni, a túlméretezett lib betöltése pedig időnként teljesen indokolatlan is - azaz felesleges terhelést okoz.
  
• Osztály betöltés optimalizálása: Ennek a jelenlegi - őskövületnek is mondható - megoldásnál sokkal gyorsabbnak kell lennie, a cél egy szükségességi alapon működő, önmenedzselő, class-merge alapú gyorsítás kialakítása.
  

v0.7 - „Forge”

• SEO Manager API: Valósuljon meg a keresőoptimalizálási megoldások integrálása. Jelenleg ennek alapjaival a rendszer rendelkezik, a cél tehát a meglévő elemek központosítása, további megoldások bevonásával.
• HTTP API: RESTful, Ext Direct és XML RPC támogatás.
• DAO: A jelenleg használt objektumstruktúra alapú rendszer eddig jól vizsgázott, ezért annak felhasználásával ki kell kerekíteni egy korrekt DAO megoldást. Olyan DAO kialakítása szükséges, amely támogatja az XML alapú adatbázis és model sémákat. A jelenlegi Model rendszeren sok változtatás nem indokolt, viszont meg kell oldani a specializáció egyszerűbbé tételét, valamint a jelenleg kísérleti jellegű de már standardizálódott metódusokat integrálni kell az alap model osztályba. A fentieken felül a DAO megvalósítás rendelkezzen a hatékony CRUD és View támogatás alapjaival, így tehát aktív rekord kezeléssel, data view-kkal. Valósuljon meg az adatforrások és tárolók egységes, transzparens kezelése. DataSource, DataAccess, DataStore, DataDirectory API-k társuljanak a kialakított DataView osztályhoz, a Record osztály kerüljön a DataAccess osztály hatáskörébe. A különböző adatelérő osztályok használják a v0.4-ben bevezetett Resource alrendszert (ezutóbbi jelenleg használaton kívül van).
• Lokalizáció: Valósuljon meg a lokalizációs alrendszer stabilizálása, a kísérleti jellegű eljárások áttekintése, értékelése, a jelenlegi rendszer szükség szerinti bővítése (például adatbázisban tárolt tartalmak többnyelvűsítése).

Folytatása következik!