- dancer-users - lists.preshweb.co.uk

Incorrect attempts to serialize HTML
by Andrew Beverley 23 Nov '14

23 Nov '14

Hi guys, I apologise in advance that this is rather vague, but I'm hoping that someone might be able to point me in the right direction of where I should be looking. I'm getting some strange problems with Dancer2 and the "auto serializer". I have set serializer => 'JSON'; in my app, but under some circumstances it is trying to serialize HTML content, with the subsequent errors that you would expect of such an action. The problems seem to be related to my error handling (using Log::Report). My implementation is currently rather poor and complicated, so I won't go into the details here, but I wondered whether someone can point me to the relevant parts of the Dancer2 code that I should start poking around in (in particular the code which detects whether to serialize the data). I've looked at serialize() in Serializer::Mutuble, but as far as I can tell this function is not being called. Where else should I look? If I remove the aforementioned serializer statement then everything works as expected. Thanks, Andy

2 6

exceptional dancing
by WK 23 Nov '14

23 Nov '14

Hi! I have no real experience using exceptions in my code. Neither I have not seen good guide how to use exceptions in software developent. I have lot of small pieces about it, but no big picture. So I have simple question: how and where to catch errors in Dancer app? I looked to Dancer::Error and it seems good, but still I don't get, where is the best place to catch and handle errors? Is it good idea to have one simple dispatcher (like in bin/app.pl), so every exception is falling to the base script and handled there? Or is better to catch them in place all over the code? Or? Is there some "best practice"? -- Wbr, Kõike hääd, Gunnar

4 3

Advent Calendar
by Sawyer X 19 Nov '14

19 Nov '14

Hi everyone, We're beginning to work on the Advent Calendar for Dancer. We've collected a few ideas on the Dancer2 repo[1] and we're interested in having more ideas and more writers. Do you have additional ideas? Write us! Do you want to write about something? It's your time to shine! Let us know. Thanks, Sawyer.

1 1

New Dancer2 release: 0.154000
by Sawyer X 17 Nov '14

17 Nov '14

Hey everyone, We've just released a new Dancer2 version, approximately two weeks after the previous one. This version contains quite a few changes. In statistics: * Github issues resolved: 21 * Bugs resolved: 7 * Enhancements introduced: 12 * Documentation changes: 6 * Total changes introduced: 25 Big ones: * Serializers always serialize, no matter what. This is important! * Static files are finally served before routes and don't create a new route. This is huge! * Catching template rendering errors. Very crucial! * Should fix Windows testing errors. Sorry about that! * Named params can be freely mixed with splat and megasplat. Woohoo! * New testing manual! See: Dancer2::Manual::Testing. * You can disable "Server" tokens header. Finally! Thank you to everyone who worked on this release (in order of appearance): Sawyer X, Russell Jenkins, Steven Humphrey, Theo Van Hoesel, Mickey Nasriachi, Omar M. Othman, Dávid Kovács (DavsX), and Johan Spade. The entire changelog is available below: 0.154000 2014-11-17 15:36:31+01:00 Europe/Amsterdam [ BUG FIXES ] * GH #744: Serialize anything, not just references. (Sawyer X) * GH #744: Serialize regardless of content_type of serializer. (Sawyer X) * GH #764: Catch template render errors. (Russell Jenkins, Steven Humphrey) * Calling uri_for(undef) doesn't crash. (Sawyer X) * GH #732: Correct name for 403 (Forbidden, not Unauthorized). (Theo van Hoesel, Sawyer X, Mickey Nasriachi, Omar M. Othman) * GH #753: Syntax of parameterized types. (Russell Jenkins) * GH #734: Failing tests on Windows. (Russell Jenkins, Sawyer X) [ ENHANCEMENTS ] * GH #664, #684, #715: Handler::File replaced for static files with Plack::Middleware::Static, allowing files to be served *before* routes. This means hooks do not apply to static files anymore! (Russell Jenkins, DavsX) * Engines now have "logger" attribute to log errors. It sends the Dancer2::Logger:: object, if one exists. (Sawyer X) * Serializers do not need to implement "loaded" method. (Sawyer X) * GH #733: In core: response_xxx removed in favor of generic standard_response. (Sawyer X, Mickey Nasriachi, Omar M. Othman) * GH #514, #642, #729: Allow mixing named params, splat, and megasplat. (Russell Jenkins, Johan Spade, Dávid Kovács) * GH #596: no_server_tokens works, as well as DANCER_NO_SERVER_TOKENS. (Omar M. Othman, Sawyer X, Mickey Nasriachi) * GH #639: Validate engine types in configuration. (Sawyer X, Omar M. Othman, Mickey Nasriachi, Russell Jenkins) * GH #663, #741: Remove "accept_type" attribute and other references. (Mickey Nasriachi, Theo van Hoesel) * GH #748: Provide forwarded_host, forwarded_protocol. (Sawyer X) * GH #748: Do not provide a default env, require env for a request. (Sawyer X) * GH #742: Update test skeleton to use to_app. (Dávid Kovács) * GH #636: Use Plack::Test in more tests. (Dávid Kovács) [ DOCUMENTATION ] * GH #656: Dancer2::Manual::Testing as a guide for testing Dancer2 applications. (Sawyer X) * Improved documentation of route matching. (Russell Jenkins) * Migration document update relating to enhancements. (Sawyer X, Mickey Nasriachi) * GH #731: Document changes in session. (racke, Sawyer X, Mickey Nasriachi, Omar M. Othman) * Document "id" attribute in Request object. (Sawyer X) * Correct Cookbook examples on command line scripts. (Sawyer X)

