On Wednesday 04 August 2010 14:39:01 P Kishor wrote:
Great! both of the above answers should be in the cookbook/docs.
I already added the first the other day so it'll be in the next Dancer release; it wouldn't hurt to include the "different layout for different URL stubs using a before handler" one in the cookbook too, agreed.
Actually, I did see that. My question arose from the need to "set" certain routes as being available only after logging in, and being able to do that in one place. Now, your answer above to my layouts question has given me the idea that I can apply the same tactic for logging in also. Would something like below work?
before sub { given (request->path) { when (m{^/area1|^/area2|^/district9}) { request->path_info('/login'); } } }
Yes. The example from the cookbook sends all requests (except requests to the login page) to the login page, unless you're logged in. If some pages should be available when not logged in but others require a login, then you can easily do what you just demonstrated :)
btw, what is the difference between request->.. and redirect->.., I mean, in effect, what is the difference? I am guessing the first one will internally "redirect" keeping all the request params intact, while the latter will redirect as if it were a new request, thereby losing all the request params, no?
The before handler, as the name suggests, runs before the request is handed off to an actual route handler. request->path_info('/login') means that the request is now going to be treated as though it was originally to /login. Cheers Dave P -- David Precious <davidp@preshweb.co.uk> http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)