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:
  1. $route['default_controller'] = 'oldal';  
  2. $route['404_override'] = 'oldal/hibalap';  
  3. $route['oldal/(:any)'] = 'oldal/view/$1';  
  4. $route['hirdetes/(:any)'] = 'hirdetes/index/$1';  
  5. $route['nezet/(:any)'] = 'nezet/valt/$1';  
  6. $route['tagok/(:num)'] = 'tagok/adatlap/$1';  
  7. $route['forum/(:num)'] = 'forum/lista/$1';  
  8. $route['hirek/(:num)'] = 'hirek/lista/$1';  
  9. $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:
  1. $routes  
  2.     ->when()  
  3.             ->domainIs('janoszen.com')  
  4.         ->then()  
  5.             ->addGroup('require:www')  
  6.         ->end()  
  7.     ->when()  
  8.             ->domainIs('www.janoszen.com')  
  9.         ->then()  
  10.             ->when()  
  11.                     ->pathPrefix('login')  
  12.                 ->then()  
  13.                     ->addGroup('require:https')  
  14.                     ->handle('Auth', 'login')  
  15.                 ->end()  
  16.        ->end()  
  17.     ->end()  
  18. ;               
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:
  1. {  
  2.     "@url": "http://api.xxx.hu",  
  3.     "@namespace": "Resource",  
  4.     "/session": {  
  5.         "/": "SessionSet",  
  6.         "/current": "CurrentSession"  
  7.     },  
  8.     "/user": {  
  9.         "/": "UserSet",  
  10.         "/@id": {  
  11.             "/": "User",  
  12.             "/authentication-factor": {  
  13.                 "@namespace": "Authentication",  
  14.                 "/": "FactorSet",  
  15.                 "/@id": "Factor"  
  16.             }  
  17.         }  
  18.     },  
  19.     "/authorization": {  
  20.         "@namespace": "Authorization",  
  21.         "/role": {  
  22.             "/": "RoleSet",  
  23.             "/@id": "Role"  
  24.         },  
  25.         "/policy": {  
  26.             "/": "PolicySet",  
  27.             "/@id": "Policy"  
  28.         },  
  29.         "/user-role": {  
  30.             "/": "UserRoleSet",  
  31.             "/@id": "UserRole"  
  32.         },  
  33.         "/user-policy": {  
  34.             "/": "UserPolicySet",  
  35.             "/@id": "UserPolicy"  
  36.         },  
  37.         "/role-policy": {  
  38.             "/": "RolePolicySet",  
  39.             "/@id": "RolePolicy"  
  40.         }  
  41.     },  
  42.     "/email": "EmailSet"  
  43. }  
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.