Routing principe
Kan iemand mij helpen of uitleggen hoe het Routing principe werkt? Ik ben namelijk met een framework bezig voor mezelf in OOP en ben nu toe gekomen aan de Routing om de goede controller te krijgen en dergelijke. Ik heb wat zitten kijken hoe andere frameworks dat doen zoals Zend en Symfony.
Ik zie veel Routing classes gebruik maken van routing configs die er bijvoorbeeld zo uit zien:
Route.json
Maar al mijn controllers staan in een database (ivm menu volgorde, subpagina's etc)en ik wil de url veranderen van 'authorization' moet ik dan elke keer de Route.json veranderen? Bij een CMS zou dat niet echt erg zijn want daar veranderen de pagina's/controller urls niet.
BV iemand wil zijn website wat veranderen en wil de pagina 'over-ons' veranderen naar 'over-php-hulp', dan moet hij dit doen in het CMS en niet in Route.json.
Dus kan iemand mij vertellen hoe ik dit kan aanpakken en toch alles zo dynamisch mogelijk kan houden?
Ik zie veel Routing classes gebruik maken van routing configs die er bijvoorbeeld zo uit zien:
Route.json
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"dashboard" : "dashboard",
"users" : "/users",
"users_add" : "/users/add",
"users_edit" : "/users/edit/{:id}",
"users_delete" : "/users/delete/{:id}",
"users_show" : "/users/show/{:id}",
"sessions" : "/sessions",
"sessions_delete" : "/sessions/delete/{:id}",
"sessions_show" : "/sessions/show/{:id}",
"authorization" : "/authorization",
"authorization_add" : "/authorization/add",
"authorization_edit" : "/authorization/edit/{:id}",
"authorization_delete" : "/authorization/delete/{:id}",
"authorization_show" : "/authorization/show/{:id}",
"flush" : "/flush",
"flush_proceed" : "/flush/proceed"
}
"dashboard" : "dashboard",
"users" : "/users",
"users_add" : "/users/add",
"users_edit" : "/users/edit/{:id}",
"users_delete" : "/users/delete/{:id}",
"users_show" : "/users/show/{:id}",
"sessions" : "/sessions",
"sessions_delete" : "/sessions/delete/{:id}",
"sessions_show" : "/sessions/show/{:id}",
"authorization" : "/authorization",
"authorization_add" : "/authorization/add",
"authorization_edit" : "/authorization/edit/{:id}",
"authorization_delete" : "/authorization/delete/{:id}",
"authorization_show" : "/authorization/show/{:id}",
"flush" : "/flush",
"flush_proceed" : "/flush/proceed"
}
Maar al mijn controllers staan in een database (ivm menu volgorde, subpagina's etc)en ik wil de url veranderen van 'authorization' moet ik dan elke keer de Route.json veranderen? Bij een CMS zou dat niet echt erg zijn want daar veranderen de pagina's/controller urls niet.
BV iemand wil zijn website wat veranderen en wil de pagina 'over-ons' veranderen naar 'over-php-hulp', dan moet hij dit doen in het CMS en niet in Route.json.
Dus kan iemand mij vertellen hoe ik dit kan aanpakken en toch alles zo dynamisch mogelijk kan houden?
Dit hoort absoluut niet in een database te staan en je denkt veel te moeilijk. waarom zou je niet gewoon een dynamische {:page} kunnen hebben voor een pagina?
Waarom hoort dit niet in een database te staan dan? Ik heb bv een tabel met alle 'controllers' van het CMS/Framework (elke row is een controller) bv:
Aan de hand van deze tabel met 'controllers' kan ik het menu samen stellen en bijvoorbeeld controllers deactiveren voor als ze bij een CMS niet van toepassing zijn zonder de mappen met source code van de FTP te verwijderen.
Code (php)
1
2
3
4
5
2
3
4
5
id parent_id name status
1 0 Dashboard 1
2 0 Security 1
3 2 Users 1
4 2 Authorization 0
1 0 Dashboard 1
2 0 Security 1
3 2 Users 1
4 2 Authorization 0
Aan de hand van deze tabel met 'controllers' kan ik het menu samen stellen en bijvoorbeeld controllers deactiveren voor als ze bij een CMS niet van toepassing zijn zonder de mappen met source code van de FTP te verwijderen.
Je JSON-voorbeeld gebruikt het patroon host/class/method/var/var/var/{etc.}. Daarin speelt /class/ voor bijvoorbeeld /authorization/ en /users/ dus de eerste viool. De CMS-router heeft daarin maar twee functies: via de database controleren of /class/ voor een bepaalde host is ingeschakeld en, zo ja, een eventuele alias en variabelen in het pad afhandelen.
Je router-class ontleent zijn bestaansrecht aan het wel of niet beschikbaar zijn van andere classes. Die classes bepalen op hun beurt echter welke vereiste en optionele input ze van de router verwachten. Met andere woorden: je hebt geen onafhankelijke classes, maar wel een model dat kan stranden in een spelletje touwtrekken rondom wie nu precies de baas is.
Misschien kun je het elegant oplossen door 'dashboard' of 'security' de baas over alles te maken. Daarmee regel je dan niet alleen de toegang tot host/class/, maar als je het nodig hebt ook die tot host/class/method/, zodat je in het CMS uitgebreider bepaalde functionaliteit kunt in- en uitschakelen.
Je router-class ontleent zijn bestaansrecht aan het wel of niet beschikbaar zijn van andere classes. Die classes bepalen op hun beurt echter welke vereiste en optionele input ze van de router verwachten. Met andere woorden: je hebt geen onafhankelijke classes, maar wel een model dat kan stranden in een spelletje touwtrekken rondom wie nu precies de baas is.
Misschien kun je het elegant oplossen door 'dashboard' of 'security' de baas over alles te maken. Daarmee regel je dan niet alleen de toegang tot host/class/, maar als je het nodig hebt ook die tot host/class/method/, zodat je in het CMS uitgebreider bepaalde functionaliteit kunt in- en uitschakelen.




