Ivanhoe WebBlog - Ceglédi Iván jegyzetei

Bár elkezdtem a kódolást az alapoknál, kész a könyvtárstruktúra, megvan néhány core modul, de még mindíg nem látom teljes egésszében a készülő rendszert.

Belefutottam néhány anyagba, amit elolvastam, és úgy gondolom, a tervezéssel tovább megyek, mert későbbiekben sok plussz munkát spórolok meg vele.

A talált anyagok a program tervezési mintákról szólnak, és emítt olvashatóak:

• Általános tudnivalók nagyobb projekt tervezéséhez
• Az 5 leggyakoribb programtervezési minta

Egy logóvázlat....

pihenés képpen

Azért Bird, mert igyekszem felhasználó szempontból szabaddá tenni a rendszert az admin lapokon való keresgéléstől,

Arért green, mert a Fiam kedvenc színe

és azért view based, mert jól hangzik...

A rendszer úgy épül fel, hogy első körben egy keretrendszer szolgálja ki a kéréseket, és utána a cms egyedi programjai következnek. Ennek megfelelően a következő csomagstruktúra kialakítására gondolok:

• CMS csomag
  • Core alcsomag - könnyű keretrendszer
  • cms alcsomag - cms specifikus scriptek

A Core alcsomag elemei

• main.php betöltő script, a rendszerfolyamat futását alapszinten kezelő script
• ClassFactory.php az includepath-okban beállított helyekről autómatikusan szerzi be az osztályokat név alapján, a példányok referenciáit önmagában tárolja, nem engedélyez ismételt példányosítást, ha csak adunk erre külön utasítást
• ClassConfig.php kérésre konfigurációs file-okat tölt és ment - ha szükséges, és a konfigurációs értékeket közvetíti
• ClassXSSFilter.php a bemeneti globális változókban végez szűrést nem kívánt tartalmak elkapására
• ClassInput.php inputokat teszti elérhetővé, ha nincs rá külön tiltás, futtatja az XSSFiltert
• ClassTemplate.php a template Lite-t teszi elérhetővé, állítja be
• ClassDB.php adodb osztály kapcsolat
• ClassSiteBuilder.php a core és a cms alcsomagok kapcsolásáért felel

A korábbi folyamatleírás átgondolásából kihozható némi egyszerűsítés, ami soha nem jön rosszul...

Tehát a rendszer vizsgálja először az post adatokat, ha valamely modul lekérdezést végez, akkor ezt előre veszi, egyébbként meg az url-nek megfelelő modul-set-tet futtatja és tolja a templátba.

Hú ez jól leegyszerüsödött.

A lenti írásból látható, hogy a rendszer menüvezérent. Az url-ben tehát a drupal-os megvalósítás szerint átadjuk a menüpont (csomópont) azonosítóját, utána jöhetnek a barátságos szövegek:

http://enoldalam.hu/321/ez_most_egy_menupont_itt.html

A moduloknak is adjunk azért lehetőséget arra, hogy hívhatóak legyenek, ez hasznos lehet pl. ajax kérelmek fogadására

http://enoldalam.hu/mod/felhasznalok/regisztracio

Ekkor a felhasznalok frontkontroller meghívja a regisztráció konrollert, és futtatja

Az ajaxmod paraméter hívása esetén csak az adott modul kerül futtatásra, csökkentve a terhelést. Ilyenkor nincs feldolgozva a teljes template, csak az adott modul.

Ha a program nem tud értelmezni csomópontot, vagy a csomópont nem létezik az adatbázisban, akkor az alapértelmezett menüopont az index oldal. Ha nincs ilyen beállítva, akkor az adott nyelv első elérhető csomópontját ábrázolja a rendszer. Ha modult hívunk közvetlenül, akkor a megállapított csomópont eldobásra kerül.

Amikor Marco installálja a rendszert, egy üres oldalt lát egy belépési ponttal. Belép, beírja, hogy admin/admin, és elküldi.

