Routing és paraméterezés
Sziasztok,
Nemrég akadt egy kis szabad időm, és belekezdtem egy régóta halasztgatott hobbi-projectbe: Én is szeretnék saját cms-t, mert miért ne. :)
Viccen kívül, "gyakorlásnak" tökéletes, már ígyis csináltam olyat, amire eddig nem volt igény. Pedig még csak az elején vagyok.
Tehát saját CMS, ehhez persze szükségesek az alapok, ahol jelenleg a routing megvalósításánál járok.
Nagyon leegyszerűsítve az lenne a lényege, hogy egy tömbben lehetne tárolni az olyan url-eket és akciókat, amik nem adatbázis függők.
Tehát ha a tömb:
akkor az xx.hu/admin/pages url-re az \Admin\Controllers\AdminPages controller index metódusa hívódna meg. Működik is.
A paraméterezéssel akadt gondom: tegyük fel, hogy az admin/pages/5 -> 5 azonosíójú oldalt kéne betölteni az admin felületen szerkesztésre.
De erre már egy egyszerű isset nem elég, hiszen a /5 miatt nem fog egyezni.
Get paraméterezést pedig ha lehet nem szeretnék használni, mert ez ugye nem csak admin felületen jöhetne szóba.
Pl xx.hu/kereses/keresett-szoveg/oldalszam esetén a \Search\Controllers\List controller getResults metódusa hívódjon meg.
A keresett szöveg és oldalszám átadása nem lényeg, azt már később ki tudom bányászni az url-ből. Viszont olyat hogyan lehetne, hogy a routing tömbben ez
Megoldottam, méghozzá egy /* -al
És ha valamelyik elem esetén a feltétel true, akkor továbbadni a vezérlést.
Habár tökéletesen működik, véleményem szerint ez egy több száz elemű tömbnél nem biztos, hogy túl jó ötlet, string műveletek nem az "olcsóságukról" híresek.
Tehát kérdésem az lenne, hogy milyen jó megoldásokat ismertek/használtok erre?
Köszönöm előre is a válaszokat
■ Nemrég akadt egy kis szabad időm, és belekezdtem egy régóta halasztgatott hobbi-projectbe: Én is szeretnék saját cms-t, mert miért ne. :)
Viccen kívül, "gyakorlásnak" tökéletes, már ígyis csináltam olyat, amire eddig nem volt igény. Pedig még csak az elején vagyok.
Tehát saját CMS, ehhez persze szükségesek az alapok, ahol jelenleg a routing megvalósításánál járok.
Nagyon leegyszerűsítve az lenne a lényege, hogy egy tömbben lehetne tárolni az olyan url-eket és akciókat, amik nem adatbázis függők.
Tehát ha a tömb:
['admin/pages' => 'Admin.AdminPages.index'] akkor az xx.hu/admin/pages url-re az \Admin\Controllers\AdminPages controller index metódusa hívódna meg. Működik is.
A paraméterezéssel akadt gondom: tegyük fel, hogy az admin/pages/5 -> 5 azonosíójú oldalt kéne betölteni az admin felületen szerkesztésre.
De erre már egy egyszerű isset nem elég, hiszen a /5 miatt nem fog egyezni.
Get paraméterezést pedig ha lehet nem szeretnék használni, mert ez ugye nem csak admin felületen jöhetne szóba.
Pl xx.hu/kereses/keresett-szoveg/oldalszam esetén a \Search\Controllers\List controller getResults metódusa hívódjon meg.
A keresett szöveg és oldalszám átadása nem lényeg, azt már később ki tudom bányászni az url-ből. Viszont olyat hogyan lehetne, hogy a routing tömbben ez
['kereses' => 'Search.List.getResults'] -ként lehessen tárolva.Megoldottam, méghozzá egy /* -al
['kereses/*' => 'Search.List.getResults'], de akkor be kéne járni a tömb összes elemét és megvizsgálni, hogy ($url az url, a $index az éppen aktuális kulcs esetén)$position = strpos($index, '/*');
if ($postition !== false) {
$match = (
substr($url, 0, $position) === substr($index, 0, $position) &&
( isset($url[$position]) ? $url[$position] === '/' : true ) // Tehát ha az url-ben van a /* helyén valami, akkor csak / lehessen, így nem ad találatot pl a keresesem-re
);
} else {
$match = $url === $index;
}
if ($match) {
...
}
if ($postition !== false) {
$match = (
substr($url, 0, $position) === substr($index, 0, $position) &&
( isset($url[$position]) ? $url[$position] === '/' : true ) // Tehát ha az url-ben van a /* helyén valami, akkor csak / lehessen, így nem ad találatot pl a keresesem-re
);
} else {
$match = $url === $index;
}
if ($match) {
...
}
És ha valamelyik elem esetén a feltétel true, akkor továbbadni a vezérlést.
Habár tökéletesen működik, véleményem szerint ez egy több száz elemű tömbnél nem biztos, hogy túl jó ötlet, string műveletek nem az "olcsóságukról" híresek.
Tehát kérdésem az lenne, hogy milyen jó megoldásokat ismertek/használtok erre?
Köszönöm előre is a válaszokat
cak egy kerdes
Ami mondjuk megoldja a routingot.
Ha nem akarsz, akkor sztem nezd at hogy a CodeIgniter hogy csinalja. Egyszeru es jo megoldas.
Megnézem
Bevallom codeIgniterrel már volt dolgom, de nagyon-nagyon régen.
Mindenképp sajátot szeretnék mindenből, mert ez egy hobbiprojekt.
A cél nem egy egyedi cms felépítése és világuralom, hanem a látókör szélesítése :)
Alap problémákkal fogok találkozni, aminek a megoldásai még nagyon jól jöhetnek a jövőben.
Akár egy világmegváltó cms létrehozásában is :)
Nem zárja ki egymást
Egyébként szerintem kár feltalálni a kereket, ha vannak jó fw-ök, minek írsz sajátot? A CI szükség szerint könnyen alakítható.
Mondanám, hogy ugyanez igaz a CMS-re is, de nem mondom, mert ott már jobban lehetnek egyedi igények.
Megnézem
Egyébként azért saját, hogy találkozzak "alacsony szintű" problémákkal.
Hirtelen a CodeIgniterből annyira emlékszek, hogy controllerneve/metódusneve/paraméter stílusú linkeket lehet használni.
Na ezt szeretném én még megtoldani a namespace-ekkel, ezért gondoltam a fenti szerkezetre.
Laravellel barátkoztam nemrég. Használni fun, de a forrásától kicsit rosszul lettem :)
Meg alapból idegen a composer is , akármennyire hasznos, még azt is emésztenem kell.
Több lehetőség van
Le tudod kérdezni darabonként az érkező paramétereket, aztán úgy használod, ahogy akarod.
$this->uri->segment(3), $this->uri->segment(4)Ha nincs az adott segmens, false-ot ad vissza.
Szerk.:
Példa: Calendar class
Ez tetszik
De nekem ugye a probléma az első 2 szegmens lesz, hiszen nekem kell valahogy a namespace szerkezet is.
Egy a cms-ben szerkesztető oldal controller elérési útja kb:
\Components\Admin\Controllers\AdminPages
De egy bejelentkezett felhasználó:
\Components\Admin\Models\AdminUser ami extendeli a \Components\User\Models\User-t
Nagyjából ilyen szerkezetet szeretnék kialakítani.
Aztán később a Components mellett lehet akár Cron, vagy ami majd még kell :)
cron?
Vagy cron tabbal url-t akarsz megnyitni?
Ezt csak akkor tedd, ha mindegy milyen surun fut.
Ok, ez tényleg hülye példa volt
Mondjuk Components helyett External-al kezdődne ami valamilyen integrációs feladathoz kapcsolódik.
Utólag belegondolva
Egy jelenleg is használt megoldást továbbgondolva:
\Cron\Social\Models\SocialConnections
Ezt a modelt egy cron arra használhatná, hogy óránként lekérje a különböző social oldalakon a like-ok, megosztások számát (ne kelljen minden oldalbetöltésnél lekérni közvetlenül tőlük).
Bár nyilván ez sem teljesen jó példa, hiszen a site-on is kellhet egy hasonló model (csak az már db-ből/cache-ből olvasná), aztán miért ne pakolhatnám egybe: social dolgok a \Components\Social-ban.
De remélem a lényegét az elképzelésemnek át tudtam adni.
Ha ilyenbe fogsz, akkor első
Elsőre kettő külön egységed lesz: a framework és a cms.
Itt meg is érkeztünk a problémád egyik megoldásához, s az kapcsolódik Pepita javaslatához.
Használj első körben egy már meglévő framework-öt.
Ha azt később megismered és jól tervezed meg a cms-t, akkor bármikor lecserélheted másikra. Akár sajátra is.
De ha úgy döntesz, hogy egyből framework-öt is írsz, akkor ez is lehet egy megoldás. A
'kereses/*'helyett használj regexp-et:'~kereses/?.*~i'.Szintek :)
A következő lépés egyébként egy jogosultságos admin rendszer lesz.
Majd ha később szükségem lesz valamire, kiegészítem a "frameworkot".
Melóban mivel több éve megy az oldal ez már pöpecre ki van építve, így nekünk magasabb szintű problémákat kell megoldani.
A preg_match gyorsabb lehet a substr-eknél? Ennek utánanézek.
Köszönöm
Micro optimazations
Nagyon irreleváns és rossz irányba viszi el a projektet. Használd azt, amivel könnyebb, jobb dolgozni.
Értem
Akkor marad a substr, mert ez már készen van.
Majd ha ismét lesz időm játszani lecserélem, és meglátjuk mennyire olvasható :)
Meg hát van egy sejtésem, hogy fogom még én ezt a részt piszkálni az időközben felmerülő igények miatt :)