[dancer-users] Dancer2 panels for Plack::Debugger
billy at bottlenose-wine.com
Sat Apr 23 21:00:56 BST 2016
I don’t have any suggestions but I’m thankful you’re taking this on.
> On Apr 23, 2016, at 6:19 AM, Peter Mottram <peter at sysnix.com> wrote:
> As I slowly drag myself away from Dancer1 towards Dancer2 I've found
> myself missing my much-loved Dancer::Debug panels and so have started
> working on a set of panels using Plack::Debugger. Before I get lost down
> too many rabbit holes I thought I'd share my current plan with the wider
> community to see how others might want to see things and to ask for
> thoughts on where I might already be going wrong.
> My approach for collecting D2 data (tokens, routes, etc) is by creating
> Dancer2::Plugin::Debugger which can then use hooks, etc and stash
> collected data via Cache::Mmap (probably serialsed using JSON) to be
> picked up by Plack::Debugger panels in 'after' callbacks. The plugin
> must be specifically enabled in config so importing is effectively a
> noop if config is not enabled.
> On the Dancer2 plugin side any collector class would be created under
> the Dancer2::Plugin::Debugger::Panel namespace with a corresponding
> class created under Plack::Debugger::Panel::Dancer2 so for example
> Dancer2::Plugin::Debugger::Panel::TemplateTokens would have a
> corresponding Plack::Debugger::Panel::Dancer2::TemplateTokens.
> I'm also planning to have Dancer2::Debugger which is a Dancer2 app which
> sets up the Plack::Debugger side of things to make setup in the psgi
> file as simple as possible keeping configuration shared between the two
> parts in D2 config files.
> The current plan allows for new panels to be released as individual
> distros which provide the plugin panel and the debugger panel classes.
> So before I wade in too deep does anyone have any suggestions, issues, ...?
> dancer-users mailing list
> dancer-users at dancer.pm
More information about the dancer-users