Ezután a honlap különböző pontjain kis menü ikonokat lát, mást nem. A menü ikonok javascripttel kerülnek a helyükre, mindíg a templátban megadottak szerint, ahol is helyörzők jelölik azon blokkok kezdetét, ahova dinamikus tartalmat szúrhatunk be.

A kis ikonra kattintva egy modal ablakból kiválaszthatja, milyen modult ad az adott helyhez. Kiválasztja pl. a menü modult, hiszen most kezdi építeni oldalát. Elküldi, az oldal frissül, de most sem lát túl sokkal többet, csupán az előző helynél megjelenik egy újabb ikon, a modulbeállítást jelölő. Erre rákattint, modal fel, benne tabokkal tagolva:

1. Menüpontok szerkesztése
2. Menüsablon

Menüpont szerkesztése résznél Új-ra kattint, megjelenik egy form, a következőkkel:

1. menüpont cím
2. külső link: ha kitölti, akkor a többi beállítás nem számít, hiszen nem kapcsolódik az oldalon tartalomhoz
3. index oldal? checkbox, azaz, hogy az oldal alapesetben ezt a lapot mutassa-e
4. hozzáférésiszint, pontosabban szerepkör, erről később. most beállítja, hogy mindenki.
5. látható? Marco Igen-en hagyja, hiszen ezért csinálja az egésszet.

Menüsablonra kattintva listából kiválasztja a menüsablont, azaz hogy hogy nézzen ki a menü, ezt a dizájner kolléga mellékeli a tervhez, és a blokkhoz tartozó mappából utómatikusan szűri ki a rendszer

Lementéskor megjelenik a menüpont egy táblázatban, újabbakat adhat hozzá, almenüket hozhat létre, sorrendezheti őket.

Ha ezzel megvan, kilép a menüszerkesztőből, és hurrá, megjelenik a kívánt kinézetben a menüpontunk a kiválasztott helyen.

Marco rákattint, hogy lássa, mi lesz.

Ekkor a dizájner kolléga által előre 'komponensblokk'-ként meghatározott helyen, azaz a tartalmi részen megjelenik egy kis komponensbeállítás ikon. Rákattintva a köv. lehetőségeket választhatja modál ablakból:

1. Cikk - írhat egy cikket: cikk modul
2. Főoldal - Az írásokból kiemelt főoldalra jelölt cikkeket rakja k: főoldal modul
3. Mindenféle elérhető modulok listája

Kiválasztja a cikket.

A lap frissül, megjelenik egy cikkszerkesztő, plussz pár kérdés, hogy hozzáad-e valamilyen plug-int, kikerül-e a főoldalra, meta adatok.

Lementi, látja is a cikket ahogy kell, alatta szerkesztés gombbal, felette - mivel ez a komponens egy modulja, a modulra vonatkozó beállítási lehetőségekkel, melyek

1. Mozgatás le
2. mozgatás fel
3. Eltávolítás

Mivel így kicsit snassz a kezdőlap, Marco a cikk alatt lévő modul hozzáadás gombbal hozzárak még egy pár dolgot, egy három hasábos jegyzetlapot, ahova linkeket helyez el, egy youtube videót magáról és a barátnőjéről, és egy kis galériát néhány képpel a kutyájáról. A kutya után még felrak egy főoldal modult is, hogy változzon gyakran a kezdőoldal.

Megvan hát a kezdőoldal, csillog villog, így kirak még 3-4 menüpontot, s lassan összeáll az oldal.

Szóval van már egy főmenüje, és feltöltötte az oldalt tartalmakkal. De az oldalsáv üres, oda is kellene valami.

Jó lenne oldalra is egy menü. A jobb sávon is van egy modul hozzáadása ikon, klikkel hát, hozzáad egy menü modult, kirak pár linket.

