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
On Sun, 8 Feb 2015 10:21:52 +0100 (CET) Henk van Oers <hvo.pm@xs4all.nl> wrote:
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?
This is something I've really wanted to find time to attempt - a universal plugin API module that plugins could inherit from, and write code using that API which would work the same in D1 & D2. Unfortunately, a tuit shortage has prevented me from it, so far; I think it'd need some fairly careful design to be useful, but if achieved, it'd be fantastic. Perhaps it's something we could collaborate on?
This is something that I have been struggling with as well. My experience is working on something ( https://github.com/pdl/Articulate/ ) which I hope will become a very flexible base for CMSs of all sorts. I started off with it being a collection of Dancer1 plugins which worked together but the problem of "which app do I belong to" (which Dancer2, quite correctly, as far as I'm concerned, forces you to think about) meant I had to consolidate it into a single mega-plugin which had subcomponents which explicitly know about each other - one of which is a framework adapter which works on either Dancer1 or Dancer2 (and possibly more). At the moment I'm quite happy about that and breathing easy because it was possible to reduce the interactions with Dancer to a couple of fairly contained components (even though the interface is still a bit ramshackle at present). That approach may be excessive for plugins to implement themselves, but having a generic 'DancerX::Plugin' class that does that stuff for you would be very nice. I also agree that it would be a massive help (possibly a prerequisite of the above) to have a single object for either Dancer which behaved the same way and which provides methods equivalent to the functional interface that you get when you do either `use Dancer;` or `use Dancer appname => 'Foo';`, and I would definitely be wiling to help out if it was something Dancer core devs agreed in principle should happen. Daniel Details of how I'm doing it so far if you're curious: https://github.com/pdl/Articulate/blob/master/lib/Dancer/Plugin/Articulate.p... https://github.com/pdl/Articulate/blob/master/lib/Dancer2/Plugin/Articulate.... https://github.com/pdl/Articulate/blob/master/lib/Articulate/FrameworkAdapte... https://github.com/pdl/Articulate/blob/master/lib/Articulate/FrameworkAdapte... On 8 February 2015 at 14:24, David Precious <davidp@preshweb.co.uk> wrote:
On Sun, 8 Feb 2015 10:21:52 +0100 (CET) Henk van Oers <hvo.pm@xs4all.nl> wrote:
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?
This is something I've really wanted to find time to attempt - a universal plugin API module that plugins could inherit from, and write code using that API which would work the same in D1 & D2.
Unfortunately, a tuit shortage has prevented me from it, so far; I think it'd need some fairly careful design to be useful, but if achieved, it'd be fantastic.
Perhaps it's something we could collaborate on? _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, 8 Feb 2015, D Perrett wrote:
This is something that I have been struggling with as well. My experience is working on something ( https://github.com/pdl/Articulate/ ) which I hope will become a very flexible base for CMSs of all sorts. I started off with it being a collection of Dancer1 plugins which worked together but the problem of "which app do I belong to" (which Dancer2, quite correctly, as far as
You are right.
I'm concerned, forces you to think about) meant I had to consolidate it into a single mega-plugin which had subcomponents which explicitly know about each other - one of which is a framework adapter which works on either Dancer1 or Dancer2 (and possibly more).
At the moment I'm quite happy about that and breathing easy because it was possible to reduce the interactions with Dancer to a couple of fairly contained components (even though the interface is still a bit ramshackle at present).
That approach may be excessive for plugins to implement themselves, but having a generic 'DancerX::Plugin' class that does that stuff for you would be very nice.
I also agree that it would be a massive help (possibly a prerequisite of the above) to have a single object for either Dancer which behaved the same way and which provides methods equivalent to the functional interface that you get when you do either `use Dancer;` or `use Dancer appname => 'Foo';`, and I would definitely be wiling to help out if it was something Dancer core devs agreed in principle should happen.
Daniel
Details of how I'm doing it so far if you're curious:
https://github.com/pdl/Articulate/blob/master/lib/Dancer/Plugin/Articulate.p... https://github.com/pdl/Articulate/blob/master/lib/Dancer2/Plugin/Articulate....
With a 'DancerX::Plugin' that could be only one.
https://github.com/pdl/Articulate/blob/master/lib/Articulate/FrameworkAdapte... https://github.com/pdl/Articulate/blob/master/lib/Articulate/FrameworkAdapte...
You implement a smal part of the DSL. If you make your FrameworkAdapter/Dancer* a Dancer plugin, I think you can do more. Maybe even use "normal" plugins. But your goal is to support other frameworks as well. I'm interested. ++ for your Moo skils. -- Henk
On Sun, 8 Feb 2015, David Precious wrote:
On Sun, 8 Feb 2015 10:21:52 +0100 (CET) Henk van Oers <hvo.pm@xs4all.nl> wrote:
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?
It can get DRYer. All existing plugins can stay in there current namespace.
This is something I've really wanted to find time to attempt - a universal plugin API module that plugins could inherit from, and write code using that API which would work the same in D1 & D2.
Unfortunately, a tuit shortage has prevented me from it, so far; I think it'd need some fairly careful design to be useful, but if achieved, it'd be fantastic.
Perhaps it's something we could collaborate on?
Yes please. I have a tuit shortage to convert all my D1 stuff. I can make a POC for a small D1 plugin and run it under D2. -- Henk
participants (3)
-
D Perrett -
David Precious -
Henk van Oers