Hello, some times ago I wrote about idea of skeleton dir with default dancer app. It's convenient when projects differs from default dancer layout with simple or TT template. For example, in every our project we use only CTPP as templates, CGI::WebIn, which requires some additional strings in hook 'before' by default, etc. Does this feature exists or planned now? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
This (scaffolding profiles) was planned on doing using Dancer::Script, which was part of the work of Carlos (gnusosa). I was just successful at rebasing his code on everything that happened since (phew...) and it's available on the gnusosa-scripting branch. Considering the current state of Dancer 1 and 2, I think we should enable this feature on Dancer 2 but let go for Dancer 1. I'd be happy if you could help plan and execute this. :) On Wed, Oct 10, 2012 at 10:34 AM, Nick Knutov <mail@knutov.com> wrote:
Hello,
some times ago I wrote about idea of skeleton dir with default dancer app. It's convenient when projects differs from default dancer layout with simple or TT template.
For example, in every our project we use only CTPP as templates, CGI::WebIn, which requires some additional strings in hook 'before' by default, etc.
Does this feature exists or planned now?
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ______________________________**_________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/**cgi-bin/listinfo/dancer-users<http://www.backup-manager.org/cgi-bin/listinfo/dancer-users>
On Wed, 10 Oct 2012 23:05:32 +0200 sawyer x <xsawyerx@gmail.com> wrote:
This (scaffolding profiles) was planned on doing using Dancer::Script, which was part of the work of Carlos (gnusosa). I was just successful at rebasing his code on everything that happened since (phew...) and it's available on the gnusosa-scripting branch.
Considering the current state of Dancer 1 and 2, I think we should enable this feature on Dancer 2 but let go for Dancer 1. I'd be happy if you could help plan and execute this. :)
Agree - gnusosa did some excellent work which unfortunately languished due to Dancer2 stealing the show - I think his work should indeed be included in Dancer2!
Yep, Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ? On 11 October 2012 01:09, David Precious <davidp@preshweb.co.uk> wrote:
On Wed, 10 Oct 2012 23:05:32 +0200 sawyer x <xsawyerx@gmail.com> wrote:
This (scaffolding profiles) was planned on doing using Dancer::Script, which was part of the work of Carlos (gnusosa). I was just successful at rebasing his code on everything that happened since (phew...) and it's available on the gnusosa-scripting branch.
Considering the current state of Dancer 1 and 2, I think we should enable this feature on Dancer 2 but let go for Dancer 1. I'd be happy if you could help plan and execute this. :)
Agree - gnusosa did some excellent work which unfortunately languished due to Dancer2 stealing the show - I think his work should indeed be included in Dancer2!
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
yeah, sure. On Thu, Oct 11, 2012 at 11:23 AM, damien krotkine <dkrotkine@gmail.com>wrote:
Yep,
Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ?
On 11 October 2012 01:09, David Precious <davidp@preshweb.co.uk> wrote:
On Wed, 10 Oct 2012 23:05:32 +0200 sawyer x <xsawyerx@gmail.com> wrote:
This (scaffolding profiles) was planned on doing using Dancer::Script, which was part of the work of Carlos (gnusosa). I was just successful at rebasing his code on everything that happened since (phew...) and it's available on the gnusosa-scripting branch.
Considering the current state of Dancer 1 and 2, I think we should enable this feature on Dancer 2 but let go for Dancer 1. I'd be happy if you could help plan and execute this. :)
Agree - gnusosa did some excellent work which unfortunately languished due to Dancer2 stealing the show - I think his work should indeed be included in Dancer2!
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On 10/11/2012 11:23 AM, damien krotkine wrote:
Yep,
Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ?
I suppose it needs a bit of rewrite as Dancer::Script class derives from Dancer::Object, which is gone in Dancer 2. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
On Thu, Oct 11, 2012 at 12:02 PM, Stefan Hornburg (Racke) <racke@linuxia.de>wrote:
On 10/11/2012 11:23 AM, damien krotkine wrote:
Yep,
Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ?
I suppose it needs a bit of rewrite as Dancer::Script class derives from Dancer::Object, which is gone in Dancer 2.
Yes. Indeed.
On 10/11/2012 12:22 PM, sawyer x wrote:
On Thu, Oct 11, 2012 at 12:02 PM, Stefan Hornburg (Racke) <racke@linuxia.de>wrote:
On 10/11/2012 11:23 AM, damien krotkine wrote:
Yep,
Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ?
I suppose it needs a bit of rewrite as Dancer::Script class derives from Dancer::Object, which is gone in Dancer 2.
Yes. Indeed.
Also, any suggestions on rewriting this part of code for Dancer 2 as Dancer::ModuleLoader is gone too: unless (Dancer::ModuleLoader->load('YAML')) { print <<NOYAML; ***** WARNING: YAML.pm is not installed. This is not a full dependency, but is highly recommended; in particular, the scaffolded Dancer app being created will not be able to read settings from the config file without YAML.pm being installed. To resolve this, simply install YAML from CPAN, for instance using one of the following commands: cpan YAML perl -MCPAN -e 'install YAML' curl -L http://cpanmin.us | perl - --sudo YAML ***** NOYAML } Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
On Fri, 12 Oct 2012 16:28:33 +0200 "Stefan Hornburg (Racke)" <racke@linuxia.de> wrote:
On 10/11/2012 12:22 PM, sawyer x wrote:
On Thu, Oct 11, 2012 at 12:02 PM, Stefan Hornburg (Racke) <racke@linuxia.de>wrote:
On 10/11/2012 11:23 AM, damien krotkine wrote:
Yep,
Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ?
I suppose it needs a bit of rewrite as Dancer::Script class derives from Dancer::Object, which is gone in Dancer 2.
Yes. Indeed.
Also, any suggestions on rewriting this part of code for Dancer 2 as Dancer::ModuleLoader is gone too:
unless (Dancer::ModuleLoader->load('YAML')) { print <<NOYAML; ***** WARNING: YAML.pm is not installed. This is not a full dependency, but is highly recommended; in particular, the scaffolded Dancer app being created will not be able to read settings from the config file without YAML.pm being installed. [...]
Since Dancer2 uses Config::Any, so they could use any of a variety of config file formats, I expect that bit can just be removed. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
On 10/12/2012 05:07 PM, David Precious wrote:
On Fri, 12 Oct 2012 16:28:33 +0200 "Stefan Hornburg (Racke)"<racke@linuxia.de> wrote:
On 10/11/2012 12:22 PM, sawyer x wrote:
On Thu, Oct 11, 2012 at 12:02 PM, Stefan Hornburg (Racke) <racke@linuxia.de>wrote:
On 10/11/2012 11:23 AM, damien krotkine wrote:
Yep,
Sawyer : can you try to push it in master as soon as you're convinced it's stable and sane enough ?
I suppose it needs a bit of rewrite as Dancer::Script class derives from Dancer::Object, which is gone in Dancer 2.
Yes. Indeed.
Also, any suggestions on rewriting this part of code for Dancer 2 as Dancer::ModuleLoader is gone too:
unless (Dancer::ModuleLoader->load('YAML')) { print<<NOYAML; ***** WARNING: YAML.pm is not installed. This is not a full dependency, but is highly recommended; in particular, the scaffolded Dancer app being created will not be able to read settings from the config file without YAML.pm being installed. [...]
Since Dancer2 uses Config::Any, so they could use any of a variety of config file formats, I expect that bit can just be removed.
I suppose we have to start with ONE configuration file format for Dancer::Script though. IMHO new users don't want to decide about the format and such. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
On Fri, Oct 12, 2012 at 5:10 PM, Stefan Hornburg (Racke) <racke@linuxia.de>wrote:
On 10/12/2012 05:07 PM, David Precious wrote:
Since Dancer2 uses Config::Any, so they could use any of a variety of config file formats, I expect that bit can just be removed.
Yup. Just "use YAML" or "use Config::Any"; It would probably be better to actually lazily load "JSON" or whatever to write the configuration file with the requested format and die if it fails. That way it's like "if you got Config::INI, we'll be able to write you an .ini config".
I suppose we have to start with ONE configuration file format for Dancer::Script though. IMHO new users don't want to decide about the format and such.
New users might not, but experienced users already asked for the ability to work with different file formats for the configuration file. Jason Crome had done the proper work on supporting Config::Any in reading the configuration file. It has been merged. Awesome work, obviously. :)
On 10/13/2012 07:39 PM, sawyer x wrote:
On Fri, Oct 12, 2012 at 5:10 PM, Stefan Hornburg (Racke) <racke@linuxia.de>wrote:
On 10/12/2012 05:07 PM, David Precious wrote:
Since Dancer2 uses Config::Any, so they could use any of a variety of config file formats, I expect that bit can just be removed.
Yup. Just "use YAML" or "use Config::Any"; It would probably be better to actually lazily load "JSON" or whatever to write the configuration file with the requested format and die if it fails. That way it's like "if you got Config::INI, we'll be able to write you an .ini config".
I suppose we have to start with ONE configuration file format for Dancer::Script though. IMHO new users don't want to decide about the format and such.
New users might not, but experienced users already asked for the ability to work with different file formats for the configuration file. Jason Crome had done the proper work on supporting Config::Any in reading the configuration file. It has been merged.
Experienced users could use the proper commandline switches once we fully ported dancer script to D2. I started that project here: https://github.com/racke/dancer2/tree/topic/dancer_script This is still in the early stages, but at least it runs and produces a few files 8-). It bails out with the following error: no template found for Test/MANIFEST.SKIP at /home/racke/dancer/core/lib/Dancer/Script.pm line 313, <DATA> line 998. But this bug is inherited from the Dancer 1 / gnusosa-script code. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
participants (5)
-
damien krotkine -
David Precious -
Nick Knutov -
sawyer x -
Stefan Hornburg (Racke)