Szeretne egy szavazást is, de azt szeretné, ha csak akkor látszana, ha az egyik almenüben vagyunk, egyébként nem lenne kint. Minden nem menüponthoz rendelt modul rendelkezik egy Láthatóség ikonnal, ahol két dolgoz állíthat Marco:

1. Milyen szerepkörrel rendelkező felhasználó láthatja, ezt beállítja mindenkire
2. mely menüágtól legyen látható a modul.
3. mely menüágtól ne legyen látható a modul vagyis ha belépek a blog menüpontba, tűnjön el pl. a linkajánló modul oldalról, és legyen helyette egy blog naptár...

Marco nem töltött túl sok időt tehát a honlap összepakolásával, mindent ott szerkeszt, és ott állít be, ahol a kész oldalon látni fogja.

Pár globális beállítás van hátra, amiket a kilépés mellett lévő központ gombra kattintva ér el. A tartalmi részen megjelenik pár ikon, ami az adott feladatok elérését biztosítja, globális beállítások, cikkkategóriák, médiakezelő, azaz installált modulok elérését teszi lehetővé.

Mivel azonban Marco keni a spanyolt, szeretné spanyolul is látni az odlalát.

A központban a nyelvek modult választja, ott hozzáad egy nyelvet, feltölt egy zászlócskát, okézik.

Kirak jobbra egy nyelvi modult, ami megjeleníti a zászlókat.

Rákattint a spanyolra, és látszólag nem történik semmi, csak egy csillag jelenik meg a menüpontok neve előtt, jelezve, hogy ezek fordításra várnak.

Valójában a teljes oldalról egy másolat készül az adatbázisban, ahol minden ott és úgy van, ahogy az eredeti nyelven elkészítette, csak fordítani kell a szövegeket, menüpontokat.

A modulok fordítását egy beépített fordító segíti, amelyet a vezérlőpultról ér el.

A spanyol nyelvű oldal azonban ekkor elválik az eredeti nyelvűtől, akár teljesen más menüstruktúrát is építhetne, más modulokkal, más template-tal, de markó ezzel nem foglalkozik, megnézi inkább a felhasználók kezelését, hogy az hogy megy.

Látja önmagát, mint egyedüli szereplőt a listán, rákattint, átírja a nevét Adminról Marco-ra, meg jelszót vált, látja, hogy minden modulhoz hozzáfér. kilép, felviszi a barátját, regisztrált felhasználóra állítja. Ezután a szerepkörökben beállítja, hogy a regisztrált felhasználó a komment modult használhassa.

Marco elégedett,.

Futás szempontjából a jelenleg képzelet felhőkön lebegő cms követné azt a sémát, amelyet elődei kikoptattak, miszerint a dinamikus tartalmak, és az azokat befolyásoló folyamatok a következő leosztásban jelennek meg kódszinten - az én értelmezésemben:

1. Komponensek
2. Modulok
3. Plug In-ok, beépülők

A komponensek tartalomtípusokat jelenítenek meg. Ilyen pl. a cikkek, webáruház.

A modulok olyan önnálló létezésre képes programok, melyek a honlap különböző dobozaiban helyezkednek el. Komponensnek lehet modulja vagy fordítva, azaz hivatkozhatnak egymásra, kapcsolhatóak egymáshoz, stb. Pl. írok egy klassz cikket, és felrakok hozzá egy szavazást... vagy képeket, vagy google maps-ot., commenteket, stb.

A plug-in a komponens működését befolyásoló program. Pl. kódkiemelő, hozzászólások, megosztás, stb...

Programfutás folyamata szerint a modulok mikor fussanak le a komponenshez képest? Ha a komponens futása előtt kerülnek értelmezésre, akkor bizonyos módosítások nem lépnek életbe. Pl. belépés az oldalra panelen be szeretnék jelentkezni, mert nem látok egy védett tartalmat. A belépést egy modul intézi. Belépek, de visszakapom, azt hogy lépjen be az oldalra, iszen a modul a komponens után futott le.

