ugrás a tartalomhoz

[OGF] Routing stratégia

janoszen · 2013. Okt. 20. (V), 21.53
Sziasztok!

Megint egy OGF-fel kapcsolatos kérdés, ezúttal a routing stratégia kapcsán.

Az alapvető koncepció az, hogy a kurrens regexp- és prefix match stratégiákkal ellentétben a rendszer által feltérképezett címek fastruktúrába rendeződjenek, tehát a / jelek mentén elválasztva és visszalépkedve mindig értelmes címeket kapjunk.

A megálmodott config fájlom így néz ki: link

Az egyes elemek osztályoknak felelnek meg, a mapping pedig a mellékelt elements.xml fájlban kerül leírásra.

Kérdés: hogyan valósítanátok meg egy ilyen relatíve szigorú routingot úgy, hogy a fejlesztőnek mégis triviális legyen routing szabályokat írni?

János
‹ Php funkció betöltése gombnyomásra hogyan? header(Location: változóval, és session változó átadása ›
 ■
1

Lehet, hogy sehogy

Pepita · 2013. Okt. 21. (H), 01.41
Már elég fáradt vagyok, úgyhogy változhat a véleményem, ez csak az első. (OGF-et nem ismerem, de a kérdéshez szerintem nem is kell.)

- Amit configban megvalósítasz, Apache esetén ezt szoktuk .htaccess-ben, Nginx esetén is van megfelelője, lehet valamilyen tudatlanságom okozza, hogy nem értem ezt miért is a fw-re hagyományozod. Vagy mi dolgozza fel? Én valószínű a kiszolgálóra bíznám, mielőtt a fw elindulna.
- Az elements.xml-ben pofonegyszerű megfeleltetést írni, itt viszont nincsen szabály, ha jól látom. Csak egy paraméter van, ami ha létezik, adott controller jön.

Azt hiszem nekem ez a szisztéma nagyon nem jelentene "triviális routing szabály írást". Nem látom át az értelmét. Ami nekem pl. triviális:
$route['default_controller'] = 'oldal';
$route['404_override'] = 'oldal/hibalap';
$route['oldal/(:any)'] = 'oldal/view/$1';
$route['hirdetes/(:any)'] = 'hirdetes/index/$1';
$route['nezet/(:any)'] = 'nezet/valt/$1';
$route['tagok/(:num)'] = 'tagok/adatlap/$1';
$route['forum/(:num)'] = 'forum/lista/$1';
$route['hirek/(:num)'] = 'hirek/lista/$1';
$route['kepek/(:num)'] = 'kepek/lista/$1';
És minden path-ként jön: kontroller/függvény/paraméter/paraméter2... alakban, ha nincs rá se szabály, se nem találta el pontosan a kontrollert és a fv-t, akkor jön a 404. Ez szerintem egy egyszerű és jól használható megoldás.

A másik amit nem értek: ha van az oldalon SSL, akkor miért nem mindig? Miért csak login esetén kötelező?

Az sem egészen tiszta, hogy miért pont így veszed kétfelé. A domaines dolgok .htaccess-be "valók", de az SSL is, a többi meg a példához hasonlóan, egy helyen, minimális szabályokkal - szerintem.
Ha jobban elmagyarázod a miértet, lehet, hogy egész más véleményen leszek...
2

OGF

janoszen · 2013. Okt. 21. (H), 10.49
Az OGF saját framework, most készül, szóval ahhoz nem is lehet nagyon érteni.

Ami az SSL-es, illetve hostname-s dolgot illeti, azért van a webapp configjában, mert én sokat dolgozom olyan projekteken, amik komplex szabályrendszerekkel rendelkeznek és ezeket kirakni webszerverre csökkentené az átláthatóságot. A bemutatott config természetesen csak sample config, azt demonstrálja, hogy mi mindent lehet vele megcsinálni.

Amiért nem szeretem a sima egyszerű route listát, az az, hogy sokan "abuzálják" az URL-eket mindenféle random dolgok tárolására és ezt szeretném picit visszaterelni a fastruktúra elvre. Ugyanez a routing építene a későbbiekben pl. breadcrumb trailt. (A létező legborzalmasabb routing megoldás amit valaha láttam a ZF1-ben volt egyébként.)
3

Hát használj olyasmit, ami

tgr · 2013. Okt. 21. (H), 10.55
Hát használj olyasmit, ami maga is fastruktúra (tömb, xml, könyvtárstruktúra).
4

Öröklődési hierarchia :)

Joó Ádám · 2013. Okt. 21. (H), 12.56
Öröklődési hierarchia :)
5

Kezicsokolom

janoszen · 2013. Okt. 21. (H), 13.46
Kezicsokolom, el teccett olvasni a postot? XML-ben van a config jelenleg is. Nem ez a kerdes. :)
6

Azt látom, hogy XML-ben van,

tgr · 2013. Okt. 21. (H), 13.50
Azt látom, hogy XML-ben van, azt nem látom, hogy az XML hierarchikus szerkezetét bármilyen módon kihasználná. (Max. a saját belső objektumhierarchiájának a leképezésére, amivel viszont a felhasználó az esetek 99%-ában nem akar foglalkozni; a path hierarchia leképezésére viszont nem.)
7

Pedig

