dancer2's prototype is there, feedback needed
Hi there, I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised. -*- https://github.com/sukria/dancer2 -*- dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes: - no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...) The prototype I've pushed to GitHub currently covers ~80% of the DSL of Dancer. It's able to run simple applications (it can run the PerlDancer.org website for instance). Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests. You can test very easily your app with dancer2: $ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl Also, important to know: most of the plugins may not be working well. Thanks a lot ;)
On Fri, Sep 30, 2011 at 1:47 PM, sukria <sukria@sukria.net> wrote:
I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised.
Amazing work! Thanks to all involved!
Hello, Looks interesting, but I personally very dislike Moose/Mouse/Moo syntax. Will it be possible to write plugins for Dancer2 without Moo? 30.09.2011 16:47, sukria пишет:
Hi there,
I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised.
-*- https://github.com/sukria/dancer2 -*-
dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes:
- no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...)
The prototype I've pushed to GitHub currently covers ~80% of the DSL of Dancer. It's able to run simple applications (it can run the PerlDancer.org website for instance).
Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests.
You can test very easily your app with dancer2:
$ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl
Also, important to know: most of the plugins may not be working well.
Thanks a lot ;) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
On Sep 30, 2011, at 7:24 AM, Nick Knutov wrote:
Hello,
Looks interesting, but I personally very dislike Moose/Mouse/Moo syntax. Will it be possible to write plugins for Dancer2 without Moo?
I too detest Moose, but hadn't seen Moo, which now looks very interesting. It seems to be in the spirit of ::Tiny, and I love all ::Tiny (pretty much exclusively use Template::Tiny). sidenote -- Why I dislike Moose: I never installed Moose. But, I ended up getting Moose because I installed something else (I think it was an app based on Catalyst). So, I wanted a croissant... and suddenly I saw all the ingredients in the grocery store, and all the parts of a kitchen, and a house and a factory flying by me... WTF! Maybe it is just perception. If Moose had installed silently, and I had never known about it, I wouldn't have been bothered by it. Lesson: keep Dancer lightweight. Every change in its core should be a change that has a legitimate reason, not gratuitous.
30.09.2011 16:47, sukria пишет:
Hi there,
I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised.
-*- https://github.com/sukria/dancer2 -*-
dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes:
- no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...)
The prototype I've pushed to GitHub currently covers ~80% of the DSL of Dancer. It's able to run simple applications (it can run the PerlDancer.org website for instance).
Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests.
You can test very easily your app with dancer2:
$ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl
Also, important to know: most of the plugins may not be working well.
Thanks a lot ;)
On Fri, 30 Sep 2011 08:15:09 -0500, "Mr. Puneet Kishor" <punk.kish@gmail.com> wrote:
Lesson: keep Dancer lightweight. Every change in its core should be a change that has a legitimate reason, not gratuitous.
Moo is pure Perl5 code. It hasnt any non-core deps, so Dancer2 wont bring half of the CPAN. The fact dancer2 is based on Moo is a huge benefit for Dancer itself, because it gives all the goodness of post-modern programming to the core. Take a look at the roles we have, at how the hooks work and how we can factorize stuff like headers or configuraiton bits. Also think at the power of lazyness in a web framework. All this is possible thanks to Moo, at a very reasonable price: one dependency only. Anyway, my announcement was sent in order to get feedback about application upgrades (from Dancer 1 to 2), so please, dont turn this into a discussion about Moose/Mouse/Moo/Mo/M ;) Thanks.
On Fri, Sep 30, 2011 at 10:12 AM, sukria <sukria@sukria.net> wrote:
Anyway, my announcement was sent in order to get feedback about application upgrades (from Dancer 1 to 2), so please, dont turn this into a discussion about Moose/Mouse/Moo/Mo/M ;)
Questions if you have a moment:
- Is the object of this to be 100% back compatible? - Are we going to change how we do plugins? - Considering this is a rewrite, is there any augmentation as part of this? (New functionality, or just better?) Thanks sukria! meraxes -- dave.s.doyle@gmail.com
On Fri, 30 Sep 2011 10:44:27 -0400, Dave Doyle <dave.s.doyle@gmail.com> wrote:
Questions if you have a moment:
- Is the object of this to be 100% back compatible?
Given that everything that is soft-deprecated in Dancer1 will be hard-depreacted in 2, it's intended to be 100% compatible with the DSL. Also, the configuration files syntax will change (so an existing application might need to update its configuration file). Plugins will be more complex to handle, I'll give more details when I'll take care of Dancer::Plugin in 2.
- Are we going to change how we do plugins?
I don't want to change that (being able to extend the DSL is - I think - a nice an interesting feature. But plugins author will have access to the whole Core API. So they will be able to write more powerful tools, like generic route handlers (see https://github.com/sukria/dancer2/blob/master/lib/Dancer/Handler/File.pm for an example). So more power expected for plugins.
- Considering this is a rewrite, is there any augmentation as part of this? (New functionality, or just better?)
Lots of augmentation: * namespace scoping (settings, engines, prefixes, filters, everything is scoped in the caller's namespace now). * faster (so far, my benchmakrs tell me that Dancer2 is 30% faster than 1). * important design issues solved (no more applications collisions) * Much less code lines, so obviously, more stable/maintainable code-base (Dancer 1 is 12k lines, Dancer2 is 4k currently, for 80% of the DSL).
Thanks sukria!
Welcome!
You can test very easily your app with dancer2:
$ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl
This seems to work as described.
Also, important to know: most of the plugins may not be working well.
And load_app is missing, so there's only one small reporting app that I could try, but that seemed to function fine. Perl 5.10 on Debian. -- Richard Huxton Archonet Ltd
On Fri, Sep 30, 2011 at 6:47 AM, sukria <sukria@sukria.net> wrote:
- no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...)
I, for one, welcome our new Moo Overlord. I appreciate some think "keep it lightweight" because that's what dancer is, but I don't think Moo is overly heavy. That being said, I have huge affection for Moose. I sense a new tutorial coming on: "Tap Dancing Bovines" meraxes -- dave.s.doyle@gmail.com
On Fri, Sep 30, 2011 at 6:47 AM, sukria <sukria@sukria.net> wrote:
Hi there,
I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised.
-*- https://github.com/sukria/dancer2 -*-
dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes:
- no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...)
The prototype I've pushed to GitHub currently covers ~80% of the DSL of Dancer. It's able to run simple applications (it can run the PerlDancer.org website for instance).
This is exciting news. What people love about Dancer is its DSL syntax, in other words, its interface. I hope you try to keep the interface compatible as possible. Refactoring the implementation to be more maintainable etc. is great. -Naveed
2011/10/2 Naveed Massjouni <naveedm9@gmail.com>:
This is exciting news. What people love about Dancer is its DSL syntax, in other words, its interface. I hope you try to keep the interface compatible as possible. Refactoring the implementation to be more maintainable etc. is great. -Naveed
It's the idea: * DSL 100% compatible with 1.X (given that anything deprecated in 1 will disappear in 2) * 100% compatible with Plugins * configuration file syntax may change (and it will) * core engines config may change (TT will use [% as default tags for instance) Of course this is a target, and as I'm rewtiting everything, chances are that there will be breakages. To make the transition as smooth as possible though, I plan to provide a "glue" module which would be used like "Dancer::Compatibility version => 2". This module would do anythig it can to make an old Dancer1 application works under 2. This is an idea, we'll see when I'll be there ;)
On Fri, Sep 30, 2011 at 12:47:03PM +0200, sukria wrote:
Hi there,
I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised.
-*- https://github.com/sukria/dancer2 -*- ... You can test very easily your app with dancer2:
$ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl
Does Dancer2 require Dancer1? On `make test` there are a lot of errors: ...Can't locate Dancer/HTTP.pm in @INC... ...Can't locate Dancer/Exception.pm in @INC... ...Can't locate Dancer/Config.pm in @INC... These modules are missing in lib -- Vladimir Lettiev aka crux ✉ theCrux@gmail.com
2011/10/3 <thecrux@gmail.com>:
On `make test` there are a lot of errors:
...Can't locate Dancer/HTTP.pm in @INC... ...Can't locate Dancer/Exception.pm in @INC... ...Can't locate Dancer/Config.pm in @INC...
These modules are missing in lib
Indeed, thanks for the report, I'm going to fix that.
sukria wrote, On 09/30/2011 06:47 AM:
Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests.
Problem 1: ========= 1. Created a new Dancer application: $ dancer -a d2test2 $ cd d2test2 2. Run with new Dancer: $ perl -I ../sources/dancer2/lib ./bin/app.pl I get this output: === core: binding app to main core: binding app to d2test2 core: [d2test2] running 'get' with /, CODE(0x320b1d8) core: [d2test2] running 'true' with core: [main] running 'dance' with HTTP::Server::Simple::PSGI: You can connect to your server at http://localhost:3000/ core: [d2test2] running 'template' with index ==== But when visiting "http://localhost:3000" I get: === Internal Server Error Can't locate object method "context" via package "Dancer::Template::Simple" at /home/gordon/sources/dancer2/lib/Dancer.pm line 141, <DATA> line 16. === Changing the template engine to "template_toolkit" simply changes the error message to: === Internal Server Error Can't locate object method "context" via package "Dancer::Template::TemplateToolkit" at /home/gordon/sources/dancer2/lib/Dancer.pm line 141, <DATA> line 16. === Problem 2: ========== 1. created a new Dancer application" $ dancer -a d2test3 $ cd d2test3 2. Added a single line to "./lib/d2test3.pm" (with "prefix "/testme";"): $ sed -i '6iprefix "/testme";' lib/d2test3.pm 3. Run with new Dancer, I get the following error: === $ perl -I ../sources/dancer2/lib ./bin/app.pl core: binding app to main core: binding app to d2test3 core: [d2test3] running 'prefix' with /testme core: [d2test3] running 'get' with /, CODE(0x1870da8) core: [d2test3] running 'true' with core: [main] running 'dance' with Cannot combine a prefix (/testme) with a regular expression ((?-xism:.*)) at (eval 72) line 74 === Using perl 5.12.4 (on debian), Template::Toolkit 2.22, Dancer2 74a925baac7f67c306404e4a0316060211c8ef5d (Oct 2). -gordon
Hi and thanks for the test report. 2011/10/3 Assaf Gordon <gordon@cshl.edu>:
sukria wrote, On 09/30/2011 06:47 AM:
Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests.
Problem 1: [...] Can't locate object method "context" via package "Dancer::Template::Simple" at /home/gordon/sources/dancer2/lib/Dancer.pm line 141, <DATA> line 16.
Template::Simple is not ported yet.
Changing the template engine to "template_toolkit" simply changes the error message to: Yeah, the syntax changed, you should do the following in your config:
template: "toolkit" And also, the default tags are now back to TT's default : [% and %], you can override them with: engines: template: toolkit: START_TAG: '<%' END_TAG: '%>' [...]
Problem 2: ========== 1. created a new Dancer application" $ dancer -a d2test3 $ cd d2test3
2. Added a single line to "./lib/d2test3.pm" (with "prefix "/testme";"): $ sed -i '6iprefix "/testme";' lib/d2test3.pm
3. Run with new Dancer, I get the following error: === $ perl -I ../sources/dancer2/lib ./bin/app.pl core: binding app to main core: binding app to d2test3 core: [d2test3] running 'prefix' with /testme core: [d2test3] running 'get' with /, CODE(0x1870da8) core: [d2test3] running 'true' with core: [main] running 'dance' with Cannot combine a prefix (/testme) with a regular expression ((?-xism:.*)) at (eval 72) line 74
Hmm, this looks to be a regression, but can you make sure it actuallt works under Dancer1 ? Thanks!
Alexis Sukrieh wrote, On 10/03/2011 12:30 PM:
2011/10/3 Assaf Gordon <gordon@cshl.edu>:
Changing the template engine to "template_toolkit" simply changes the error message to: Yeah, the syntax changed, you should do the following in your config:
template: "toolkit"
That solved it. A minor difference (from Dancer 1): In the "index.tt" template, there's a sidebar which contains: ===== <h3>Your application's environment</h3> <ul> <li>Location: <code>/home/gordon/projects/dancer_test/MyFirstApp</code></li> <li>Template engine: <code><% settings.template %></code></li> <li>Logger: <code><% settings.logger %></code></li> <li>Environment: <code><% settings.environment %></code></li> </ul> ===== With Dancer 1, the output is : === Your application's environment Location: /home/gordon/projects/dancer_test/MyFirstApp Template engine: simple Logger: console Environment: development === With Dancer 2, the output is: === Your application's environment Location: /home/gordon/projects/dancer_test/MyFirstApp Template engine: Dancer::Template::Toolkit=HASH(0x188dcb8) Logger: Dancer::Logger::Console=HASH(0x1602758) Environment: === That is - with the "HASH(0x188dcb8)" part of the engine & logger objects. Also - it seems "environment" is not set, but perhaps that's another (updated) configuration option that I'm missing.
[...]
Problem 2: Cannot combine a prefix (/testme) with a regular expression ((?-xism:.*)) at (eval 72) line 74
Hmm, this looks to be a regression, but can you make sure it actuallt works under Dancer1 ?
Yes, it works with Dancer1. Here's how to reproduce: ========= ## ## Create a new application ## $ dancer -a d2test4 [...] $ cd d2test4/ ## ## Add a "prefix" statement ## $ sed -i '6iprefix "/testme";' lib/d2test4.pm ## ## show the updated application ## $ cat lib/d2test4.pm package d2test4; use Dancer ':syntax'; our $VERSION = '0.1'; prefix "/testme"; get '/' => sub { template 'index'; }; true; ## ## Run with Dancer 1 ## $ ./bin/app.pl [15837] core @0.000008> loading Dancer::Handler::Standalone handler in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 41 [15837] core @0.000163> loading handler 'Dancer::Handler::Standalone' in /usr/local/share/perl/5.12.4/Dancer.pm l. 366
Dancer 1.3072 server 15837 listening on http://0.0.0.0:3000 == Entering the development dance floor ... [15837] core @0.000123> request: GET /testme/ from 127.0.0.1 in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 52 [15837] core @0.000502> [hit #1]trying to match `/testme/' against /(?-xism:^(?-xism:^\/testme(?:\/)?$)$)/ in /usr/local/share/perl/5.12.4/Dancer/Route.pm l. 78 [15837] core @0.000641> [hit #1] --> got 1 in /usr/local/share/perl/5.12.4/Dancer/Route.pm l. 95 [15837] core @0.006332> [hit #1]response: 200 in /usr/local/share/perl/5.12.4/Dancer/Handler.pm l. 167 ^C
## ## Run with Dancer 2 ## $ perl -I /home/gordon/sources/dancer2/lib ./bin/app.pl core: binding app to main core: binding app to d2test4 core: [d2test4] running 'prefix' with /testme core: [d2test4] running 'get' with /, CODE(0x2b082b8) core: [d2test4] running 'true' with core: [main] running 'dance' with Cannot combine a prefix (/testme) with a regular expression ((?-xism:.*)) at (eval 72) line 74 ====== I did not change the "config.yml" file with the correct template syntax, but I assume it is not relevant for this behavior. -gordon
On Monday 03 October 2011 17:30:37 Alexis Sukrieh wrote:
Changing the template engine to "template_toolkit" simply changes the error message to: Yeah, the syntax changed, you should do the following in your config:
template: "toolkit"
I'm not sure I really like the change from Dancer::Template::TemplateToolkit to Dancer::Template::Toolkit; the logical layout is a module under the Dancer::Template namespace named after the templating engine it uses, i.e. "Dancer::Template::EngineName" - e.g. Dancer::Template::TemplateToolkit, Dancer::Template::HTMLTemplate, etc. Using just "toolkit" seems a bit wrong to me - what do you think? It also seems a bit pointless lowercasing the engine name - we could just make it so the engine name you provide is whatever you see after Dancer::Template:: with no translation at all - so TemplateToolkit is Dancer::Template::TemplateToolkit, HTMLTemplate is Dancer::Template::HTMLTemplate, etc etc. What do you think? It just seems a little unintutive to me otherwise, and pretty much everything about Dancer to date has seemed pretty intuitive to me (it works pretty much as I'd expect it to, to the point where I can write a big load of code without consulting docs, and it'll Just Work :) ) Cheers Dave P -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On 10/03/2011 09:43 PM, David Precious wrote:
I'm not sure I really like the change from Dancer::Template::TemplateToolkit to Dancer::Template::Toolkit; the logical layout is a module under the Dancer::Template namespace named after the templating engine it uses, i.e. "Dancer::Template::EngineName" - e.g. Dancer::Template::TemplateToolkit, Dancer::Template::HTMLTemplate, etc. Using just "toolkit" seems a bit wrong to me - what do you think?
I second that. The full name of the template engine is "Template Toolkit", so using just "toolkit" seems somewhat inconsistent.
It also seems a bit pointless lowercasing the engine name - we could just make it so the engine name you provide is whatever you see after Dancer::Template:: with no translation at all - so TemplateToolkit is Dancer::Template::TemplateToolkit, HTMLTemplate is Dancer::Template::HTMLTemplate, etc etc.
Yeah, I think this might also be good for consistency. The plugins configuration section uses the actual (non-lowercase) plugin names, so the same rule could be applied to template engines. -- Michal Wojciechowski http://odyniec.net/ | http://search.cpan.org/~odyniec/
On Mon, Oct 3, 2011 at 12:43 PM, David Precious <davidp@preshweb.co.uk>wrote:
On Monday 03 October 2011 17:30:37 Alexis Sukrieh wrote:
Changing the template engine to "template_toolkit" simply changes the error message to: Yeah, the syntax changed, you should do the following in your config:
template: "toolkit"
I'm not sure I really like the change from Dancer::Template::TemplateToolkit to Dancer::Template::Toolkit; the logical layout is a module under the Dancer::Template namespace named after the templating engine it uses, i.e. "Dancer::Template::EngineName" - e.g. Dancer::Template::TemplateToolkit, Dancer::Template::HTMLTemplate, etc. Using just "toolkit" seems a bit wrong to me - what do you think?
It also seems a bit pointless lowercasing the engine name - we could just make it so the engine name you provide is whatever you see after Dancer::Template:: with no translation at all - so TemplateToolkit is Dancer::Template::TemplateToolkit, HTMLTemplate is Dancer::Template::HTMLTemplate, etc etc.
Just FYI, although the "distro" is called Template Toolkit the actual module is called only "Template" so if you're planning on using the names directly to load modules, to get Template Toolkit you'd have to have: Dancer::Template::Template
What do you think?
It just seems a little unintutive to me otherwise, and pretty much everything about Dancer to date has seemed pretty intuitive to me (it works pretty much as I'd expect it to, to the point where I can write a big load of code without consulting docs, and it'll Just Work :) )
Cheers
Dave P
-- David Precious ("bigpresh") http://www.preshweb.co.uk/
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
2011/10/3 David Precious <davidp@preshweb.co.uk>:
On Monday 03 October 2011 17:30:37 Alexis Sukrieh wrote:
Changing the template engine to "template_toolkit" simply changes the error message to: Yeah, the syntax changed, you should do the following in your config:
template: "toolkit"
I'm not sure I really like the change from Dancer::Template::TemplateToolkit to Dancer::Template::Toolkit; the logical layout is a module under the Dancer::Template namespace named after the templating engine it uses, i.e. "Dancer::Template::EngineName" - e.g. Dancer::Template::TemplateToolkit, Dancer::Template::HTMLTemplate, etc. Using just "toolkit" seems a bit wrong to me - what do you think?
Fair enough, I'll change it back to TemplateToolkit. Also, I plan to remove our Template::Simple engine in dancer2 in favor of Template::Tiny.
2011/10/3 Alexis Sukrieh <sukria@sukria.net>:
2011/10/3 David Precious <davidp@preshweb.co.uk>: Fair enough, I'll change it back to TemplateToolkit.
Also, I plan to remove our Template::Simple engine in dancer2 in favor of Template::Tiny.
It's now TemplateToolkit: https://github.com/sukria/dancer2/commit/8f9e88a38369364675407d2932d777df9ac...
2011/10/3 Assaf Gordon <gordon@cshl.edu>:
sukria wrote, On 09/30/2011 06:47 AM:
Problem 2: ========== 1. created a new Dancer application" $ dancer -a d2test3 $ cd d2test3
2. Added a single line to "./lib/d2test3.pm" (with "prefix "/testme";"): $ sed -i '6iprefix "/testme";' lib/d2test3.pm
3. Run with new Dancer, I get the following error: Cannot combine a prefix (/testme) with a regular expression ((?-xism:.*)) at (eval 72) line 74
This has been fixed here: https://github.com/sukria/dancer2/commit/f56e4f7a5e5880705162747d7cf9794f45d... Thanks for the report!
Hi, another problem: POST request with parameters hangs. Steps to reproduce: ==== ## New dancer app $ dancer -a d2test5post $ cd d2test5post/ ## Change the "GET" to a "POST": $ sed -i '/^get/s/^get/post/' lib/d2test5post.pm $ cat lib/d2test5post.pm package d2test5post; use Dancer ':syntax'; our $VERSION = '0.1'; post '/' => sub { template 'index'; }; true; ## run the application with Dancer 1: $ ./bin/app.pl ## ## In a new terminal, run the following commands: ## ## Access the app with "GET" - this fails (as expected). $ curl http://localhost:3000/ [ 404 response ] ## Access the app with "POST" (no parameters) - works OK $ curl -X POST http://localhost:3000/ [ ... ] ## Access the app with "POST" (and parameters) - works OK $ curl -X POST -d name=foobar http://localhost:3000/ [ ... ] ## ## Now test with Dancer 2 ## ## change the 'config.yml' and the templates to use Dancer2's TT $ sed -i '/^template:/s/".*"/"toolkit"/' config.yml $ sed -i 's/<%/[%/g' views/index.tt $ sed -i 's/%>/%]/g' views/index.tt $ sed -i 's/<%/[%/g' views/layouts/main.tt $ sed -i 's/%>/%]/g' views/layouts/main.tt ## Run with Dancer2 $ perl -I ../sources/dancer2/lib ./bin/app.pl ## ## In a new terminal, run the following commands ## ## Access the app with "GET" - this fails (as expected). $ curl http://localhost:3000/ [ 404 response ] ## Access the app with "POST" (no parameters) - works OK $ curl -X POST http://localhost:3000/ [ ... ] ## Access the app with "POST" (and parameters) - FAILS - the request hangs, BEFORE even reaching my 'post' handler code. $ curl -X POST -d name=foobar http://localhost:3000/ [ XXXX - Stuck - XXXX ] ================== regards, -gordon
Thanks for all these tests, I'm going to fix that. 2011/10/3 Assaf Gordon <gordon@cshl.edu>:
Hi,
another problem: POST request with parameters hangs.
Steps to reproduce: ==== ## New dancer app $ dancer -a d2test5post $ cd d2test5post/
## Change the "GET" to a "POST": $ sed -i '/^get/s/^get/post/' lib/d2test5post.pm $ cat lib/d2test5post.pm package d2test5post; use Dancer ':syntax';
our $VERSION = '0.1';
post '/' => sub { template 'index'; };
true;
## run the application with Dancer 1: $ ./bin/app.pl
## ## In a new terminal, run the following commands: ##
## Access the app with "GET" - this fails (as expected). $ curl http://localhost:3000/ [ 404 response ]
## Access the app with "POST" (no parameters) - works OK $ curl -X POST http://localhost:3000/ [ ... ]
## Access the app with "POST" (and parameters) - works OK $ curl -X POST -d name=foobar http://localhost:3000/ [ ... ]
## ## Now test with Dancer 2 ##
## change the 'config.yml' and the templates to use Dancer2's TT $ sed -i '/^template:/s/".*"/"toolkit"/' config.yml $ sed -i 's/<%/[%/g' views/index.tt $ sed -i 's/%>/%]/g' views/index.tt $ sed -i 's/<%/[%/g' views/layouts/main.tt $ sed -i 's/%>/%]/g' views/layouts/main.tt
## Run with Dancer2 $ perl -I ../sources/dancer2/lib ./bin/app.pl
## ## In a new terminal, run the following commands ##
## Access the app with "GET" - this fails (as expected). $ curl http://localhost:3000/ [ 404 response ]
## Access the app with "POST" (no parameters) - works OK $ curl -X POST http://localhost:3000/ [ ... ]
## Access the app with "POST" (and parameters) - FAILS - the request hangs, BEFORE even reaching my 'post' handler code. $ curl -X POST -d name=foobar http://localhost:3000/ [ XXXX - Stuck - XXXX ]
==================
regards, -gordon
Hi Assaf, Note, I've run this test against the last HEAD of the GitHub repo (master branch) 2011/10/3 Assaf Gordon <gordon@cshl.edu>:
## Access the app with "POST" (and parameters) - FAILS - the request hangs, BEFORE even reaching my 'post' handler code. $ curl -X POST -d name=foobar http://localhost:3000/ [ XXXX - Stuck - XXXX ]
I can't reproduce that. Here is what I did: $ dancer -a d2test5post $ sed -i '/^get/s/^get/post/' lib/d2test5post.pm Then I've updated the configuration file to use "template_toolkit" and change the engines config section to fit the dancer2 expectation: template: "template_toolkit" engines: template: template_toolkit: encoding: 'utf8' start_tag: '<%' end_tag: '%>' Then I ran the app: $ perl -I/home/sukria/Devel/dancer2/lib bin/app.pl core: binding app to main core: binding app to d2test5post core: [d2test5post] running 'post' with /, CODE(0xa30eb50) core: [d2test5post] running 'true' with core: [main] running 'dance' with HTTP::Server::Simple::PSGI: You can connect to your server at http://localhost:3000/ And then it worked pretty well: $ curl -I http://0:3000/ HTTP/1.0 404 Not Found $ curl -I -X POST http://0:3000/ HTTP/1.0 200 OK
Hello Alexis, I'm still getting this behavior (POST with parameters is stuck) with the latest dancer2. But I have more details. Alexis Sukrieh wrote, On 10/08/11 05:54:
2011/10/3 Assaf Gordon <gordon@cshl.edu>:
## Access the app with "POST" (and parameters) - FAILS - the request hangs, BEFORE even reaching my 'post' handler code. $ curl -X POST -d name=foobar http://localhost:3000/ [ XXXX - Stuck - XXXX ]
I can't reproduce that. Here is what I did:
$ curl -I -X POST http://0:3000/ HTTP/1.0 200 OK
The missing part is adding POST parameters, with the following command: $ curl -I -X POST -d "hello=world" http://0:3000/ Here's what happens in my setup, to the best of my ability to debug dancer2: 1. Request arrives (after some trials and tribulations) to "Dancer::Core::Dispatcher->dispatch()" which finds the appropriate route. 2. "Dispatch()" runs: my $http_method = lc $context->request->method; but $context->request DOES NOT exist, so the "moo" auto-builder thingy calls "Dancer::Core::Context::_build_request". 3. A new Dancer::Core::Request object is created, goes to "Dancer::Core::Request->BUILD". Eventually calls "$self->_build_params()". 4. "Dancer::Core::Request->_build_params()" calls "_parse_post_params()" 5. "Dancer::Core::Request->_parse_post_params()" calls "_read_to_end()" 6. "Dancer::Core::Request->_read_to_end()" looks like this: ================ sub _read_to_end { my ($self) = @_; my $content_length = $self->content_length; return unless $self->_has_something_to_read(); if ($content_length > 0) { while (my $buffer = $self->_read()) { $self->{body} .= $buffer; $self->{_http_body}->add($buffer); } } return $self->{body}; } =============== I assume in your testing (without POST parameters), "content_length" was zero, and so nothing is read, and the function returns undef. In my case, "content_length" is the length of the POST parameters (e.g. "hello=world" = 11 characters). So it calls "$self->_read()". 7. "read_()" looks like this (without my sprinkled "warn" statements): =================== sub _read { my ($self,) = @_; my $remaining = $self->content_length - $self->{_read_position}; warn "#### remaining = $remaining"; my $maxlength = $self->{_chunk_size}; warn "#### maxlength = $maxlength"; return if ($remaining <= 0); my $readlen = ($remaining > $maxlength) ? $maxlength : $remaining; warn "#### readlen = $readlen"; my $buffer; my $rc; warn "##### before read"; warn "###### input_handle = " . dump($self->input_handle) ; $rc = $self->input_handle->read($buffer, $readlen); warn "##### after read"; if (defined $rc) { $self->{_read_position} += $rc; return $buffer; } else { croak "Unknown error reading input: $!"; } } =================== And Dancer2 is stuck in the: $rc = $self->input_handle->read($buffer, $readlen); Statement, unable to read the expected number of characters. The printed output is: ======== #### remaining = 11 at /home/gordon/sources/dancer2/lib/Dancer/Core/Request.pm line 552, <DATA> line 16. #### maxlength = 4096 at /home/gordon/sources/dancer2/lib/Dancer/Core/Request.pm line 554, <DATA> line 16. #### readlen = 11 at /home/gordon/sources/dancer2/lib/Dancer/Core/Request.pm line 559, <DATA> line 16. ##### before read at /home/gordon/sources/dancer2/lib/Dancer/Core/Request.pm line 563, <DATA> line 16. ###### input_handle = do { require Symbol; bless(Symbol::gensym(), "FileHandle"); } at /home/gordon/sources/dancer2/lib/Dancer/Core/Request.pm line 564, <DATA> line 16. ======== Because the "read" function never returns. Not sure if this is a problem in my setup or in dancer2, but it's reproducible every time. regards, -assaf.
Hello,
I can't reproduce that. Here is what I did:
$ curl -I -X POST http://0:3000/ HTTP/1.0 200 OK
The missing part is adding POST parameters, with the following command:
$ curl -I -X POST -d "hello=world" http://0:3000/
Very interesting debug infos, thanks a lot, I'm going to investigate further, but I'm suprised becasue this code comes from Dancer1 (actually, it even come from Plack::Request in the first place) so well it's theoritically trustable. Anyway, I'll investigate. Thanks.
On 09/30/2011 06:47 AM, sukria wrote:
Hi there,
I am very glad and proud to announce here that I've came up with a prototype of dancer2 that pleases me enough to be advertised.
-*- https://github.com/sukria/dancer2 -*-
dancer2 is a complete rewrite of Dancer aiming at providing the same awesomeness with the following major changes:
- no more globals in the core - 100% object-oriented backend (based on Moo) - better scoping for sub-applications - better design (no more encapsulation violations, Law of Demeter, ...)
The prototype I've pushed to GitHub currently covers ~80% of the DSL of Dancer. It's able to run simple applications (it can run the PerlDancer.org website for instance).
Of course, with your real-life applications, it will break in many places in this current shape, and this is where you can help. I'd like to have as many reports as possible regarding upgrades tests.
You can test very easily your app with dancer2:
$ git clone http://github.com/sukria/dancer2.git $ cd YOUR_APP $ perl -I../dancer2/lib bin/app.pl
Also, important to know: most of the plugins may not be working well.
How do I port a template engine to dancer2? Just implementing the context method? Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
2011/10/4 Stefan Hornburg (Racke) <racke@linuxia.de>:
On 09/30/2011 06:47 AM, sukria wrote:
How do I port a template engine to dancer2? Just implementing the context method?
You just have to consume the role Dancer::Core::Role::Template, and then, implement the render method. See Toolkit.pm, it's a good example of how to do it: https://github.com/sukria/dancer2/blob/master/lib/Dancer/Template/Toolkit.pm
On 10/04/2011 04:55 PM, Alexis Sukrieh wrote:
2011/10/4 Stefan Hornburg (Racke)<racke@linuxia.de>:
On 09/30/2011 06:47 AM, sukria wrote:
How do I port a template engine to dancer2? Just implementing the context method?
You just have to consume the role Dancer::Core::Role::Template, and then, implement the render method.
See Toolkit.pm, it's a good example of how to do it: https://github.com/sukria/dancer2/blob/master/lib/Dancer/Template/Toolkit.pm
OK, that was indeed fairly easy: https://github.com/racke/Template-Flute/commit/87c3a73b0f0c2a4c8cbeb750c42a5... Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
participants (14)
-
Alexis Sukrieh -
Assaf Gordon -
Brian E. Lozier -
Dave Doyle -
David Precious -
Michal Wojciechowski -
Mr. Puneet Kishor -
Naveed Massjouni -
Nick Knutov -
Richard Huxton -
sawyer x -
Stefan Hornburg (Racke) -
sukria -
thecrux@gmail.com