Tehát definiálni kell, hogy a modul-plugin mikor hajtandó végre, a kontroller előtt, után ...

Nézzünk egy lehetséges programfutási sémát:

• vizsgáljuk, jött - e valamely modulra vonatkozó kérelem, ha igen, ezeket futtatjuk.
• kigyűjtjük a futtatásra kerülő modulokat,
• meghatározzuk a komponenst
• megszerezzük a komponenshez rendelt plug-in-okat.
• futtatjuk a komponenst, ami
  • vizsgálja, melyik modul futtatandó a kontroller előtt, ezeket indítja
  • elkészíti saját kimenetét
    • a kimeneten lefuttatja a megfelelő plug-inokat
  • futtatja a kontroller után esedékes modulokat
  • kilép
• mehet a template-rendszerbe a kimenet

RoliSoft oldalán találtam ezeket a pontokat, melyekre érdemes odafigyelni fejlesztés közben. Bár az oldalon teljes egésszében elolvasható, de ide is beröffentem, mert szerintem nagyon lényeges gondolatok vannak megfogalmazva alant.

http://rolisoft.net/blog/tippek-php-kod-optimizalasahoz.html

• Ha egy osztály lehet statikus is, akkor használd deklaráld mint static class; körülbelül négyszer lesz gyorsabb.
• Az echo sokkal gyorsabb mint a print.
• Csökkentheted a memóriahasználatot, azzal, hogy több paramétert adsz meg az echo-nak, ahelyett hogy összeragaszd a stringeket:
  

  echo '<title>', $oldal['cim'], '</title>';

• Használd az unset() függvényt, hogy szabadíts fel memóriát. Főleg ha hosszú stringekkel vagy nagy tömbökkel dolgoztál, és már nincs rájuk szükséged.
• Tartsd magad távol a __get(), __set(), __autoload() meg hasonló megoldásoktól.
• A require_once() sok erőforrást igényel. Ne használd.
• Ahol csak lehet használj teljes útvonalakat a fájlokhoz, így nem kell felesleges időt eltöltenie a fordítónak rendszerhívásokkal, hogy megtalálja a teljes útvonalat.
• Ha meg szeretnéd tudni a kódod mikor kezdte a futását akkor használd a $_SERVER['REQUEST_TIME'] változót, ahelyett hogy újat hozz létre a kódod elején.
• A reguláris kifejezésekkel sok mindent meg lehet oldani, viszont nagyon lassúak. Próbáld meg először megoldani a problémád a strncasecmp(), strpbrk() vagy stripos() függvényekkel.
• A str_replace() sokkal gyorsabb mint a preg_replace(), a strtr() viszont négyszer gyorsabb a str_replace() függvénynél.
• Ha egy függvény, mint például a str_replace(), elfogad tömböt és stringet is paraméterként, a te listád viszont nem nagy és nem változó, akkor inkább többször hívd meg a függvényt, minthogy egy tömböt adj át neki.
• Jobb ha switch-et használsz sok if/else helyett.
• A hibaüzenetek elhallgattatására használt @ nagyon lassú.
• A hibaüzenetek sok erőforrást igényelnek; óvakodj tőlük.
• Kapcsold be az Apache mod_deflate modulját. Akár 80%-al is összetömörítheti az oldalad, így kevesebb lesz az adatforgalmad.
• Zárd be az adatbázisaid kapcsolatait miután már nem használod őket vagy a kód végén.
• Ne használj függvényeket a for() ciklusaidban!
  

  for($i = 0; $i <= count($tomb); $i++) // A count() meg lesz hívva minden egyes ciklusban!