1 0

Some questions about Logger and format_message in Dancer2
by Lennart Hengstmengel 12 Nov '14

12 Nov '14

Hi, I'm using Dancer2 in a RESTful JSON API. Works like a charm. Made everything so much easier! :) Now I needed to implement some logging, and I noticed that the documentation describes some placeholders that haven't been implemented yet, like %h (host emitting the request) and %{header}h (value of a request header). I really needed those two so I cloned the repo and implemented these myself, which was quite easy. I'll push the changes and create a pull request. But I have some questions: - According to the docs, the (not yet implemented) placeholder %i should give the "request id". I'm not sure what that should be? Some kind of session id or something? - lib/Dancer2/Core/Role/Logger.pm:74 : $level = sprintf( '%5s', $level ); Here $level is padded with spaces if it's shorter than 5 chars. So "info" gets an extra space. I'm not sure about the rationale, as "warning" has 7 chars so this line seems a bit pointless. (And the extra space before "info" makes my OCD play up ;)) - lib/Dancer2/Core/Role/Logger.pm:83 : return "[" . strftime( $block, localtime(time) ) . "]"; Why is the custom formatted time/date enclosed in brackets? Wouldn't it be better to do that in the log_format config directive if you wanted to? Obviously I'm hesitant to change the behaviour of these last two things as that may break stuff (like log parsers)... Thanks, Lennart

2 3

no request method
by Jean-Marc Choulet 02 Nov '14

02 Nov '14

Hello, Is it possible to create a no request method in Dancer2 module ? get qr{/(\d+)/members} => sub { my ($department) = splat; ... my $sth = database('foo')->prepare($queryString); ... # call my method doit(); my $data = doit()... } sub doit { # I want to retrieve some data from my database 'foo' return $data } Thanks, Jean-Marc

2 1

Dancer2 0.153000 on its way to CPAN
by Sawyer X 23 Oct '14

23 Oct '14

Hey everyone! Another Dancer2 release is upon us. Dancer2 version 0.153000 is uploading as we speak. The changelog is as follows: [ ENHANCEMENT ] * Internal: Move the implementation of send_file from DSL to App. (Russell Jenkins) [ BUG FIXES ] * GH #634, #687: Fix file logger defaults. (Russell Jenkins, Dávid Kovács, Sawyer X) * GH #730: Make App use app-level config for behind_proxy. (Sawyer X) * GH #727: Disable regex metachars when calculating app location in tests (Gregor Herrmann) * GH #681, #682, #712: Clear session engine within destroy_session. (DavX, Russell Jenkins) * Ignore :tests in importing, don't suggest :script. (Sawyer X) [ DOCUMENTATION ] * GH #728: Typos in Policy document. (Olaf Alders, Sawyer X) I want to thank everyone who was involved in this release (in no particular order): Russell Jenkins, Dávid Kovács, Gregor Herrmann, DavX, Olaf Alders, and Sawyer X. Enjoy!

1 0

Example of pagination with DBIC?
by John Stoffel 22 Oct '14

22 Oct '14

Hi all, My google-fu is weak and I haven't been able to find a good example of how to do pagination with Dancer, DBIC and ideally some basic Javascript to make it look good. Here's my basic code that I'm working with right now, which I know is semi busted, but I just keep hitting roadblocks. The goal here is to let me spin up quick, but nice search forms for read only mysql DBs for a library I work with in my spare time. Ideally a CRUD interface down the line to allow end users to add/edit records. DBIC looks to be the way to go with this down the line, since it can do proper records and transactions. At least I think it can. Any way, my code: package TestDBIC; use Dancer ':syntax'; use Dancer::Plugin::DBIC qw(schema resultset rset); # cd TestDBIC; # TestDBIC::Schema 'dbi:mysql:dbname=emina;host=quad' emina our $VERSION = '0.1'; get '/' => sub { template 'search'; }; post '/results' => sub { my $name = param 'Name'; my $sex = param 'Sex'; my $city = param 'City'; my $state = param 'State'; my $id = param 'MummyID'; my @rows; my $query; my $q = {}; my $limit = 10; my $opts = {}; $opts->{order_by} = { -desc => 'id' }; $opts->{rows} = $limit if defined $limit; # We need to join in several tables from the schema $opts->{page} = 1; $opts->{limit} = 15; $opts->{order_by} = { 'desc' => 'name'}; my $rs = schema->resultset('MummyInNorthAmerica'); if ($name) { if ($query) { $query .= " AND "; } $query .= "Name LIKE $name"; $q->{name} = { like => "%$name%" } ; } if ($sex) { if ($query) { $query .= " AND "; } $query .= "Sex = $sex"; $q->{sex} = $sex; } @rows = $rs->search($q,$opts)->pager; template 'results', { query => $query, mummies => \@rows, rows => 1000 }; }; true;

3 10

Dancer2 Release Cycles and Feature/Bugfix Release Planning
by burnersk 21 Oct '14

21 Oct '14

Hi Sawyer, here is my draft of the introduction email... --- DRAFT --- Hi folks. I was wondering recently when the feature X or the bug Y will be fixed. So I try to look up it in the GitHub Milestones[1]. I saw that milestones was used but starting from 0.14100 there was no progress at all with milestones (progress with issues itself was made of course). For me as a developer milestones are nice because I can see what is on the schedule for the next release. From the user point I can see when my beloved feature X or hated bug Y is going to be fixed. I think GitHub Milestones are a great way to communicate to developers and users at the same time. So I asked on #dancer if there where any plans to proceed with release planning based on GitHub Milestones. It turns out that the intention was there but time was missing to organize. Sawyer asked me to attend to help with release planning. I'm not sure that this is true but I had in mind, that the Dancer2 release cycle supposed to be 2 weeks. So that every second week there will be a new release with new great features and fixed bugs. I'd like to check with all of you folks, developers or users, if you want this or not. Please discuss this idea. I can imagine the following "process". Basic environment: * develop period: 12 days (freeze on day 13 and 14, release on day 14) * develop time per developer: 1 hour / day (5 days a week, 10 hours a period) * developers: 8 core developer (some may not work "all the time" but we have other contributors) * total work hours per period: 80 hours Milestone calculation (break on first match, it's just a guideline - not a strict rule): * estimate severity and popularity * very_next_release means the very next release even if it's barely possible (no left *planed* development time) * next_possible_release means the next possible release according on the development time left for the milestone * next_but_one_possible_release means the possible release(ses) after next_possible_release according on the development time left for the milestone 1. for severity in (Blocker, Critical) set milestone to very_next_release 2. for type in (Bug) and severity in (Major) and popularity in (High) set milestone to very_next_release 3. for severity in (Medium) and popularity in (High) and complexity in (Easy) set milestone to next_possible_release 4. for severity in (Medium) and popularity in (High) and complexity in (Moderate) set milestone to next_possible_release 5. for severity in (Medium) and popularity in (High) and complexity in (Hard) set milestone to next_but_one_possible_release 6. for others set milestone to next_but_one_possible_release I'd soft estimate the severity and popularity, check back with the core developers and finally assign the milestone. Furthermore I'll (or a small team will) set severity, popularity and complexity initially when they are checked by the core team. According to the release cycle the milestone due dates will be set. Issues which are not become final within the desired milestone will be moved to the next milestone. Due to this circumstance there will be reserve of 10 working hours within every milestone for those delayed issues. The affected issues will be flagged as delayed. What do you think about all of it? [1] https://github.com/PerlDancer/Dancer2/milestones -- Cheers, burnersk

2 2

Dancer2::Manual::Migration
by Sawyer X 20 Oct '14

20 Oct '14

Hi all, as I mentioned in the release email, Dancer2 now has a migration document for users coming from Dancer, Dancer2::Manual::Migration <https://metacpan.org/pod/distribution/Dancer2/lib/Dancer2/Manual/Migration.…> [1]. This is a living document describing the few differences between Dancer and Dancer2, and is meant to help you convert your applications and adjust your way of doing things to fit Dancer2. You can help! If you see something wrong, if you think something could be described better, if you wish to add anything that is missing, please let us know. Either send a pull request, a Github issue, an RT ticket, or just shoot us an email - to the list or to one of the core devs personally. Whatever you prefer. The migration document has been assembled and written by an OPW (Outreach Program for Women) applicant, Snigdha Dagar. I want to thank her for her work (which is not done yet!) and to all those who reported and helped collect all the various issues that are mentioned in the migration document. Good job! Dance away, Sawyer. [1] https://metacpan.org/pod/distribution/Dancer2/lib/Dancer2/Manual/Migration.…

5 4