Router ohne mapping

[Fuel]

Ich mag den Router von Laravel. Der ist sehr unkompliziert zu handhaben. Da sieht eine Route zB so aus.

Route::get('/home', 'HomeController@showHome');

//oder
Route::any('{all}', function() {
if (!Auth::check())
    Redirect::to('/login');
}); 

Natürlich hätte ich gerne meinen eigenen Router gemacht, aber wenn ich mir andere Router angucke verstehe ich leider nur die Hälfte. Warum zB wandelt ihr die Route aus der URL so kompliziert um? Gerade wenn ich mir die Funktion compileRoute ansehe bei rkr.

[tr0y]

Ich halte das Router-Proposal von jack88 für überladen.

Deine Environment-Daten sind Daten die ein Router nicht brauch, die Restriction-Daten gehören auch nicht zu den Daten die der Router unbedingt wissen muss, das sie auf die Route selbst keinen einfluss haben sollen.

Ob eine bestimmte Restriktion einer Route zu Teil werden sollte ( abgesehen von der Request-Methode ) sollte nicht Teil des Route-Hubs sein, das ist Sache des Security-Hubs. Ich würde 3 Daten in der Route speichern: Pfad, Name der Route und die Request-Methode(n) der Route. Aus assoziativer Sicht könnte man durchaus noch hingehen und ein Callback ( keinen abstrakten String ) in der Route speichern die nach Ausführung das Response zurück gibt.

Dein Router könnte außerdem noch before und after callbacks festhalten die zur Route gehören, ich tendiere aber eher dazu dass sowas durchaus in einen eigenen Container gehört ( Pre-/Post-Processing Container, mit jeweils einer pre- und eine post-Queue ), deine Security-Geschichten ebenso in einen eigenen Container.

Benötigt man einmal nicht den Security-Hub, ist nur der Router zur Abhandlung des Routings nötig. Um das ganze zu synchronisieren würde ich den Router im Framework selbst als ein Router-Gateway implementieren das ein Facade umsetzt und 2 bzw. 3 Interfaces ( Routing, Security [, Processing] ) zu einem Interface vereinigt ( das dann das selbe Interface generell implementiert das der Router selbst besitzt ).

Sowas derart setzt im übrigen Symfony so um und hat das auch so komponentisiert ( Security, Routing => Firewall, Router | Route ). Schlussendlich auch Laravel.

Als elementar empfehlenswerter Router hat mich Nikita Popov's ( einer der PHP Constributor ) FastRoute für PHP bisher sehr angesprochen, meine eigenen Router-Implementierungen orientieren sich stark an dessen Prinzip / Algorithmen.

FastRoute ist dort zu finden: https://github.com/nikic/FastRoute

[rkr]

@jack88: Da gebe ich tr0y recht. Die Zuständigkeit vom Router habe ich in meiner README.md festgehalten. TL;DR: Der Router ist ein Key-Value-Array mit einer (später noch konfigurierbaren) Lookup-Methode, die zu einer Anfrage (REQUEST_URI) das passende Muster findet und dessen Value-Part samt Key zurückgibt.

Diese Komponente kann von einer anderen Komponente gekapselt werden, die den Weg genau anders herum geht, um aus vorhandenen Daten die passende Url zu bauen. Denn: Wenn ich der Applikation erlaube, den Value-Part frei zu bestimmen, dann muss die Applikation sich auch selbst drum kümmern, ein für ihre Zwecke passendes Muster zu finden. Meine Url-Builder gehen nie(!) nach dem Muster (also dem Key-Part), sondern immer nach bestimmten Daten im Value-Part. Ich will eine Url anpassen können, ohne den Namen eines Action-Controllers ebenfalls anpassen zu müssen, sonst bekomme ich beim CodeReuse Probleme. Eleganter finde ich: Suche mit die passende Route mit der ich den ActionController X und die Methode Y aufrufe und das Ergebnis als Json zurückgebe. Gibt es diese Route nicht: Exception. Kann man prima cachen.

@fuel: Ich muss ja zu einer Anfrage (z.B. /user/10) das passende Muster suchen, dass dann erklärt, was nun passieren soll.

[jack88]

Ich halte das Router-Proposal von jack88 für überladen.

Man kann es natürlich unterschiedlich sehen.

Ob eine bestimmte Restriktion einer Route zu Teil werden sollte ( abgesehen von der Request-Methode ) sollte nicht Teil des Route-Hubs sein,

