Portál építés egy hosszú fő függvényre építve szerintetek jó?
Általában nagyon jó instrukciókat kapok különböző,
fórumon feltett kérdéseim megválaszolása alkalmával a jövőbeli fejlesztések technikai megvalósítását illetően.
Így tanultam meg hogy a html jobb css-el.
Sőt inkább xhtml. Na meg táblázatot csak arra használjunk, amire való.
A php és html szétválasztása valamilyen template rendszer segítségével. Osztályok alkalmazása, OOP szemlélet.
Az OOP szemlélettel kapcsolatban Megjegyzem egyik nagyobb projekt, vagy cms kódjában sem láttam, hogy csak osztályokkal dolgoztak volna.
Szeretnék újra útmutatást kapni, hogy hogyan tovább...
Amit utoljára csináltam portált, az tulajdonképpen smarty-val, tisztán osztályokkal, táblázat megfelelő használatával készült.
Lesarkítva úgy néz ki a dolog, hogy egyetlen osztály egyetlen függvénye irányít mindent, meghívva a többi osztály megfelelő függvényeit.
Maga a (fő)függvény egy elég hosszú:) feltételes utasítás, ami tulajdonképpen megjeleníti a megfelelő template-et, és meghívja a megfelelő függvényeket a kapott $_REQUEST paraméterek alapján.
Nem konkrét kódokat várok, csak tanácsokat és megoldásokat nagyvonalakban.
Vagy véleményeket az én módszeremmel kapcsolatban.
Biztos van a portál, vagy esetleg cms építésnek kiforrottabb, átláthatóbb, karbantarthatóbb, viszonylag általános megoldása, megoldásai.
Tehát a lényeg... Ti hogy csináljátok, hogy csinálnátok?
■ fórumon feltett kérdéseim megválaszolása alkalmával a jövőbeli fejlesztések technikai megvalósítását illetően.
Így tanultam meg hogy a html jobb css-el.
Sőt inkább xhtml. Na meg táblázatot csak arra használjunk, amire való.
A php és html szétválasztása valamilyen template rendszer segítségével. Osztályok alkalmazása, OOP szemlélet.
Az OOP szemlélettel kapcsolatban Megjegyzem egyik nagyobb projekt, vagy cms kódjában sem láttam, hogy csak osztályokkal dolgoztak volna.
Szeretnék újra útmutatást kapni, hogy hogyan tovább...
Amit utoljára csináltam portált, az tulajdonképpen smarty-val, tisztán osztályokkal, táblázat megfelelő használatával készült.
Lesarkítva úgy néz ki a dolog, hogy egyetlen osztály egyetlen függvénye irányít mindent, meghívva a többi osztály megfelelő függvényeit.
Maga a (fő)függvény egy elég hosszú:) feltételes utasítás, ami tulajdonképpen megjeleníti a megfelelő template-et, és meghívja a megfelelő függvényeket a kapott $_REQUEST paraméterek alapján.
Nem konkrét kódokat várok, csak tanácsokat és megoldásokat nagyvonalakban.
Vagy véleményeket az én módszeremmel kapcsolatban.
Biztos van a portál, vagy esetleg cms építésnek kiforrottabb, átláthatóbb, karbantarthatóbb, viszonylag általános megoldása, megoldásai.
Tehát a lényeg... Ti hogy csináljátok, hogy csinálnátok?
az én rencerem
Én modulos felépítésű rendszert alkottam, ezek közül van olyan modul, ami nyilván szükségszerű a futáshoz, meg olyan, ami nem. A portal modul igazából a legfontosabb, az hívja be a dblayer, log, user, cms, template modulokat, majd elvégzi a kívánt utasítást. (a dblayer az adodb, a template pedig a smarty implementálása, a log nyilván a loggolás - adatbázisba, a user modul pedig a felhasználókezelés, ez eldönti, hogy az adott oldalletöltő a három automatikus csoport melyikébe tartozik /látogató, bejelentkezett, admin/ )
Nem érzem, hogy nagynak kellene lennie a dolognak ahhoz hogy fusson. A portal modul feladata, hogy a szabályos rendben lévő fájlokat behúzza, illetve a szintén szabályos elnevezéssel ellátott osztályokat példányosítsa. A rendszermodulokat nyilván automatikusan, ha azoktól eltérő modult hívunk meg, akkor pedig szintén automatikusan betölti (így fölöslegesen nem kell semminek include-olódnia).
Egyébiránt a modulook oldalakra és azon belül tevékenységekre vannak nálam lebontva, az 'oldal' az egy PHPfájl, a tevékenység pedig az abban a fájlban található objektum metódusa. Így ragyogóan lehet a jogosultságokat 3 szinten is megadni. (Teszemazt a gallery modul 'main' és 'admin' oldallal rendelkezik, és így az X csoportnak megadhatom a gallery/admin/all jogot, míg a többiek a gallyer/main/all hozzáféréssel bírhatnak - természetesen ezen felül van a galéria modulban megfelelő jogosultságkezelés album/kép szinten) - a main oldal az alapértelmezett, ha nincs megadva semmi, illetve az első definiált metódus az alapértelmezett, a futáskor, így ha nincs megadva minden paraméter, akkor sincsen gond.
És igazából szerintem a lényeg a szempontodból:
Jelen pillanatban én tartalom kesselést még nem használok, de már dolgozom rajta, hiszem teljesen fölösleges az X alum Z-edik oldalát állandóan az adatbázisból kiszedni, amikor nagyon jól tudjuk, hogy mikor változik: ha képet töltönk föl, módosítunk, avagy törlünk. Ezek a kesselések sokkal többet jelentenek egy legalább 'normálisan' átgondolt rendszer esetében, mint az, hogy nyersz-e pár ezredmásodpercet egy okos ötlettel valamelyik rendszerfunkció esetében. Persze, ha a legjobb kódot írod meg mindenhol, akkor le a kalappal, sajnos és szerencsére én tudom, hogy sok helyen hol és mit lehetne javítani nálam. :)
Úgy vélem, a legfontosabb, hogy amilyen generált tartalmat csak lehet kesselj, minél kevesebb modult/modulrészletet tölts be automatikusan, és igyekezz úgy szervezni a kódot, hogy egy-egy futáskor a lehető legkevesebb fájlt húzd be. (bár alapvetően egy fájlban egy obkejtumot szokás tartani, én biza megszegetm azt az íratlan szabályt néhány helyen, ajánlatos nagyobb rendszereknél elgondolkodni ezen úgy vélem)
Természetesen akinek ötlete van/kérdése van, azt szívesen veszem.
ebben még nem használtam
Gondolkodtam az adodb-én, de inkább írtam sajátot. Nyilván ami csak mysql adatbázisra jó.
Nem érzem, hogy nagynak kellene lennie a dolognak ahhoz hogy fusson.
Annyit én is felismertem, hogy ez így nem stimmel:) Mert ugye nálam
egy osztály (control.php) tulajdonságaiként szerepel a többi osztály példányosított objektuma, s így ennek a control osztálynak egyetlen (main())
függvénye szolgál ki minden kérést. Ha ennek van haszna, az az, hogy összeszedve egy helyen történik a program vezérlése. Ami egyrészt jó, mert
áttekinthetőbb, mintha 5-10 külön fájlban történnének a kérések kiszolgálásai, másrészt aggasztó a main() függvény esetleges későbbi még nagyobb méretűre duzzadása. (ami már így is 650 sor). Igazából ennek a megoldása érdekelne valami tömb segítségével esetleg...vagy valahogy.
A rengeteg include-olást és spagettikódot továbbra is mellőzném ha lehet.
Hát igen a cache-elés is jó lenne, de azzal még hadilábon állok:)
Meg kacsintgatok az ajax felé is. Meg a rövid url is jó lenne.
fut != nagy
A futás nálam is úgy néz ki, hogy a legelső index.php-t hívja minden, kivétel persze azért akad.
Milyen gépen és mennyi idő alatt fut le a scripted egy kezdőoldalnál, illetve a legdurvább oldalnál? Leginkább az mondja meg, hogy mennyire írtad meg jól a kódot, nem az, hogy hány soros. Ha pl. jól kommentezel és sok trükkös megoldást használsz, aminek a működését célszerű is leírni, akkor a kód egy igen jelentős része lehet 'szemét' is, így az 'X soros' programkód nem értelmezhető mennyiség.
Én pl. a phpDoc-ot használom dokumentáció készítésére, így elég sok sorom dokumentációs komment... :D
Kérés: simi, megtennéd, hogy megírod az e-mailedet nekem?
Tudom:)
Hiszen én pont ezt a mondatot idéztem tőled:)
Tehát mégegyszer én sem gondolom, hogy ami nagy az jó.
Nálam ez egyszerűen a nem megfelelő tervezés eredménye. Hiszen sokkal
érthetőbb és átláthatóbb egy sok kisebb, viszonylag önálló modulból felépített program. Nálam az egyes osztályok feladata sem egyértelműen meghatározott sajnos. Pl. az adatbázis osztály (akkor jó ötletnek tűnt:)
több feladatot végez mint, kellene.
Abban teljesen igazad van, hogy a cache-elésnek sokkal nagyobb, szemmel láthatóbb "jótékony" hatása van a gyorsaságot illetően, mint a tized, ezred másodpercek nyerése a kód optimalizálása során. Persze az adatbázisműveletek
megint más lapra tartoznak. A lekérdezések optimalizálása, akár redundáns adattárolás is a hatékonyság növelése érdekében, limitálás stb.
Sajnos az én kódomban nem sok "szemét" van, de próbálok ezen változtatni jövőben. (megfelelő dokumentálás)
Az email címem:
simonzoltan kukac index pont hu
Kérdés
Egyéni döntés, azt hiszem, a legelterjedtebb a közös indulópont használata, mert az a legflexibilisebb.