4 x 5 perc, hogy weboldala megújulhasson!

RouterunnerCMS - Kompromisszumok nélkül

Cégünk, a Retroscope Creative 2009 óta foglalkozik webfejlesztéssel. Ez alatt az idő alatt többnyire olyan felkéréseket kaptunk, amiket vagy egyáltalán nem vagy csak nehezen lehetett volna megoldani az aktuális nyílt forrású tartalomkezelő rendszerekkel.

Ezeket az oldalakat végül mindig az általunk fejlesztett tartalomkezelővel szolgáltuk ki, melyből már két alkalmazást zártunk le, hogy újabb, jobb, rugalmasabb rendszert építsünk fel.

RouterunnerCMS - Kompromisszumok nélkül

Már az előző tartalomkezelő rendszerünk, a Dinascope CMS, fő alapelve is a rugalmas felépítés és a felhasználóbarát kezelőfelület volt. Ennek fejlesztését 1 éve fejeztük be, hiszen akkor már finisben volt az új rendszerünk, a RouterunnerCMS, fejlesztése.

Maguk a fejlesztési irányvonalak, igények már körülbelül 2 éve megvoltak és ez alatt az idő alatt folyamatosan bővítettük a listát, aminek majd csak nagyon sokára fogunk a végére érni.

 

Ebben a cikkben szeretném megosztani a tervezési, fejlesztési folyamatot, belelátva a RouterunnerCMS alapjaiba, működésére:

 

2014. január:

Tervezési alapok

Számtalan folyamatábra, adatstruktúra vázlat, felhasználói felület skicc után ebben az időszakban született meg az a 5 fő irányvonal, amit a RouterunnerCMS alapjainak tekintünk:

- egy jól átlátható, könnyen és gyorsan fejleszthető, könyvtár útvonal alapú frontend felépítés

- minden lehetséges helyen inline szerkesztői felület kialakítása a tartalomkezelő felületen

- minden olyan űrlap, beviteli mező, megjelenés, ami oldalanként, alkalmazásonként egyedi lehet könnyen lehessen szerkeszteni, személyre szabni és az oldal szerkezeti könyvtárában tárolódjon és ne a CMS-ben

- kis erőforrás igényű rendszer legyen, ezért csökkentettük a szükséges lekérdezések számát, template rendszer helyett natív php view-kat tölt be, ahol a model tulajdonságait php függvényekkel ágyazható be

- szakítunk az eddigi hagyományokkal és nyílt forrásúvá tesszük mind a frontend felépítést, mind a RouterunnerCMS rendszer alapjait, ezzel javítva a rendszer megbízhatóságát és növelve az ügyfelek biztonság érzetét

 

2014. február-május:

Útvonal rendszer és MVC szerkezet felépítése

Ebben az időszakban egy speciális ingatlankereső rendszer kialakítását végeztük és tudtuk, hogy ehhez a legjobb választás a még készülő RouterunnerCMS lesz. Bár a rendszernek bizonyos részei még csak a „tervasztalon” voltak meg, de ekkor már össze tudtuk állítani azokat a rendszermodulokat, amik megalapozták a CMS könyvtár alap útvonal rendszerének használatát és a model-view-controller szerkezet felépítését.

Itt még csak elméleti szinten foglalkoztunk a tartalomkezelő szerkesztői felületével, de erre az ingatlankereső szempontjából nem is volt jelentősége, hiszen a legtöbb adatot a felhasználók biztosították az oldal számára. Sokkal fontosabb volt, hogy a sokféle adatból álló ingatlanokat egyszerűen lehessen kezelni az oldalon és hogy ezek megjelenítését, keresését, szerkesztését kiszolgálja a RouterunnerCMS.

 

Az útvonal rendszer alapja egy ún. „scaffold” könyvtár, amiben megtalálható a frontend oldal felépítéséhez szükséges komponensek. A sitebuild olyan elemei, mint a stíluslapok, kliensoldali programok, képek lehetnek ezen a könyvtáron kívül is, de minden amire a RouterunnerCMS-nek szüksége van, az ezen a scaffold-on belül strukturáltan helyezkedik el.

 

Jelenleg legalább 5 fő könyvtárat tartalmaz:

- bootstrap: ebben a könyvtárban találhatók azok az indulás után közvetlenül lefutó szkriptek (a megjelenítési ágtól függően), amik meghatározhatják hogy milyen megjelenítési ágak fussanak le, mi kerüljön a meta adatok közé, mi jelenjen meg a breadcrumb-ban, stb.