Der Router hat die Aufgabe für einen Request die richtige Route zu finden. Er hat auch hier keinerlei Security-Funktion, auch wenn das vielleicht auf den ersten Blick so aussehen könnte bzw. möglicherweise der Begriff „Restriction“ fälchlicherweise den Eindruck vermittelt. envPattern und paramPattern wären vielleicht etwas treffender.

Aus Sicht der Applikation kann es sich bei den folgenden URLs durchaus um zwei verschiedene Routen handeln:

http://store.example.com/978-3897214422
http://store.example.com/5097

die eine URL zeigt ein Buch anhand einer ISBN-ID, die andere anhand einer internen ID. Die Verarbeitung des Parameters ID ist also komplett anders und sollte jeweils von einer darauf spezialisierten Komponente vorgenommen werden. Dafür muss es zwei Routen geben die sich durch eine entsprechendes ParameterPattern für den Parameter ID unterscheiden.

$router->add(Route::create('/:id', array('controller' => 'Book\\Isbn'), array(), array('id' => '(978|979)[ |-][0-9]{1,5}[ |-][0-9]{1,7}[ |-][0-9]{1,7}[0-9]{1}')));
$router->add(Route::create('/:id', array('controller' => 'Book\\Id', ), array(), array('id' => '[\d]+'))); 

Ohne einen entsprechenden Parameter check lassen sich solche URLs nicht routen.

Aus meiner Sicht ist das eine Routing-Entscheidungen die auch nicht in einen Controller gehört.

Auch hier KANN es sich durchaus um zwei verschiedene Routen handeln

http://www.example.com
https://www.example.com

wenn man z.B. auf unverschlüsselten Seiten aus Sicherheitsgründen bestimmte Inhalte nicht veröffentlichen möchte.

Letztendlich wird das Routing vom Entwickler festgelegt und wenn dieser den Wunsch hat, dass eine https Verbindung anders verarbeitet werden soll, oder dass für einen Request von Firefox ein andere Controller zuständig sein soll als von Chrome, dann ist das seine Entscheidung für die er auch seine Gründe haben wird.

rkr
Da gebe ich tr0y recht. Die Zuständigkeit vom Router habe ich in meiner README.md festgehalten. TL;DR: Der Router ist ein Key-Value-Array mit einer (später noch konfigurierbaren) Lookup-Methode

Wie würdest Du das erste Beispiel (ISBN/Id) mit Deinem Router abbilden, oder ist es für Dich keine Routing-Entscheidung?

vg
jack

[rkr]

Aktuell kann mein Router noch keine RegExp-Muster pro Path-Part. Sobald er das kann, kann er die von dir dargestellten Muster unterscheiden.
Das hat dann im Endeffekt zur Folge, dass ein anderes Muster durch das Lookup anspringt und der dazu gehörenden Value-Part eine andere Action triggert.

Du kannst die Validierung ohnehin nicht einem regulären Ausdruck überlassen. Was ist, wenn es die ISBN nicht gibt? Bzw, wenn die Prüfziffer falsch ist? Kannst du das denn unterscheiden? Dein (favorisierter) Algorithmus kann bislang nur Muster unterscheiden.

[Fuel]

Aktuell kann mein Router noch keine RegExp-Muster pro Path-Part. Sobald er das kann, kann er die von dir dargestellten Muster unterscheiden.
Das hat dann im Endeffekt zur Folge, dass ein anderes Muster durch das Lookup anspringt und der dazu gehörenden Value-Part eine andere Action triggert.

Du kannst die Validierung ohnehin nicht einem regulären Ausdruck überlassen. Was ist, wenn es die ISBN nicht gibt? Bzw, wenn die Prüfziffer falsch ist? Kannst du das denn unterscheiden? Dein (favorisierter) Algorithmus kann bislang nur Muster unterscheiden.

Wenn es die ISBN nicht gibt, ist es nicht die Aufgabe des Controllers, dass festzustellen?

[rkr]

Wenn es die ISBN nicht gibt, ist es nicht die Aufgabe des Controllers, dass festzustellen?

Ja, das habe ich damit implizit gemeint. Und der Controller stellt so etwas dann eigentlich auch nicht fest, sondern trifft die Entscheidung was passieren soll, wenn der ISBN-Code falsch ist.

[jack88]

Du kannst die Validierung ohnehin nicht einem regulären Ausdruck überlassen. Was ist, wenn es die ISBN nicht gibt? Bzw, wenn die Prüfziffer falsch ist? Kannst du das denn unterscheiden? Dein (favorisierter) Algorithmus kann bislang nur Muster unterscheiden.

