Major Dancer 2 release: 0.140000
Hey everyone! I just released a new version of Dancer 2. It's a major one. I'd like to share a bit about it. *Semver:* First of all, you probably noticed a completely different release version. Previous ones were 0.12, 0.13, which is why it would make sense for this one to be 0.14. In fact, it is! We've decided to use a convention called Semver[1]. It allows us to indicate to you, the users and developers, what changes we've done. *Changelog:* Additionally, if you check the Changes file, you will see a few more interesting gems. We only have features in this release, there are four changes which were introduced by the same three people (Stefan Hornburg, Mickey Nasriachi, and myself - Sawyer X). *Hackathon:* The reason for many of these changes were a Dancer 2 core hackathon that was conducted at Booking.com's HQ with the aforementioned three core devs last Thursday, a day before the Dutch Perl Workshop. We have worked hard on cleaning up several things that bugged us for a while. Allow me to fill you in on those: *Deliverables:** Replace Config role with better ConfigReader role. * Move App-related attributes (engines) to App instead of config role. Dancer2::Core::Role::Config has been a sore point for a long while. It was pushing attributes to unrelated classes, contained triggers which caused us several attempts to untangle, and was something we wanted to clean up. The new ConfigReader just reads a configuration, allows local and global triggers, and the necessary attributes went into the appropriate class. Yay! * Untangle Runner-Server (removing Server entirely). Dancer2 had a setup of Server handlers (under the ::Server class name), one for PSGI app handling, and the other for a standalone server. The idea was: you call "dance()" (or "start()") and Dancer will either return a PSGI coderef (which goes to Plack) or start a local development web server. Thus we had ::Server::PSGI and ::Server::Standalone. While this makes total sense, it doesn't make any sense at all. First of all, the standalone server is, in fact, a PSGI server. The PSGI server handler (::Server::PSGI) was not a server, but a coderef. Secondly, the standalone server would still need the PSGI coderef. Confused? Good. Now you understand why we wanted to remove it. What we did was keep the Runner class, have it hold a "server" attribute, which will be lazily evaluated to a PSGI development standalone server. If you will need a standalone server run, it will build it, and call it with a PSGI coderef. There is now no ::Server handler classes. That entire layer has been removed. * Replace HTTP::Server::Simple::PSGI with HTTP::Server::PSGI. Since Plack comes with HTTP::Server::PSGI, we could remove a dependency, while replacing it with a much better module. It is more maintained, doesn't require (monkey-)patching (which we introduced in HTTP::Server::Simple::PSGI) and already does all we need. There is now also no ability to daemonize the development server within Dancer2 since 1. Plack already allows it via command line, and 2. you should not be running the development server in the background. If you do, please consider changing it. *Non-hackathon changes:* Cookie building improvements and using Plack::Middleware::Head to serve the head (instead of an ugly around() method), both by Russell Jenkins, and supporting deserializing from DELETE methods as well, done by Russell, Yanick Champoux, and Sawyer. *Thanks:* Major thanks goes to all people mentioned in the changelog in this release: Mickey Nasriachi, Stefan Hornburg, Russell Jenkins, Yanick Champoux, and Sawyer X. Another major thanks goes to our fantastic community. Thank you for the feedback, support, and help! Please try out this new version and update us on any issue you may find! [1] Semantic Versioning: semver.org.
Il giorno Mon, 28 Apr 2014 23:58:03 +0200 sawyer x <xsawyerx@gmail.com> ha scritto:
Hey everyone!
I just released a new version of Dancer 2. It's a major one. I'd like to share a bit about it.
Hi, I tried Dancer2 0.140000 with a site that was perfectly working with Dancer2 0.13. Login seems to be now broken, at least using the development server. I noticed, using YAML as session manager, that a new session is created for every request, despite they come from the same client. Session is correctly written by my code but obviosly ignored because a new one is used to evaluate the next request. How can i solve this? -- Cymon Coniglio domina, http://perlishscrewdriver.blogspot.com
On Wed, Apr 30, 2014 at 12:35 AM, Cymon <cymon.ML@gmail.com> wrote:
Il giorno Mon, 28 Apr 2014 23:58:03 +0200 sawyer x <xsawyerx@gmail.com> ha scritto:
Hey everyone!
I just released a new version of Dancer 2. It's a major one. I'd like to share a bit about it.
Hi,
Hey Cymon!
I tried Dancer2 0.140000 with a site that was perfectly working with Dancer2 0.13.
Thanks for trying it out so early.
Login seems to be now broken, at least using the development server. I noticed, using YAML as session manager, that a new session is created for every request, despite they come from the same client. Session is correctly written by my code but obviosly ignored because a new one is used to evaluate the next request.
We haven't touched the session code, but this might be fallout from the transition to the new ConfigReader role, which effectively decoupled local configurations from global ones. It caches the objects (exactly as before - in fact, almost everything is literally the same code) so I don't see how this would be a problem. Either way, I'd like to get this resolved ASAP.
How can i solve this?
Is it possible to provide a small test case? I'll try to write my own as well. In the future, we will be sure to first release a development version.
I tried Dancer2 0.140000 with a site that was perfectly working with Dancer2 0.13.
Thanks for trying it out so early.
Well, a bit of luck... I decided to start a new site and I created a fresh new environment. I'm obviously also interested in seeing how latest release of Dancer2 works with my Strehler package :-)
We haven't touched the session code, but this might be fallout from the transition to the new ConfigReader role, which effectively decoupled local configurations from global ones. It caches the objects (exactly as before - in fact, almost everything is literally the same code) so I don't see how this would be a problem.
Either way, I'd like to get this resolved ASAP.
Probably I found... In Dancer2::Core::Request cookies are generated from cookie header in this foreach foreach my $cookie ( $self->header('COOKIE') ) but $self->header('COOKIE') is just a string, not something useful for iterating... Adding a split seems to do the trick... foreach my $cookie ( split " ", $self->header('COOKIE') ) {
In the future, we will be sure to first release a development version.
No problem, i'll be an early adopter in any case :-P -- Cymon Coniglio domina, http://perlishscrewdriver.blogspot.com
On 1/05/2014 6:23 am, Cymon wrote:
We haven't touched the session code, but this might be fallout from the transition to the new ConfigReader role, which effectively decoupled local configurations from global ones. It caches the objects (exactly as before - in fact, almost everything is literally the same code) so I don't see how this would be a problem. Either way, I'd like to get this resolved ASAP. Probably I found... In Dancer2::Core::Request cookies are generated from cookie header in this foreach foreach my $cookie ( $self->header('COOKIE') ) but $self->header('COOKIE') is just a string, not something useful for iterating... Adding a split seems to do the trick... foreach my $cookie ( split " ", $self->header('COOKIE') ) {
In the future, we will be sure to first release a development version. No problem, i'll be an early adopter in any case :-P There was a small change to how requests generate cookie objects to improve adding cookie headers when using Dancer2::Test (please use Plack::Test instead!).
Looks like this was my fault; misread the HTTP::Headers docs and erroneously removed the split that was there previously. Sorry! There is a Pr with a fix for this (#580). Cheers, Russell.
And a new version was released. :) Thank you, Cymon and Russell! On Thu, May 1, 2014 at 4:25 AM, Russell Jenkins < russell.jenkins@strategicdata.com.au> wrote:
On 1/05/2014 6:23 am, Cymon wrote:
We haven't touched the session code, but this might be fallout from the transition to the new ConfigReader role, which effectively decoupled local configurations from global ones. It caches the objects (exactly as before - in fact, almost everything is literally the same code) so I don't see how this would be a problem. Either way, I'd like to get this resolved ASAP. Probably I found... In Dancer2::Core::Request cookies are generated from cookie header in this foreach foreach my $cookie ( $self->header('COOKIE') ) but $self->header('COOKIE') is just a string, not something useful for iterating... Adding a split seems to do the trick... foreach my $cookie ( split " ", $self->header('COOKIE') ) {
In the future, we will be sure to first release a development version.
No problem, i'll be an early adopter in any case :-P
There was a small change to how requests generate cookie objects to improve adding cookie headers when using Dancer2::Test (please use Plack::Test instead!).
Looks like this was my fault; misread the HTTP::Headers docs and erroneously removed the split that was there previously. Sorry! There is a Pr with a fix for this (#580).
Cheers, Russell.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Il giorno Thu, 1 May 2014 10:51:01 +0200 sawyer x <xsawyerx@gmail.com> ha scritto:
And a new version was released. :)
Thank you, Cymon and Russell!
Thank you! Now all looks like working well. At least all those zeros after the version are not gone wasted ;-)
On Thu, May 1, 2014 at 4:25 AM, Russell Jenkins < russell.jenkins@strategicdata.com.au> wrote:
On 1/05/2014 6:23 am, Cymon wrote:
We haven't touched the session code, but this might be fallout from the transition to the new ConfigReader role, which effectively decoupled local configurations from global ones. It caches the objects (exactly as before - in fact, almost everything is literally the same code) so I don't see how this would be a problem. Either way, I'd like to get this resolved ASAP. Probably I found... In Dancer2::Core::Request cookies are generated from cookie header in this foreach foreach my $cookie ( $self->header('COOKIE') ) but $self->header('COOKIE') is just a string, not something useful for iterating... Adding a split seems to do the trick... foreach my $cookie ( split " ", $self->header('COOKIE') ) {
In the future, we will be sure to first release a development version.
No problem, i'll be an early adopter in any case :-P
There was a small change to how requests generate cookie objects to improve adding cookie headers when using Dancer2::Test (please use Plack::Test instead!).
Looks like this was my fault; misread the HTTP::Headers docs and erroneously removed the split that was there previously. Sorry! There is a Pr with a fix for this (#580).
Cheers, Russell.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Cymon Coniglio domina, http://perlishscrewdriver.blogspot.com
participants (3)
-
Cymon -
Russell Jenkins -
sawyer x