- desktop: ez az alapértelmezett nézet gyökérkönyvtár. Több nézet gyökérkönyvtárt is tartalmazhat a frontend, mint pl.: mobil (ha a desktoptól eltérő felépítést szeretnénk mobileszközökre), mail (a különböző levelek megjelenésére), admin (ha egyedi admin felületet szeretnénk létrehozni) vagy például A/B teszteléshez egy teljesen új oldalfelépítést szeretnénk létrehozni, esetleg az új designt tesztelni egy kis számú felhasználóbázison

- i18n: a tartalomkezelő backend-jének nyelvesítéséhez szükséges fájl-ok.

- input: azok a beviteli mezők, amiket az oldal szerkesztői felületén használunk.

- model: felsorolva az összes model a teljes tulajdonságlistával megjelenés nélkül. Amennyiben nincs megadva egy útvonalhoz a model, akkor innen tölti be a rendszer, valamint új model hozzáadásnál is ezt az útvonalat használja. Valamint ennek a könyvtárnak a gyökerében található a tree.php, ami egy leíró tömböt ad vissza az oldal számára betartandó szabályokkal, hogy melyik model milyen gyermek modelleket tartalmazhat és hogy milyen ikonnal, szöveggel jelenjen meg az objektumfában.

 

A nézet könyvtárak felépítése részben kötött, hiszen ezeket a php-kat keresi a rendszer az útvonal feldolgozásakor. Az összes az adott útvonalhoz szorosan tartozó feldolgozandó szkript az útvonal nevével kezdődik, majd a fő feldolgozási irányt, majd ha van, akkor ezen belül szűrhető al feldolgozási irányokra.

