Stop matching routes after first match?

[ePirat]

Maybe I am getting it wrong but I thought after a route matches and callback is executed, klein should not try to match any other routes…
But I've just tried it out:

// Backend (Admin panel)

$klein->respond('GET', '/admin/?', function ($request, $response, $service) {
    return 'Hello Admin!';
});

// Main Views

$klein->respond('GET', '/[:fuubar]/?', function ($request, $response, $service) {
    return 'Hello Fuubar!';
});

This code creates: Hello Admin!Hello Fuubar!, is this intended?

[ePirat]

Even adding a exit(); after return 'Hello Admin!'; doesn't change anything… How can I prevent this behavior?

Edit: Of course adding it after a return would not have any effect m(
Did it like that now:

$klein->respond('GET', '/admin/?', function ($request, $response, $service) {
    echo 'Hello Admin!';
    exit();
});

Is this the recommended way to do it?

[Rican7]

@ePirat This is actually the intended behavior of Klein. Klein uses route multi-matching to make it easier to create filters based on URI's, instead of having to create a new interface for doing so.

However, I do understand the confusion. You, amongst others, have been confused by this behavior as they only see it when they have similar route matches with variables, and so its come to my attention that it may be a good idea to modify this behavior somewhat. I'll keep you updated if I do so.

[ePirat]

Actually this behavior is pretty cool, but it would definitively help to mention it somewhere in the readme or provide an example that illustrates this behavior. Especially because most routers handle it like that on first matching route it will stop to match.

[Rican7]

Haha, yea, I'm glad you like it @ePirat. It would be nice to have it documented somewhere. The documentation for this project is decent, but its documenting of its growing feature list and behaviors could definitely use an update. :P

[ePirat]

Well some things are not documented at all it seems, for example reverse routing. Of course you can look at the API ref. but without knowing what exactly to look for it is hard to find out how it works. (I did not even knew that klein.php can do reverse routing and was already about choosing another framework)

[Rican7]

:/
Sorry, this project is really only maintained by me now (@chriso no longer works on it actively), and I only do it in my spare, personal time. There's only so much I can do.
I'd LOVE to take a pull request with added documentation if you'd so like, though. Or even just a WIKI entry.

[ePirat]

Ok if I have some time I will write some Wiki entries. btw what is the recommended way to terminate matching futher routes? Can I safely do exit(); or is there a better alternative to skip all next routes?

[Rican7]

It depends. If you're using the current master, then there's a method for it:
https://github.com/chriso/klein.php/blob/e5ca4e2729250ff04b3acad03ea388d0416ec872/src/Klein/Klein.php#L911

[CMCDragonkai]

I've used previous routing libraries and they terminate upon the first match. I relied on this functionality in order to implement a catch all route when no routes are matched. What's the best way for Klein to implement a "catch all" route? So if no routes match, it goes to Home. @Rican7

[Rican7]

@CMCDragonkai see my comment in #166.

[eimajenthat]

@Rican7 Working on adding some docs. I wanted to document this, but I'm unclear about the relative merits of $klein->skipRemaining() vs. $response->send(). It seems like they will both accomplish the same end result here, but perhaps through different techniques? Looks like $response->send() still allows the other matched routes to run, they simply can't modify the response, since it's locked? I guess it's possible to unlock it, so you could get different results that way. Other than that, it looks like a question of wasted CPU cycles?

Here's the doc I'm working on: https://github.com/eimajenthat/klein.php/blob/master/manual/Routing.md#matching-multiple-routes

[eimajenthat]

So, I had a case where a route needed to override any other routes (this route matches my legacy URLs, and doesn't need any fancy new stuff modifying it). I discovered a path that was matching this route and then matching another I didn't want it to. So I added a $klein->skipRemaining() to the route I wanted it to match (the first one), and I end up with a 404 error. Seems like $klein->skipRemainining() is also skipping the route in which it is called or something?

@eimajenthat smoking crack again, or is this a bug?

[Rican7]

@eimajenthat A few of things:

1. I am actually working on a way to allow for running Klein with a behavior that calls only one matched route. Its taking me some time to implement it well, but yea, its happening.
2. Klein::skipRemaining() and AbstractResponse::send() are very different beasts. Klein::skipRemaining() simply skips the remaining routes from being evaluated in the dispatch process and let's everything else run (after hooks, etc). AbstractResponse::send() doesn't control the dispatch process at all, it just simply sends the HTTP response to the client. Even though this may have a similar effect from a client standpoint, it has a very different effect on the application. The beauty of AbstractResponse::send() is that it allows other code to be run (email sending, cache creation, hook firing, clean-up processes, etc). So you can put other code in route controllers listed after the one that sends the response and have that code still execute.
3. Klein::skipRemaining() is a macro to throw an exception, so it stops your code dead in its tracks. This is an important distinction and should probably be documented better (sorry. 😞). So if you want to use it to control other routes, I would make it the absolute last line in the route's code.

Hopefully that clears up a few things. :P

[eimajenthat]

1. A way to pick a mode for your app would be cool. The multi-route matching can be cool, but the main use case I've seen is the templating example where you have a route at the beginning for the header, one at the end for the footer, and a bunch in the middle for the content. I'm using ServiceProvider::layout() to define a layout in the constructor for my AbstractController class, so I don't need to do that. Is there another use case? I think if there were an option to disable it, I might, to avoid accidentally matching two routes when I wasn't expecting it.
2. Thanks for the clarification about Klein::skipRemaining() and AbstractResponse::send(). That helps.
3. I think Klein::skipRemaining() may be broken. I'll work up a simple example and make sure it's not some other peculiarity of my code.