Az egyre bővülő standardok kínálatából válogatni az ügyfél számára azt jelenti: a fejlesztés költségei alacsonyabbak lesznek, a megvalósítás viszont gyorsabb, és a tesztelt, már alkalmazott – és központosítható – modulok kevesebb hibát hordoznak magukban.
A Dream Portal CMS üzletileg is nagymértékben más, mint az előző verziók. A múltban a modulok megvalósításához jelentős egyedi fejlesztések kellettek, és ennek egyaránt a határidőkre és a költségekre hatása volt. Az egyedi fejlesztések velejárója a hosszabb teszt időszak, valamint az ehhez kapcsolódó hibajavítás is.
Új megoldásunk ezeket a nehézségeket kívánja minden szempontból hatékonyabban kezelni. Ügyfeleink egyre bővülő standard modulokból válogathatnak, illetve ezek kellő rugalmassággal szabhatóak az igényeikre. Ez az alábbi jelentős előnyökkel jár:
- Kedvezőbb költségek
- Gyorsabb megvalósítás
- A tesztelt, már alkalmazott modulok kevesebb hibát hordoznak magukban
- Központosítható modulok (egy portfólióhoz elegendő egyszer elkészíteni egy funkciót, amely aztán minden portfólió site-on egységesen jelenik meg)
Tervezett és fejlesztés alatt álló modulok:
- Hírek kezelése
- Szavazás
- Fórum
- Blog
- Űrlap varázsló
- Rugalmas jogosultság kezelés
- Kép és videógaléria
- CRM (email és SMS kimenettel)
- Rovatszponzoráció
Címkék: modul
Nagyon érdekes amit olvasok. Lenne egy kérdésem a modulokkal kapcsolatban, pontosabban egy modulról, amit manapság szükségesnek tartok és nincs a listában.
A cache mindig egy olyan dolog volt, amit sok szerkesztő nem értett, már kiejteni is fura, a szerepéről nem is beszélve. Viszont, ha ott lenne a cmsben az a lehetőség, természetesen megfelelő jogosultság mellett, hogy ezt tudja állítani és látja az oldalon a hatását, akkor sokkal egyértelműbb lenne, hogy az micsoda. Na meg nem kellene a fejlesztő kollégának belépnie a szerverre, hogy az egyik túl sűrűn frissülő doboz cache idejét magasabbra vegye.
A CMS természetesen tartalmaz beépített cache-t, hiszen e nélkül komoly terhelés alatt még egy egyszerűbb webalkalmazás is megadná magát.
A cache nem modulként épül a CMS-be, ez egy alapszolgáltatás, amit a modulok igénybe vehetnek. A cache-nek sokféle beállítási lehetősége van, amit konfigurációs fájlokban, vagy adatbázis táblában lehet tárolni. Az adatbázisban tárolt konfiguráció – megfelelő jogosultságok birtokában – elérhető az adminisztrációs felületről is. Ugyanez vonatkozik az egyes modulok beállításaira is.
Csak az ügyfél igényeitől függ, hogy mely beállításokat viszünk fel adatbázisba,
illetve hogy ezeket a beállításokat kik tudják módosítani. Így a fejlesztőkre tartozó paraméterek maradnak fájlokban, a (bizonyos) szerkesztők által is változtatható értékek pedig hozzáférhetőek lesznek. Az egyes blokk típusok cache-ét lehetséges állítani ily módon. Tehát meg lehet azt csinálni, hogy azt mondom: minden cikklista blokk legfeljebb 5 percig töltődjön gyorstárból.
Az egyes blokk példányok cache-elésést egyenként állítani nagyon erőforrásigényes lenne. Az egyes blokkok tartalma és az egyes blokkok paraméterei szintén adatbázisban tárolódnak (természetesen). Ha a cache-elési paramétereket is letárolnánk a blokkokhoz, az gyakorlatilag értelmetlenné tenné a cache-elést, hiszen minden megjelenéskor az adatbázishoz kellene fordulni, hogy megtudjuk, kell-e az adatbázishoz fordulni. Ezért ez utóbbi megoldás nem fog bekerülni a CMS-be.
Lehet nem fogalmaztam elég jól.
Arra gondoltam, hogy maga a cache beállítások lennének adatbázisban, de működés közben nem innen olvasná ki az engine. Hanem lenne egy kötött elérési útvonal (fájlcache, memcache) ahova a cache változtatáskor (amikor ezt adminból megváltoztatom) elmentődnek és egy egyszerű include segítségével használhatók (nevezhető ez a fájl layout cachenek, vagy bármi másnak – és tartalmaz minden adott layouthoz tartozó block lejárati idejét).