Es ist keine Validierung, es ist nur ein Muster für eine Routing-Entscheidung. Ich sage damit dem Router nur: hey schick einfach alles was diesem Muster entspricht an diesen oder jenen Controller.

Wenn es die ISBN nicht gibt, ist es nicht die Aufgabe des Controllers, dass festzustellen?

Oder vielleicht auch des Models...., aber ganz sicher nicht des Routers. Macht er aber auch nicht – er findet nur die hoffentlich richtige Route.

Ein Router ist im Grunde genommen nichts anderes als ein Paketzusteller und sein Päckchen (Request). Normalerweise sind die Routen (Adressen), ja auch ganz simpel, aber manchmal bedarf es auch weiterer Zusatzinformationen (Environment) (im Hinterhof, zweite Klingel von oben, erst ab 14:00 Uhr etc.) damit das Päckchen direkt den richtigen Empfänger erreichen kann.


Vg
jack

[Fuel]

Es ist keine Validierung, es ist nur ein Muster für eine Routing-Entscheidung. Ich sage damit dem Router nur: hey schick einfach alles was diesem Muster entspricht an diesen oder jenen Controller.


Oder vielleicht auch des Models...., aber ganz sicher nicht des Routers. Macht er aber auch nicht – er findet nur die hoffentlich richtige Route.

Vg
jack

Hab ich das MVC Pattern noch nicht verstanden!? Ich dachte das Model holt nur die Daten und legt fest was mit den Daten geschieht. Die Entscheidung müsste doch der Controller festlegen ob es die ISBN Nummer nicht gibt, da er es ja dann mit einem Response zurückgeben muss.

[alxy]

Und wie soll der Controller das rausfinden ohne mal Model::findById($id) aufgerufen zu haben? (Man könnte wahrscheinlich diskutieren, ob nicht das ModelRepository dafür zuständig wäre. )

[tr0y]

http://store.example.com/978-3897214422
http://store.example.com/5097

$router->add(Route::create('/:id', array('controller' => 'Book\\Isbn'), array(), array('id' => '(978|979)[ |-][0-9]{1,5}[ |-][0-9]{1,7}[ |-][0-9]{1,7}[0-9]{1}')));
$router->add(Route::create('/:id', array('controller' => 'Book\\Id', ), array(), array('id' => '[\d]+'))); 

[/CODE]

Wie würdest Du das erste Beispiel (ISBN/Id) mit Deinem Router abbilden, oder ist es für Dich keine Routing-Entscheidung?

$router = new RouterGateway();
$router->register('GET', '/{id:[0-9]+}', 'book::id');

# entweder
$router->register('GET', '/{isbn:(978|979)[ |-][0-9]{1,5}[ |-][0-9]{1,7}[ |-][0-9]{1,7}[0-9]{1}}', 'book::isbn');

# oder
$router->attachRoutePropertyHandler($services->make('routing:isbn-identifier'));
$router->register('GET', '/{isbn:[[ISBN]]}', 'book::isbn');

$router->firewall($router::ANY, ['secure' => true]);

$route = $router->query($requestObject); 

[rkr]

Ich finde es mindestens diskissionswürdig via Eventhandler Aspekte an Objekte zu klemmen, die man besser durch Kapselung darstellen kann: "Spezialisierter Router nutzt allgemein gehaltenen Router um domänenspezifische Routingdetails abzubilden". Das ist leicht nachvollziehbar, da man die Zuständigkeit in der späteren Applikation klar erkennen kann.

Bei deinem Ansatz fehlt mir das.

[tr0y]

Ich finde es mindestens diskissionswürdig via Eventhandler Aspekte an Objekte zu klemmen, die man besser durch Kapselung darstellen kann: "Spezialisierter Router nutzt allgemein gehaltenen Router um domänenspezifische Routingdetails abzubilden". Das ist leicht nachvollziehbar, da man die Zuständigkeit in der späteren Applikation klar erkennen kann.

Bei deinem Ansatz fehlt mir das.

Event-was ?

[rkr]

Was genau soll die Aufgabe von deinem attachRoutePropertyHandler sein?

[Gast]

//OT:
mal abgesehen von dem theoretischen zu lösendem problem, halte ich es für sonderbar:

http://store.example.com/978-3897214422
http://store.example.com/5097

in irgendeiner weise als isbn oder id auszuwerten, mir kommt das beispiel konstruiert vor.
kann oder will mich da jemand vom gegenteil überzeugen?