Hi, Is it possible to use different layouts for different parts of the application, perhaps, for different routes? Right now, it seems, only one layout per application is possible via the layout setting in the config file. Also, I am looking for a tutorial (cookbook recipe, perhaps) on how to create an authentication mechanism, one that would let me specify a bunch of routes that should be available only after login, redirecting the user to a login page. Many thanks, -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================
On Wednesday 04 August 2010 04:00:37 P Kishor wrote:
Hi,
Is it possible to use different layouts for different parts of the application, perhaps, for different routes? Right now, it seems, only one layout per application is possible via the layout setting in the config file.
When calling template, you can optionally specify the layout to use via the third param, e.g.: template 'page.tt' => { foo => 'bar'}, { layout => 'otherlayout.tt' }; You could probably also manage it by updating the layout setting from a before handler, if you want it controlled in one place: before sub { given (request->path) { when (m{^/area1}) { layout 'area1.tt'; } when (m{^/area2}) { layout 'area2.tt'; } default { layout 'main.tt'; } } }
Also, I am looking for a tutorial (cookbook recipe, perhaps) on how to create an authentication mechanism, one that would let me specify a bunch of routes that should be available only after login, redirecting the user to a login page.
The cookbook itself contains such an example: http://search.cpan.org/dist/Dancer/lib/Dancer/Cookbook.pod#Sessions_and_logg... Basically, use a before handler to check whether the user is logged in yet; if not, and they're requesting a page other than the login page, send them to the login page instead. At some point I'd like to write a few Dancer::Plugin::Auth modules to make this even easier; for instance, I could write one which uses PAM to authenticate real system users, so you could just 'use Dancer::Plugin::Auth::PAM', and anyone with a real user account on the machine hosting the app could log in easily. Similarly, D::P::Auth::IMAP and D::P::Auth::LDAP could be useful too. 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)
On Wed, Aug 4, 2010 at 4:31 AM, David Precious <davidp@preshweb.co.uk> wrote:
On Wednesday 04 August 2010 04:00:37 P Kishor wrote:
Hi,
Is it possible to use different layouts for different parts of the application, perhaps, for different routes? Right now, it seems, only one layout per application is possible via the layout setting in the config file.
When calling template, you can optionally specify the layout to use via the third param, e.g.:
template 'page.tt' => { foo => 'bar'}, { layout => 'otherlayout.tt' };
You could probably also manage it by updating the layout setting from a before handler, if you want it controlled in one place:
before sub { given (request->path) { when (m{^/area1}) { layout 'area1.tt'; } when (m{^/area2}) { layout 'area2.tt'; } default { layout 'main.tt'; } } }
Great! both of the above answers should be in the cookbook/docs.
Also, I am looking for a tutorial (cookbook recipe, perhaps) on how to create an authentication mechanism, one that would let me specify a bunch of routes that should be available only after login, redirecting the user to a login page.
The cookbook itself contains such an example:
http://search.cpan.org/dist/Dancer/lib/Dancer/Cookbook.pod#Sessions_and_logg...
Basically, use a before handler to check whether the user is logged in yet; if not, and they're requesting a page other than the login page, send them to the login page instead.
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'); } } } 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?
At some point I'd like to write a few Dancer::Plugin::Auth modules to make this even easier; for instance, I could write one which uses PAM to authenticate real system users, so you could just 'use Dancer::Plugin::Auth::PAM', and anyone with a real user account on the machine hosting the app could log in easily. Similarly, D::P::Auth::IMAP and D::P::Auth::LDAP could be useful too.
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)
-- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================
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)
participants (2)
-
David Precious -
P Kishor