• Az $adatok['ar'] hétszer gyorsabb, mint az $adatok[ar].
• A globális változók kétszer gyorsabbak, mint a helyi változók.
• A leggyorsabb a helyi változó növelése. Majdnem olyan, mint egy helyi változóval dolgozni egy függvényben.
• Egy objektum változójának növelése a leglassúbb. Például a $this->valtozo++; háromszor lassúbb mint egy helyi változó növelése.
• Egy nem deklarált változó növelése tízszer lassúbb, mint egy deklarálté.
• A jelenlegi osztályban található függvények hamarabb lefutnak, mint a szülő osztályban található függvények.
• Egy üres függvény egy paraméterrel körülbelül annyi futásidőt használ, mint nyolcszor egy helyi változó növelése.
• Ha a stringjeid ' közé rakod " helyett, akkor sokkal gyorsabban fognak lefutni, mivel a "-ben a PHP keres változókat is, míg '-ban nem.
• Egy PHP fájl 2-10x lassabban lesz kiszolgálva az Apache által, és több erőforrást is igényel, mivel lefut a PHP compiler is. Ha a fájl nem tartalmaz PHP kódot, akkor statikus fájlként tárold.
• A PHP kódjaid minden egyes futásnál le lesznek fordítva és csak utána futtatva. Sok időt és erőforrást takaríthatsz meg, ha telepítsz egy olyan modult amely cache-elni a lefordított kódot, így nem kell minden futásnál újrafordítani. Ilyen például az APC.
• Cache-elj minél többet. Ahelyett, hogy minden egyes kis adatért kérést küldj az adatbázisodnak (pl MySQL), használj inkább memached-et.
• Mikor biztos kell légy benne, hogy egy stringnek megvan egy bizonyos hosszúsága, akkor normális esetben meghívod rá a strlen() függvényt. Habár a strlen() egyáltalán nem egy terhelő függvény, mégis egy függvény, és lassú a meghívása a következő trükkhöz képest:
  

  if(!isset($nev{5})) die('A név rövidebb öt karakternél.');

  Az isset() nem egy függvény, hanem egy nyelvi konstrukció, így sokkal gyorsabb a meghívása.
• Ha egy változó értékét növeled vagy csökkented, az $i++ lassúbb mint, a ++$i. Ez az érdekesség csak a PHP nyelvben van jelen. Az $i++ meghívásakor a fordító készít egy átmeneti másolatot, megnöveli, majd ezt visszamásolja az eredeti változóba; a ++$i viszont már egyből a kért változó értékét növeli.
• Nem kell mindent OOP-ban megírj. Sok memóriát használ.
• Nem kell mindenféle adatnak saját osztályt írj, majd ebben tárold; így nagyon sok memóriát pazarolsz el. Ilyen célra vannak a tömbök.
• Ha olyan függvényekkel dolgozol, amelyek nagyon sok erőforrást és időt használnak, próbáld meg őket átírni C nyelvre és töltsd be mint PHP kiterjesztést.
• Használj egy code profilert, mert ezek megmutatják a kódod melyik része a lassú. Ilyen például az xDebug.

Kicsit körbenéztem a neten, találtam is két jó tutorialt az MVC felépítésről:

Anant Garg összedob egy CMS-t

Kevin Waterson MVC leírása.

További olvasnány:

Adatbázis absztrakciós réteg

Tehát készítünk egy  CMS-t. Összefoglalom a rendszerrel kapcsolatos kívánalmakat először vázlatosan:

Fejlesztői szemszögből:

1. Szempont, hogy MVC szerkezetű legyen. Korábban készítettem már CMS-t, ami használható is, de nehézkes a ráfejlesztés, a kódújrahasznosítás.

Felhasználói szemszögből:

1. Nincs elválasztva az adminisztráció a normál nézettől (lásd Exponent CMS)
   
   
2. A template rendszer a szokásos MVC feldarabolástól eltérően designer barát legyen: egy fő file tartalmazza a megfelelő elemeket, csupán a különböző doboztartalmak kerüljenek külön könyvtárakba. A stílus váltasztható legyen.

Webnaplóm egy php cms rendszer fejlesztése-fejlődése körüli bejegyzéseket tartalmaz majd.

Hamarosan jelentkezem...

echo('Szia Világ!');