Az útvonal feldolgozás alapjaihoz igénybe vettük a SlimFramework (http://docs.slimframework.com/) mikro keretrendszert, de ezzel nem rontottunk a feldolgozási sebességen.

 

A példánk egy termék megjelenítése lesz, tehát az útvonal a product nevet kapja ezen az útvonalon: scaffold/desktop/body/contents/product

A feldolgozási sorrend a következő:

1. product.runner.php – alap konstruktor, ami létrehozza az útvonal objektumot és csak minimális információt tartalmazhat a jogosultságokról. Ez az egyetlen kötelező szkript.

2. product.event.[get.|post.]construct.php – a konstruktor után közvetlenül lefutó esemény, ekkor még nem töltötte be a modelt sem. Megfelelő deklarálásra, egyedi jogosultságok beállítására, feldolgozás megszakítására, stb.

3. product.function.php – Az útvonalhoz egyedi függvénykönyvtárat lehet betölteni, ami csak ebből az útvonalból hívható meg. A felhasználása tetszőleges.

4. product.i18n.[hu.|en.|de.|…].php – Az útvonalhoz tartozó nyelvesítési fájl-ok. Csak az ezen az útvonalon található nézet szövegeit cseréli ki a megfelelő nyelvre.

5. product.property.php – Függvénytár, mellyel a modelhez egyedi tulajdonságok rendelhetők, akár úgy, hogy egy másik tulajdonság értékét módosítja. Pl.: olvasható dátum timestampből, szöveg levágás, stb.

6. product.model.params.php – A model betöltéséhez szükséges paraméterek. Egyelőre két megoldás használható:

- meg lehet adni direkt SQL lekérdezést

- egy beépített query builder állítja össze a lekérdezést az itt megadott változók alapján

A rendszernek nagy előnye, hogy tetszőleges tábla szerkezetet képes használni, sőt akár több táblát is össze tud kapcsolni egy model-re, elég csak a megfelelő lekérdezést megírni hozzá.

Ezen felül a force_list és a force_view változók true-ra állításával erőltethető a lista vagy az egyszerű nézet típus.

7. product.external.php -Külső hivatkozások beágyazása.

8. product.model.php – A model osztály maga, ezt példányosítja a rendszer minden objektumra, amit lekérdez.

9. product.script.return.php – Azokat a javascript parancsokat tartalmazza, amik jellemzően az ehhez az útvonalhoz tartoznak csak, tehát nem kell más útvonalon betölteni őket. Viszont megelőzve a betöltési problémákat, ez a szkript csak eltárolja egy előre lefoglalt változóba a kiírandó kódot és csak a lap megjelenítésének végén írja ki őket.

10. product.event.[get.|post.]before.php – Ez az esemény közvetlenül az előtt fut le, hogy a modelhez vagy az útvonalhoz tartozó nézetet elkezdené feldolgozni.

11. product.backend.container.[owner|group].php - A backend felület vezérléséhez szükséges paraméterek azon része, amik a modelleket magukba foglaló ún. konténer elemek meghatározására szolgálnak. Ennek a visszatérő tömbjében adható meg, hogy mi a konténer jQuery selector-a, milyen típusú modelleket fogadhat be vagy hogy az objektum fában milyen néven szerepeljen.

12. product.backend.model.[owner|group].php – Ez pedig a backend felület vezérléséhez szükséges paraméterek másik fele, melyek a model tulajdonságairól írja le, hogy azok melyik jQuery selector-ral találhatók meg, hogy milyen típusúak, kötelezőek-e vagy sem, van-e valami formai követelményük vagy hogy mi legyen az alapértelmezett értékük.

13. product.list.before.php – Ez a nézet alprogram akkor fut le, ha lista nézet jelenik meg és jellemzően arra használatos, hogy a listát magába foglaló elemeket megjelenítse. Pl.: a kezdő UL tag megjelenítése.

14. product.[view.|list.][owner|group].php – Ez maga a nézet, ebben van a megjelenítéshez szükséges HTML kód a beágyazott model tulajdonságokkal. A lista nézet akkor indul el automatikusan, ha több modelt kérdezett le az útvonal. Ha az útvonalban csak egy model van példányosítva, akkor alapesetben a view nézet lesz feldolgozva.

15. product.list.[null.|eqX.|divX.]php – Ezek a nézet alprogramok a lista megjelenítésben segítenek:

- null: akkor fut le, ha nincs lekérdezett model

- eqX: az X-edik modelt ezzel a nézettel jeleníti meg

- divX: minden X-edik elem után megjelenik

16. product.list.after.php – Ez a nézet alprogram a list.before ellentéte, ami a lista megjelenítés után fut le, hogy le tudja zárni a before-ban megkezdett elemeket, mint pl. az UL-t.

17. product.event.[get.|post.]after.php – Ez gyakorlatilag az útvonal destructorja, ami akkor fut le, amikor már minden mással végzett az útvonalon.

 

Persze egy részével már az elmúlt egy évben egészítettük ki a rendszert, ahogy újabb igények merültek fel, de nagy előnye az alapoknak, hogy ha újabb nézet vezérlőt is építünk bele, azt nem szükséges használnunk. Az egész alapja egy útvonal feldolgozó függvény, ami az útvonal létrehozásakor megvizsgálja, hogy milyen vezérlő fájlokat tartalmaz és azokat a fenti sorrendben és feltételek alapján feldolgoz.

Amennyiben a valamelyik nézet vezérlőben újabb útvonal lett beágyazva, akkor a vezérlő átugrik arra az útvonalra és csak akkor tér vissza az eddigi feldolgozására, amikor a beágyazott útvonallal már végzett.

 

Ez az útvonal alapú feldolgozás HTML oldalak felépítéshez tökéletesen megfelel, hiszen ugyanígy épül fel minden weboldal.

 

A soron következő cikkeinkben foglalkozunk még a RouterunnerCMS további fejlesztési folyamataival:

- adatbázis felépítése a szabad adatszerkezet kiszolgáláshoz

- helper függvények és template rendszer

- a tartalomkezelő rendszer alapjai

- tartalomkezelés személyre szabva

- jövőbeni tervek





Újévi üdvözlet

Újévi üdvözlet

Boldog Új Évet Kívánunk minden jelenlegi és jövőbeni ügyfelünknek és partnerünknek!

Olvassa tovább...

Kereső helyett felhasználói élményoptimalizálás

Kereső helyett felhasználói élményoptimalizálás

A keresőkben történt változásokkal kapcsolatos cikksorozatunk utolsó részében összegezzük az eddigi legfontosabb megállapításainkat és levonhatjuk a következtetéseinket. Cikkünk végén pedig konkrét segítséget nyújtunk abban, hogy hol tudja Ön is egyszerűen megnézni, hogy cége weboldalán keresőoptimalizálás szempontjából mi működik megfelelően és mi az, amin még javítania kellene, hogy előrébb kerülhessen a találatok között.

Olvassa tovább...

Címsorok, cikkek, lapok és domainek

Címsorok, cikkek, lapok és domainek

Mai bejegyzésünkkel újabb mítoszokat döntünk le a keresőoptimalizálás világából. Ahogy korábban írtuk a keresőoldalak időről-időre változnak és új szabályok alapján osztályozzák a weboldalakat. Többek között szó lesz a címsorok fontosságának elvesztéséről, arról, hogy milyen módon kell rendszereznünk a jövőben a tartalmunkat, hogy hány oldalon milyen hosszú cikkeket írjunk, valamint hogy miért fontos, hogy a címünket pontosan adjuk meg weboldalunkon és az utolsó fejezetben még egy kis pénzt is megspórolhatunk vállalkozásának.

Olvassa tovább...