Include the method, and the pattern the compiled regex was generated from.
For some reason, t/03_route_handler/18_auto_page.t expected a non-existent page to return a 500 error rather than a 404, which seems stupid and wrong. Unless I'm missing something, this test was merely expecting retarded behaviour which was previously present, and needs to be updated for now-sane behaviour.
Replace detailed docs with a pointer to the hook keyword.
If we don't find a direct match for `views/$path`, try appending `/index` to the path and looking again. This means that, if the request was for `/foo` and we didn't have `views/foo`, we'll then look for `views/foo/index.tt`, and use that if found. This is something I've missed for a long time, and makes the auto_page feature a lot more useful, I think.
Instead of adding a route to the app to catch requests for /:page and see if we can handle that, and pass if not, add a new `render_autopage()` to `Dancer::Renderer` which is called by `Dancer::Handler` if no route / static file matched. This immediately makes the auto_page feature more usable, as it can handle sub-directories properly now (e.g. given a request for `/foo/bar`, a view named `foo/bar.tt` will be rendered, as you'd expect). (Heh, look at that - the commit message explaining is almost as long as the code needed to just fucking do it :) )
There's a far better way coming in the next few commits.
This provides a consistant example throughout the documentation.
on line 30 of Hook.pm. Why not just have all the examples refer to before_template_render instead.
previous functions have been deprecated since version 1.3080.
In the example for exporting only the "route controllers", remove before & after (as they're deprecated, and it's arguable whether they ever really belonged there), and add del. Prompted by @skington - cheers Sam.
Fixes GH-738. (Arguably, though, the code that showed up this missing exception type ought to use Core::Route, I think, as the issue is that `params` was called wrongly from within a route handler - the problem isn't with the request. I guess it comes down to, should the exception type indicate the point the exception was raised, or the original source of the problem, if known?)