janoszen · 2013. Okt. 21. (H), 13.55
Pedig a pathpart resz arra lenne hivatott, hogy tobb pathpartot egymas moge tegyen. De ha van jobb otleted hogy hogyan kellene ezt lekepezni, annak nagyon orulnek.
8

Ez a példából nemigen derül

tgr · 2013. Okt. 21. (H), 14.23
Ez a példából nemigen derül ki. Én amúgy nem feltétlenül erőltetném konfig szinten a hierarchikusságot, inkább paraméterezhető stringeket használnék (/users/view/(id:int)) és mellékelnék valami toolt, ami elemzi a konfigurációt és jelzi a potenciális problémákat, és az szólhatna, ha egy szülő útvonal nincs lekezelve. A fő problémának mindenesetre azt látom, hogy túl sokmindent próbálsz egy konfigfájlba bezsúfolni - az auth és redirekt szabályokat nem venném ide, azt csinálja a kontroller vagy a webszerver (utóbbi nehezebben áttekinthető, viszont hatékonyabb), vagy legyenek külön fájlban nevesített redir/auth szabályok, amiket csak behivatkozol a leafből. A séma is mehet az authhoz, és akkor a maradék már sokkal olvashatóbb lesz.
9

Kodkieg

janoszen · 2013. Okt. 21. (H), 14.29
Hogy lesz ehhez code completion? Mert az XML-hez van.
10

Mit lehet kódkiegészíteni

tgr · 2013. Okt. 21. (H), 15.25
Mit lehet kódkiegészíteni azon, hogy $routes['/users/view/(id:int)'] = 'UserController::viewAction';? Egyébként is, az XML kódkiegészítésnek szerintem nincs túl sok haszna, mert nem lehet dokumentációt csatolni a DTD-hez. Akkor már inkább egy fluid interfész:

$routes
    ->when()
            ->domainIs('janoszen.com')
        ->then()
            ->addGroup('require:www')
        ->end()
    ->when()
            ->domainIs('www.janoszen.com')
        ->then()
            ->when()
                    ->pathPrefix('login')
                ->then()
                    ->addGroup('require:https')
                    ->handle('Auth', 'login')
                ->end()
       ->end()
    ->end()
;
12

Nem rossz!

janoszen · 2013. Okt. 21. (H), 17.35
Ez igy nem is rossz! Ez tetszik!
13

Megnyugodtam :)

Pepita · 2013. Okt. 23. (Sze), 20.52
Az OGF saját framework, most készül, szóval ahhoz nem is lehet nagyon érteni.
Kezdtem azt hinni, hogy megint egy súlyos lik a tájékozottságomban. :) Azért remélem te értesz hozzá...

Hát, másképp gondolkodunk és / vagy mások az ügyfeleink-magunk igénye.

A fastruktúra irány jogos, de én mégis összehoznám valahogy a kettőt (szabályok és lista) egybe, nem is feltétlenül XML-ben. De mint mondtam - másképp gondolkodunk, és én egyelőre nem is gondolkodom saját fw írásán, inkább alakítgatom kedvemre a kedvencem.

Így sajnos nemigazán tudtam segíteni.
11

Nekem kicsit

inf · 2013. Okt. 21. (H), 15.27
Nekem kicsit túlbonyolítottnak tűnik a dolog.
Egy ilyet hogyan írnál le a config fájloddal: SLIM Route Groups ?

Végülis nagyjából mindegy szerintem, hogy mi van az xml-ben, ha csinálsz hozzá egy editort, amivel generáltatni lehet...

Tipikusan nem kézzel írt konfig fájl a legjobb megoldás erre, hanem annotációk használata, amik alapján lehet konfig fájlt generáltatni. Ha mégis kézzel szerkesztett konfig fájl mellett döntesz, akkor szerintem csináld a lehető legegyszerűbbre, legtömörebbre, pl nálam kb így néz ki egy config egy rest service darabhoz:

{
    "@url": "http://api.xxx.hu",
    "@namespace": "Resource",
    "/session": {
        "/": "SessionSet",
        "/current": "CurrentSession"
    },
    "/user": {
        "/": "UserSet",
        "/@id": {
            "/": "User",
            "/authentication-factor": {
                "@namespace": "Authentication",
                "/": "FactorSet",
                "/@id": "Factor"
            }
        }
    },
    "/authorization": {
        "@namespace": "Authorization",
        "/role": {
            "/": "RoleSet",
            "/@id": "Role"
        },
        "/policy": {
            "/": "PolicySet",
            "/@id": "Policy"
        },
        "/user-role": {
            "/": "UserRoleSet",
            "/@id": "UserRole"
        },
        "/user-policy": {
            "/": "UserPolicySet",
            "/@id": "UserPolicy"
        },
        "/role-policy": {
            "/": "RolePolicySet",
            "/@id": "RolePolicy"
        }
    },
    "/email": "EmailSet"
}
Valószínűleg config fájl helyett a fentebb linkelt route groups, amit használni fogok, mert ott nem kell string-ben osztályneveket megadnom... A controller példányosítást valszeg closure típusú paraméterekkel fogom csináltatni. Előtte tesztelni fogom, hogy az autoload pontosan mikor próbálja betölteni a Controller osztályt...

A config fájlba kiemelést nem tartom szerencsés dolognak, akkor látom értelmét, ha valamilyen alkalmazással akarom generáltatni a config fájlt.