Dancer 1 or Dancer 2?
Hi! I'm starting a smaller web application. Would it make sense to use Dancer 2 already? Best regards, Alex
It depends on the features you want, and how much you're willing to put up with. :) Dancer2 is still not fully stable. Things are changing. However, it has some spiffier features and allows some things which weren't possible in D1. For the normal day-to-day stuff, it should perfectly fine. Hit us up with any issues you find! :) On Thu, Sep 11, 2014 at 9:58 PM, Alex Becker <asb.cpan@gmail.com> wrote:
Hi!
I'm starting a smaller web application. Would it make sense to use Dancer 2 already?
Best regards, Alex
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Fri, Sep 12, 2014 at 11:18 AM, Sawyer X <xsawyerx@gmail.com> wrote:
It depends on the features you want, and how much you're willing to put up with. :)
Dancer2 is still not fully stable. Things are changing. However, it has some spiffier features and allows some things which weren't possible in D1.
Is there a comparison table between D1 and D2 ? Gabor
2014-09-12 10:39 GMT+02:00 Gabor Szabo <gabor@szabgab.com>:
On Fri, Sep 12, 2014 at 11:18 AM, Sawyer X <xsawyerx@gmail.com> wrote:
It depends on the features you want, and how much you're willing to put up with. :)
Dancer2 is still not fully stable. Things are changing. However, it has some spiffier features and allows some things which weren't possible in D1.
Is there a comparison table between D1 and D2 ?
That would be something very good to provide, indeed. -- Alexis Sukrieh http://twitter.com/sukria - http://blog.sukria.net "People get annoyed when you try to debug them." -- Larry Wall
It was also mentioned in the discussion about the roadmap for D2 Best, VinceW On 09/12/2014 10:59 AM, Alexis Sukrieh wrote:
2014-09-12 10:39 GMT+02:00 Gabor Szabo <gabor@szabgab.com>:
On Fri, Sep 12, 2014 at 11:18 AM, Sawyer X <xsawyerx@gmail.com> wrote:
It depends on the features you want, and how much you're willing to put up with. :)
Dancer2 is still not fully stable. Things are changing. However, it has some spiffier features and allows some things which weren't possible in D1.
Is there a comparison table between D1 and D2 ?
That would be something very good to provide, indeed.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
One thing I've noticed is that in Dancer2 the before hooks are executed even on static files; that way https://metacpan.org/pod/distribution/Dancer/lib/Dancer/Cookbook.pod#Session... is not working at all, because if the user is not logged in, the static (css, js etc) files are not served. Back at the time that was one of the reasons I went with Dancer1 instead of Dancer2. On Fri, Sep 12, 2014 at 11:00 AM, VinceW <info@vincew.net> wrote:
It was also mentioned in the discussion about the roadmap for D2
Best, VinceW
On 09/12/2014 10:59 AM, Alexis Sukrieh wrote:
2014-09-12 10:39 GMT+02:00 Gabor Szabo <gabor@szabgab.com> <gabor@szabgab.com>:
On Fri, Sep 12, 2014 at 11:18 AM, Sawyer X <xsawyerx@gmail.com> <xsawyerx@gmail.com> wrote:
It depends on the features you want, and how much you're willing to put up with. :)
Dancer2 is still not fully stable. Things are changing. However, it has some spiffier features and allows some things which weren't possible in D1.
Is there a comparison table between D1 and D2 ?
That would be something very good to provide, indeed.
_______________________________________________ dancer-users mailing listdancer-users@dancer.pmhttp://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Unfortunately that is a terrible example. The concept of blocking all requests in a before() hook is... let's say, naive. In reality you would like to simply block specific requests according to session, a la David Golden's Auth::Tiny. The before hooks are basically run on every request. Static files are now served through the File handler. That means it will trigger the before hooks because it's a normal request. I would love to do it using the Static middleware, but then it will happen before a route check on it, so we can't have that. On Fri, Sep 12, 2014 at 11:21 AM, Kovács Dávid [ Davs ] <davserer@gmail.com> wrote:
One thing I've noticed is that in Dancer2 the before hooks are executed even on static files; that way https://metacpan.org/pod/distribution/Dancer/lib/Dancer/Cookbook.pod#Session... is not working at all, because if the user is not logged in, the static (css, js etc) files are not served. Back at the time that was one of the reasons I went with Dancer1 instead of Dancer2.
On Fri, Sep 12, 2014 at 11:00 AM, VinceW <info@vincew.net> wrote:
It was also mentioned in the discussion about the roadmap for D2
Best, VinceW
On 09/12/2014 10:59 AM, Alexis Sukrieh wrote:
2014-09-12 10:39 GMT+02:00 Gabor Szabo <gabor@szabgab.com> <gabor@szabgab.com>:
On Fri, Sep 12, 2014 at 11:18 AM, Sawyer X <xsawyerx@gmail.com> <xsawyerx@gmail.com> wrote:
It depends on the features you want, and how much you're willing to put up with. :)
Dancer2 is still not fully stable. Things are changing. However, it has some spiffier features and allows some things which weren't possible in D1.
Is there a comparison table between D1 and D2 ?
That would be something very good to provide, indeed.
_______________________________________________ dancer-users mailing listdancer-users@dancer.pmhttp://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On 09/12/2014 02:35 PM, Sawyer X wrote:
Unfortunately that is a terrible example. The concept of blocking all requests in a before() hook is... let's say, naive. In reality you would like to simply block specific requests according to session, a la David Golden's Auth::Tiny.
The before hooks are basically run on every request. Static files are now served through the File handler. That means it will trigger the before hooks because it's a normal request. I would love to do it using the Static middleware, but then it will happen before a route check on it, so we can't have that.
I still disagree with this change of behaviour from Dancer 1 to Dancer 2. What is the benefit of calling before hook for public files? Also in a production environment you might deliver static files with some other software (Nginx, ...) and you loose control on these public files anyway. Regards Racke -- Perl and Dancer Development Visit our Perl::Dancer conference 2014: http://act.perl.dance/
On Fri, Sep 12, 2014 at 3:21 PM, Stefan Hornburg (Racke) <racke@linuxia.de> wrote:
On 09/12/2014 02:35 PM, Sawyer X wrote:
Unfortunately that is a terrible example. The concept of blocking all requests in a before() hook is... let's say, naive. In reality you would like to simply block specific requests according to session, a la David Golden's Auth::Tiny.
The before hooks are basically run on every request. Static files are now served through the File handler. That means it will trigger the before hooks because it's a normal request. I would love to do it using the Static middleware, but then it will happen before a route check on it, so we can't have that.
I still disagree with this change of behaviour from Dancer 1 to Dancer 2. What is the benefit of calling before hook for public files? Also in a production environment you might deliver static files with some other software (Nginx, ...) and you loose control on these public files anyway.
The point is that this is not a selection of behavior. It isn't "we want a before hook on public files", but "because public files are serves as a handler, they will have before hooks called too". It's implicit behavior because of the restructuring of public files as file handlers.
On Fri, Sep 12, 2014 at 8:56 AM, Sawyer X <xsawyerx@gmail.com> wrote:
On Fri, Sep 12, 2014 at 3:21 PM, Stefan Hornburg (Racke) <racke@linuxia.de
wrote:
On 09/12/2014 02:35 PM, Sawyer X wrote:
Unfortunately that is a terrible example. The concept of blocking all requests in a before() hook is... let's say, naive. In reality you would like to simply block specific requests according to session, a la David Golden's Auth::Tiny.
[Disclaimer: I have only ever used Dancer1. I lurk here specifically so that I will know when things are stable enough to start building new stuff in Dancer2. Please pardon my ignorance or just press delete.]
What do you mean by "in reality you would like to simply block specific requests according to session"? I have live code being used in a mission critical and highly sensitive project with a before hook (approximately) like this: hook before => sub { #whitelist /ip route as not needing any auth check return if (request->path_info =~ m{(^/ip$)|}); my $user = Dancer::Plugin::Auth::Extensible::Provider::Redacted->ip_login(); var user => $user; $user or die "no user"; }; This is very clean design; anyone adding a new route (and the nature of the project and team were such that this was happening without me really being able to oversee it, and contributions were being made by Dancer novices) could not accidentally make that route available without authentication. If they needed an un-authenticated route, they would have to go through the before hook. I'm not sure I'm understanding what you're talking about here (I don't know what a "route check" is, for example), but it sounds to me like Dancer2 removes this capability?
The before hooks are basically run on every request. Static files are now served through the File handler. That means it will trigger the before hooks because it's a normal request. I would love to do it using the Static middleware, but then it will happen before a route check on it, so we can't have that.
I still disagree with this change of behaviour from Dancer 1 to Dancer 2. What is the benefit of calling before hook for public files? Also in a production environment you might deliver static files with some other software (Nginx, ...) and you loose control on these public files anyway.
The point is that this is not a selection of behavior. It isn't "we want a before hook on public files", but "because public files are serves as a handler, they will have before hooks called too". It's implicit behavior because of the restructuring of public files as file handlers.
I suppose I could do the same as I have above but put in an exception in my before hook allowing through public files--would that be feasible in the new architecture? Rather than considering the cited example naive, I kind of think it's naive to think you _wouldn't_ have applications where everything served by code is locked down, and all static files are unrestricted. I would think you really want to have the option of having static files served with as little intervention by code as possible. mike
That is exactly how I handle auth in all my apps. It's also shown as an example in the cookbook. Not sure why it's naive. On Wed, Sep 17, 2014 at 1:29 PM, Mike South <msouth@gmail.com> wrote:
On Fri, Sep 12, 2014 at 8:56 AM, Sawyer X <xsawyerx@gmail.com> wrote:
On Fri, Sep 12, 2014 at 3:21 PM, Stefan Hornburg (Racke) < racke@linuxia.de> wrote:
On 09/12/2014 02:35 PM, Sawyer X wrote:
Unfortunately that is a terrible example. The concept of blocking all requests in a before() hook is... let's say, naive. In reality you would like to simply block specific requests according to session, a la David Golden's Auth::Tiny.
[Disclaimer: I have only ever used Dancer1. I lurk here specifically so that I will know when things are stable enough to start building new stuff in Dancer2. Please pardon my ignorance or just press delete.]
What do you mean by "in reality you would like to simply block specific requests according to session"?
I have live code being used in a mission critical and highly sensitive project with a before hook (approximately) like this:
hook before => sub { #whitelist /ip route as not needing any auth check return if (request->path_info =~ m{(^/ip$)|});
my $user = Dancer::Plugin::Auth::Extensible::Provider::Redacted->ip_login();
var user => $user;
$user or die "no user"; };
This is very clean design; anyone adding a new route (and the nature of the project and team were such that this was happening without me really being able to oversee it, and contributions were being made by Dancer novices) could not accidentally make that route available without authentication. If they needed an un-authenticated route, they would have to go through the before hook.
I'm not sure I'm understanding what you're talking about here (I don't know what a "route check" is, for example), but it sounds to me like Dancer2 removes this capability?
The before hooks are basically run on every request. Static files are now served through the File handler. That means it will trigger the before hooks because it's a normal request. I would love to do it using the Static middleware, but then it will happen before a route check on it, so we can't have that.
I still disagree with this change of behaviour from Dancer 1 to Dancer 2. What is the benefit of calling before hook for public files? Also in a production environment you might deliver static files with some other software (Nginx, ...) and you loose control on these public files anyway.
The point is that this is not a selection of behavior. It isn't "we want a before hook on public files", but "because public files are serves as a handler, they will have before hooks called too". It's implicit behavior because of the restructuring of public files as file handlers.
I suppose I could do the same as I have above but put in an exception in my before hook allowing through public files--would that be feasible in the new architecture?
Rather than considering the cited example naive, I kind of think it's naive to think you _wouldn't_ have applications where everything served by code is locked down, and all static files are unrestricted.
I would think you really want to have the option of having static files served with as little intervention by code as possible.
mike
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (9)
-
Alex Becker -
Alexis Sukrieh -
Gabor Szabo -
Jacques Lareau -
Kovács Dávid [ Davs ] -
Mike South -
Sawyer X -
Stefan Hornburg (Racke) -
VinceW