Call to all Dancer2 plugin writers
Hi all, Underneath the surface, I've been toiling away at a new plugin system for Dancer2. This new system aims at fixing a few of the thorny issues of the current one, and add a wee bit of unicorn dust to the mix. ## For plugin users, the changes are: * No change! The new plugins will be called the same way as the old ones -- it'll be transparent to you if a plugin is new gen or old gen. Isn't that music to your ears, or what? :-) * No change! Plugins using the new system can work side-by-side with original plugins. It's all really transparent to you. Relax, we're taking care of everything. :-) ## For plugin writers, the changes are: * The new system inherit from Dancer2::Plugin2 (yes, I know, we just loooove that '2' digit around here...). * The new system is much more OO-based, which so far makes for cleaner, easier to write plugins. * The new system doesn't export the Dancer keywords into the plugin namespace. It removes a little bit of the sugar (you'll have to do `$self->app->request` instead of `request()` inside the plugin module), but it makes much more explicit what is the plugin class, and what is the plugin instance associated with an app. * Plugin can now use other plugins! * The list of plugin instances are also kept as an attribute in the app object, which makes introspection possible (a plugin, for example, can check if other plugin A is already loaded or not and do things in consequence). ## What do I want from you? Before unleashing D2::P2, it needs to be tested. Racke already migrated two of his plugins to D2::P2 (https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2). I would like for all of you to try to migrate your plugins, and report if it was a success, or if you uncovered some sore points. How to do that? I'm glad you asked: 1. clone and use the Dancer2 branch at https://github.com/yanick/Dancer2/tree/plugins-yanick 2. read the D2::P2 docs (`perldoc lib/Dancer2/Plugin2`) 3. if docs are not sufficient, check examples (`/t/plugins2-*`) and the already-ported modules at bullet #5 below. 4. report all problems, head-scratchers, suggestions, etc to https://github.com/PerlDancer/Dancer2/pull/1010#issuecomment-147376270 5. you ported the plugin and all works? Post your victory to the PR dicussion at #4, and add your plugin to the list at https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2 (that's important, I'll set up a job to test any new tweaks on D2::P2 to all the converted modules) And, of course, you have questions or anything, please feel free to hit me with'em. Joy, `/anick
On 10/12/2015 05:05 PM, Yanick Champoux wrote:
Hi all,
Underneath the surface, I've been toiling away at a new plugin system for Dancer2. This new system aims at fixing a few of the thorny issues of the current one, and add a wee bit of unicorn dust to the mix.
## For plugin users, the changes are:
* No change! The new plugins will be called the same way as the old ones -- it'll be transparent to you if a plugin is new gen or old gen. Isn't that music to your ears, or what? :-)
* No change! Plugins using the new system can work side-by-side with original plugins. It's all really transparent to you. Relax, we're taking care of everything. :-)
## For plugin writers, the changes are:
* The new system inherit from Dancer2::Plugin2 (yes, I know, we just loooove that '2' digit around here...).
* The new system is much more OO-based, which so far makes for cleaner, easier to write plugins.
* The new system doesn't export the Dancer keywords into the plugin namespace. It removes a little bit of the sugar (you'll have to do `$self->app->request` instead of `request()` inside the plugin module), but it makes much more explicit what is the plugin class, and what is the plugin instance associated with an app.
* Plugin can now use other plugins!
* The list of plugin instances are also kept as an attribute in the app object, which makes introspection possible (a plugin, for example, can check if other plugin A is already loaded or not and do things in consequence).
## What do I want from you?
Before unleashing D2::P2, it needs to be tested. Racke already migrated two of his plugins to D2::P2 (https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2). I would like for all of you to try to migrate your plugins, and report if it was a success, or if you uncovered some sore points.
How to do that? I'm glad you asked:
1. clone and use the Dancer2 branch at https://github.com/yanick/Dancer2/tree/plugins-yanick
2. read the D2::P2 docs (`perldoc lib/Dancer2/Plugin2`)
3. if docs are not sufficient, check examples (`/t/plugins2-*`) and the already-ported modules at bullet #5 below.
4. report all problems, head-scratchers, suggestions, etc to https://github.com/PerlDancer/Dancer2/pull/1010#issuecomment-147376270
5. you ported the plugin and all works? Post your victory to the PR dicussion at #4, and add your plugin to the list at https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2 (that's important, I'll set up a job to test any new tweaks on D2::P2 to all the converted modules)
And, of course, you have questions or anything, please feel free to hit me with'em.
A few remarks: 1. Dancer2::Plugin::DBIC is actually ironcamel's module. 2. Plugins based on Plugin2 can not use plugins based on Plugin(1). 3. Tests are going to be rewritten, now we need an app object. I would be good to fake that so we can test plugin calls from the outside of the routes. Regards Racke -- Perl and Dancer Development Visit our Perl::Dancer conference 2015. More information on https://www.perl.dance.
Hi!!! This plugin2 looks great!. It solves execution problems of Dancer2::Plugin. I have a question about the add_route functionality, how can I access to the DSL keywords? eg. param('param_name') when I'm defining the code for a new route? Ruben. On Tue, Oct 13, 2015 at 3:19 AM, Stefan Hornburg (Racke) <racke@linuxia.de> wrote:
On 10/12/2015 05:05 PM, Yanick Champoux wrote:
Hi all,
Underneath the surface, I've been toiling away at a new plugin system for Dancer2. This new system aims at fixing a few of the thorny issues of the current one, and add a wee bit of unicorn dust to the mix.
## For plugin users, the changes are:
* No change! The new plugins will be called the same way as the old ones -- it'll be transparent to you if a plugin is new gen or old gen. Isn't that music to your ears, or what? :-)
* No change! Plugins using the new system can work side-by-side with original plugins. It's all really transparent to you. Relax, we're taking care of everything. :-)
## For plugin writers, the changes are:
* The new system inherit from Dancer2::Plugin2 (yes, I know, we just loooove that '2' digit around here...).
* The new system is much more OO-based, which so far makes for cleaner, easier to write plugins.
* The new system doesn't export the Dancer keywords into the plugin namespace. It removes a little bit of the sugar (you'll have to do `$self->app->request` instead of `request()` inside the plugin module), but it makes much more explicit what is the plugin class, and what is the plugin instance associated with an app.
* Plugin can now use other plugins!
* The list of plugin instances are also kept as an attribute in the app object, which makes introspection possible (a plugin, for example, can check if other plugin A is already loaded or not and do things in consequence).
## What do I want from you?
Before unleashing D2::P2, it needs to be tested. Racke already migrated two of his plugins to D2::P2 (https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2). I would like for all of you to try to migrate your plugins, and report if it was a success, or if you uncovered some sore points.
How to do that? I'm glad you asked:
1. clone and use the Dancer2 branch at https://github.com/yanick/Dancer2/tree/plugins-yanick
2. read the D2::P2 docs (`perldoc lib/Dancer2/Plugin2`)
3. if docs are not sufficient, check examples (`/t/plugins2-*`) and the already-ported modules at bullet #5 below.
4. report all problems, head-scratchers, suggestions, etc to
https://github.com/PerlDancer/Dancer2/pull/1010#issuecomment-147376270
5. you ported the plugin and all works? Post your victory to the PR dicussion at #4, and add your plugin to the list at
https://github.com/PerlDancer/Dancer2/wiki/Plugins-migrated-to-D2::P2
(that's important, I'll set up a job to test any new tweaks on D2::P2 to all the converted modules)
And, of course, you have questions or anything, please feel free to hit me with'em.
A few remarks:
1. Dancer2::Plugin::DBIC is actually ironcamel's module.
2. Plugins based on Plugin2 can not use plugins based on Plugin(1).
3. Tests are going to be rewritten, now we need an app object. I would be good to fake that so we can test plugin calls from the outside of the routes.
Regards Racke
-- Perl and Dancer Development
Visit our Perl::Dancer conference 2015. More information on https://www.perl.dance.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- ____________________________ Rubén Darío Amórtegui Medina MCE - Ingeniero de Sistemas
On 10/14/2015 04:33 PM, Rubén Amórtegui wrote:
Hi!!!
This plugin2 looks great!. It solves execution problems of Dancer2::Plugin.
I have a question about the add_route functionality, how can I access to the DSL keywords? eg. param('param_name') when I'm defining the code for a new route?
Ruben.
The first parameter for the route sub is an $app object, so you can do for example: $app->request->params Regards Racke -- Perl and Dancer Development Visit our Perl::Dancer conference 2015. More information on https://www.perl.dance.
On 2015-10-14 10:38 AM, Stefan Hornburg (Racke) wrote:
I have a question about the add_route functionality, how can I access to the DSL keywords? eg. param('param_name') when I'm defining the code for a new route?
The first parameter for the route sub is an $app object, so you can do for example:
Yup. The 'app' object is the way to go. As Racke mentioned, it's passed to the coderef, and it's also available as an attribute of the plugin object: sub BUILD { my $plugin = shift; $plugin->app->add_route( method => 'get', regexp => '/goodbye', code => sub { 'farewell ' . $plugin->app->request->params->{name}; # or my $app = shift; 'farewell ' . $app->request->params->{name}; }, ); } `/.
Thanks racke and Yanick, it works as expected. :) On Wed, Oct 14, 2015 at 9:21 AM, Yanick Champoux <yanick@babyl.dyndns.org> wrote:
On 2015-10-14 10:38 AM, Stefan Hornburg (Racke) wrote:
I have a question about the add_route functionality, how can I access to the DSL keywords? eg. param('param_name') when I'm defining the code for a new route?
The first parameter for the route sub is an $app object, so you can do for example:
Yup. The 'app' object is the way to go. As Racke mentioned, it's passed to the coderef, and it's also available as an attribute of the plugin object:
sub BUILD { my $plugin = shift;
$plugin->app->add_route( method => 'get', regexp => '/goodbye', code => sub { 'farewell ' . $plugin->app->request->params->{name}; # or my $app = shift; 'farewell ' . $app->request->params->{name}; }, );
}
`/.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- ____________________________ Rubén Darío Amórtegui Medina MCE - Ingeniero de Sistemas
On 10/14/2015 05:21 PM, Yanick Champoux wrote:
On 2015-10-14 10:38 AM, Stefan Hornburg (Racke) wrote:
I have a question about the add_route functionality, how can I access to the DSL keywords? eg. param('param_name') when I'm defining the code for a new route?
The first parameter for the route sub is an $app object, so you can do for example:
Yup. The 'app' object is the way to go. As Racke mentioned, it's passed to the coderef, and it's also available as an attribute of the plugin object:
sub BUILD { my $plugin = shift;
$plugin->app->add_route( method => 'get', regexp => '/goodbye', code => sub { 'farewell ' . $plugin->app->request->params->{name}; # or my $app = shift; 'farewell ' . $app->request->params->{name}; }, );
}
`/.
Yanick, would you mind to enhance the POD with this example? The second variant is more straight forward in my opinion (getting $app from subroute parameters instead of using closure variable). Regards Racke -- Perl and Dancer Development Visit our Perl::Dancer conference 2015. More information on https://www.perl.dance.
On 2015-10-14 01:49 PM, Stefan Hornburg (Racke) wrote:
Yanick, would you mind to enhance the POD with this example?
Done. And sometime tomorrow (ie, as soon as I merge my changes), defining plugin keywords will get even easier: # the classic plugin_keywords 'foo', [ 'bar', 'baz' ], quux => sub { ... }; # tag methods as keywords sub some_keyword :PluginKeyword { ...; } # keyword will be 'bar' sub foo :PluginKeyword(bar) { ... } # keywords "do_it" and "do_them" will both use the method sub do_studd :PluginKeyword(do_it do_them) { ... } # attributes can be exported as keywords too has foo => ( is => 'ro', plugin_keyword => 1, # will use keyword 'foo' ); has bar => ( is => 'ro', plugin_keyword => 'baz', # will use keyword 'baz' ); has quux => ( is => 'ro', plugin_keyword => [qw/ this that / ], # will use keyword 'this' and 'that' ); Joy, `/.
Great! One more question, Is there a way to acces to "to_json" and "from_json" on the plugin? Thanks! Ruben. On Wed, Oct 14, 2015 at 2:19 PM, Yanick Champoux <yanick@babyl.dyndns.org> wrote:
On 2015-10-14 01:49 PM, Stefan Hornburg (Racke) wrote:
Yanick, would you mind to enhance the POD with this example?
Done.
And sometime tomorrow (ie, as soon as I merge my changes), defining plugin keywords will get even easier:
# the classic plugin_keywords 'foo', [ 'bar', 'baz' ], quux => sub { ... };
# tag methods as keywords sub some_keyword :PluginKeyword { ...; }
# keyword will be 'bar' sub foo :PluginKeyword(bar) { ... }
# keywords "do_it" and "do_them" will both use the method sub do_studd :PluginKeyword(do_it do_them) { ... }
# attributes can be exported as keywords too has foo => ( is => 'ro', plugin_keyword => 1, # will use keyword 'foo' );
has bar => ( is => 'ro', plugin_keyword => 'baz', # will use keyword 'baz' );
has quux => ( is => 'ro', plugin_keyword => [qw/ this that / ], # will use keyword 'this' and 'that' );
Joy, `/.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- ____________________________ Rubén Darío Amórtegui Medina MCE - Ingeniero de Sistemas
Just and update: I used the same code on the DSL module to call the functions, but I'm wondering if there is a better way to do it from the plugin. require Dancer2::Serializer::JSON; Dancer2::Serializer::JSON::to_json( $my_stuff ); Ruben. On Thu, Oct 15, 2015 at 12:06 PM, Rubén Amórtegui <ruben.amortegui@gmail.com
wrote:
Great!
One more question,
Is there a way to acces to "to_json" and "from_json" on the plugin?
Thanks!
Ruben.
On Wed, Oct 14, 2015 at 2:19 PM, Yanick Champoux <yanick@babyl.dyndns.org> wrote:
On 2015-10-14 01:49 PM, Stefan Hornburg (Racke) wrote:
Yanick, would you mind to enhance the POD with this example?
Done.
And sometime tomorrow (ie, as soon as I merge my changes), defining plugin keywords will get even easier:
# the classic plugin_keywords 'foo', [ 'bar', 'baz' ], quux => sub { ... };
# tag methods as keywords sub some_keyword :PluginKeyword { ...; }
# keyword will be 'bar' sub foo :PluginKeyword(bar) { ... }
# keywords "do_it" and "do_them" will both use the method sub do_studd :PluginKeyword(do_it do_them) { ... }
# attributes can be exported as keywords too has foo => ( is => 'ro', plugin_keyword => 1, # will use keyword 'foo' );
has bar => ( is => 'ro', plugin_keyword => 'baz', # will use keyword 'baz' );
has quux => ( is => 'ro', plugin_keyword => [qw/ this that / ], # will use keyword 'this' and 'that' );
Joy, `/.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- ____________________________ Rubén Darío Amórtegui Medina MCE - Ingeniero de Sistemas
-- ____________________________ Rubén Darío Amórtegui Medina MCE - Ingeniero de Sistemas
On 2015-10-15 02:06 PM, Rubén Amórtegui wrote:
Is there a way to acces to "to_json" and "from_json" on the plugin?
Dancer2 uses the module 'JSON', so I'd do the same in the plugin: use JSON; my $struct = from_json $data; Or you could use JSON::XS, or any of the different flavors. They all (should) play well together. Joy, `/.
participants (3)
-
Rubén Amórtegui -
Stefan Hornburg (Racke) -
Yanick Champoux