-
-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Routing: debugger panel shows wrong route as matched #1352
Comments
The point here is, that the foreach ($routeList as $index => $route) {
$appRequest = $routeList->match($index, $httpRequest);
} |
That is true but when I used only parent then all subroutes were detected and if only route is used then the most general (last) route is used (current solution). I have tried some combination of parent and child route but hierarchy structure can be really deep. |
Recursion is not a problem, it's simply a feature request to allow call match on concrete route in routelist, and all will be solved. |
I have an idea. In
...
$appRequest = $route->match($httpRequest);
if ($appRequest !== NULL) {
$name = $appRequest->getPresenterName();
if (strncmp($name, 'Nette:', 6)) {
$appRequest->setPresenterName($this->module . $name);
}
if ($route instanceof Route) {
$this->onMatch($this, $route);
}
return $appRequest;
}
... Related changes would be needed in |
Not bad at all! |
I have think about it and it is not so simple. There is a problem you want all basic routes (leafs of tree) to show them in debugger panel so you have depth first strategy in tree traversing. But for correct match in debugger panel you need top based call of method |
There is a problem using some custom
Nette\Application\Routers\RouteList
which has some code using in request matching which needs to be only in some subclass ofNette\Application\Routers\RouteList
. For example some global settings of whole route group are used only in the list which are used for, lets say, handling oflocale
parameter.There is NO problem with matching and handling request itself because there is some indirect recursion but in debugger panel there is another logic which broke its transparent behavior (recursion is not used). Another logic must be here there is not other way to find all routes (now). How you can see there is no call of
match
method on the list which then causes that debugger panel shows wrong route as matched.I have been thinking about it and tried some quick solutions but all did not work as I expected. Any ideas welcome!
The text was updated successfully, but these errors were encountered: