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

Just DBIC, not a plugin
by Henk van Oers 18 Feb '15

18 Feb '15

On Wed, 18 Feb 2015, Henk van Oers wrote: > I would like a Dancer::Unified::Config > used by D1 and D2, to keep it DRY. And than use it in Dancer::DBIC All the shemata you want in whatever framework. -- Henk

1 0

Dancer2::Session::DBIC
by Brendon Oliver 17 Feb '15

17 Feb '15

Hi all, Just messing with this module and discovered that it ignores the data_column value given in the settings. In _retrieve() - circa line 191: my $session_data = $session_object->session_data; needs to be something like: my $data_column = $self->data_column(); my $session_data = $session_object->$data_column(); Curious too: why doesn't this module use Dancer2::Plugin::DBIC ? I'm already using DBIC elsewhere in my application and it seems silly / redundant to me to have to define the connect string in two different places in the config. Seems to me it'd be far simpler to just have the config nominate which DBIC 'schema' connection to use and simply fall back to 'default' if none is provided. (as an aside, I'm also working on a DBIC provider for D2::Plugin::Auth::Extensible for the same reason - to reuse the existing DBIC config, but retaining the user-definable table structures as per the Database provider). cheers, - Brendon

5 11

What to do with 'add_hook'
by Henk van Oers 16 Feb '15

16 Feb '15

While working on https://github.com/hvoers/Dancer-Plugin2 I found 'add_hook'. Searching for that keyword gave me: Dancer/Plugin.pm 21: add_hook 35:sub add_hook { Dancer::Hook->new(@_) } Dancer/Plugin/Lexicon.pm 40:add_hook before => sub { 67:add_hook before_template => sub { Mmmm, no pod... In Dancer2: Dancer2/Core/App.pm 457:# add_hook will add the hook to the first "hook candidate" it finds that support 459:around add_hook => sub { 465: my $add_hook_caller = [ $package, $file, $line ]; 491: $hookable->has_hook($name) and $hookable->add_hook(@_); 506: $add_hook_caller; 556: $self->add_hook( Dancer2/Core/DSL.pm 155: $self->app->add_hook( Dancer2/Core/Role/Hookable.pm 82: $self->add_hook($hook); 95:sub add_hook { Dancer2/Plugin.pm 322: $dsl->app->add_hook( Mmmm, that last line is in a pod section... In D1 we also have Dancer::App Should the implementation of 'add_hook' move from Dancer/Plugin.pm to Dancer::App ? And where is the pod? -- Henk

1 0

Plack builder error
by mark jones 11 Feb '15

11 Feb '15

Hi all, I'm pretty new to Dancer and I'm trying to put together a quick demo with Plack::Builder and multiple apps. I've created 2 apps in separate directories - app1 and app2, and in a directory above I've got app.psgi with the following code: use Dancer2 ':syntax'; use Plack::Builder; use lib '/home/mj/app1/lib'; use lib '/home/mj/app2/lib'; use app1; use app2; setting apphandler => 'PSGI'; my $app1 = sub { my $env = shift; local $ENV{DANCER_APPDIR} = '/home/mj/app1'; load_app "app1"; Dancer2::App->set_running_app('app1'); setting appdir => '/home/mj/app1'; Dancer2::Config->load; my $request = Dancer2::Request->new( env => $env ); Dancer2->dance($request); }; my $app2 = sub { my $env = shift; local $ENV{DANCER_APPDIR} = '/home/mj/app2'; load_app "app2"; Dancer2::App->set_running_app('app2'); setting appdir => '/home/mj/app2'; Dancer2::Config->load; my $request = Dancer2::Request->new( env => $env ); Dancer2->dance($request); }; builder { mount "/app1" => builder {$app1}; mount "/app2" => builder {$app2}; }; Following the tutorial here: http://search.cpan.org/~sukria/Dancer2-0.05/lib/Dancer2/Deployment.pod#Runn…. I keep getting this error: String found where operator expected at /home/mj/app.psgi line 16, near "load_app "app1"" (Do you need to predeclare load_app?) It's probably something really simple but can anyone see what's wrong? Cheers

2 2

Dancer::Plugin2
by Henk van Oers 09 Feb '15

09 Feb '15

What does plugin_args do when you D*::Plugin ? In Dancer::Plugin sub plugin_args { (undef, @_) } In Dancer2::Plugin sub plugin_args {@_} What if there is a module Dancer::Plugin2 (or Dancer2::Plugin2) that detects the Dancer version and in the D1 case constructs a real $dsl object? Can this help to write D1 plugins the D2 way? And then make DRY plugins under this new namespace? -- Henk

3 4

Snigdha Dagar's (our OPW participant) work has been merged!
by Sawyer X 08 Feb '15

08 Feb '15

Hi everyone, I had a few conferences, lots of work, and then, of course, I was under the weather, so not much was heard from me in a while. Consider yourselves lucky. :) However, having regained enough composure to finally merge the massive PR Snigdha Dagar has submitted as part of her work on overhauling the documentation, I'd like to share it with you, because it's too cool to keep to myself. First, you can view the entire thing here: https://github.com/PerlDancer/Dancer2/commit/6eaa6a8136ad26c76a40c3aef49d86… But you probably don't want to. Why? Here's the summary: 6 files changed, 2659 insertions(+), 1236 deletions(-). Why? Well... let me tell you what she did. She completely restructured the Manual and Cookbook. This included deciding what should go where, make it reachable from Dancer2.pm (what's rendered when you open up Dancer2 in MetaCPAN or perldoc), and structure it within those documents in a coherent manner. The Manual now covers: * Installation * Bootstrapping * How to use Dancer2, including: - The HTTP methods (including multi-methods) - All route definitions - Prefixes - Hooks - Handlers - Errors - Sessions - Templates - Static files - File uploads - Configuration - Logging * How to test Dancer2 * How to package Dancer2, currently covering: - Carton - FatPacker (but more will be added) * How to add middlewares * Plugins And of course, * DSL keyword index The Manual is now a proper Manual, explaining how Dancer should be used, which we could continue to expand so it covers explanations on any and all keywords as part of a guide you can read. You will still have the DSL keywords (which many of us jump for when we want to find a keyword quickly) as well, which we will slowly be using to point to the parts in the Manual which cover the keyword's usage. The Cookbook now covers tricks and hints: * Splitting your application with prefix * Using auto_page (AutoPage itself covered in the Manual - here is only a tip to use it) * Delivering custom error pages * Using DBIx::Class * Authentication * Example for a REST application * Recommendations on serializers * Turning off warnings (under "Non-standard" :) * etc. If there's a tip you give others, or a pattern you found useful, this is where you could submit it so others could enjoy. It would fall under "cool stuff", rather than "the design of the framework". One describes the pieces and how they interact. The other all the cool stuff you could do with them. The Deployment document (which existed in 1 and was merged into the Cookbook at 2 - not the right thing) is now its own separate document, includes everything in Dancer 1 and adds more: * Running as CGI or FastCGI * Running on Perl web servers * Using different service utilities (daemontools, Ubic, etc.) * Under a reverse proxy * From Apache or Lighttpd This is where we gather the knowledge of everyone deploying Dancer2 in various environments to make sure we have clear and useful instructions for the next person who wants to follow the same deployment pattern, and to offer examples of how you could deploy your Dancer2 applications. The main module, Dancer2, now links to all of these so they are easily accessible. The DSL keyword index, since it is useful, is linked separately of the Manual, so we could find it much more quickly. This is something that nagged me personally. I never remembered *where* it was documented, and now, even though it's the proper place, I don't have to remember. Perldoc Dancer2 and it's there. I'd like to thank Snigdha for all the work she's done on this. It was not easy and included a lot of research before she could even begin reading the Dancer documents, comparing the changes between 1 and 2, making decisions about the structure, and moving everything inch by inch. (There actually were a lot of commits, but I did squashed some commits together.) Have a great day, S.

6 5

Application specific configuration options
by Gabor Szabo 08 Feb '15

08 Feb '15

Hi, In https://metacpan.org/pod/Dancer2::Config I see plugins should have their configuration in plugins: plugin-name: key: value but I have not found any suggestion where should one put the application-specific configuration options. Is there a recommended, or required hierarchy for those configuration values? Maybe: applications: "App::Name": key: "value" Oh an I think it would be also good, to add an example to that pod, showing how to fetch configuration values: config->{appdir} config->{plugins}{DBIC}{default}{dsn}; and config->{applications}{'App::Name'}{key} regards Gabor

2 1

Dancer2 - Getting Started - 20 min screencast
by Gabor Szabo 08 Feb '15

08 Feb '15

https://www.youtube.com/watch?v=O7dO3K-krrg by http://dj.id.au/ Gabor

1 0

Should get '/projects/' => also handle /projects redirecting to /projects/
by Gabor Szabo 04 Feb '15

04 Feb '15

I am learning Flask, microframework in Python similar to Dancer. In flask if you define a route to something with a trailing slash like get '/projects/' => sub {} It will automatically insert a route for get '/projects' => sub { redirect '/projects/' } See Unique URLs / Redirection Behavior http://flask.pocoo.org/docs/0.10/quickstart/ Then if you manually try to add the slash-less route, Flask blows up. I wonder if Dancer2 should have similar behavior, without the blowing up part? Gabor

3 3