What about a "use Dancer :config"?
Hi all, I was a little puzzled when I saw the "Use Dancer :syntax" disappear in the 0.007 release. I thought that a less powerful Dancer inclusion was needed as the "Use Dancer" create an App in every package is used. Thinking about it I realized that probably it's a matter of "code discipline" (tell me if I'm wrong). The right way to do things is not importing "a part" of Dancer environment, but passing the $dsl object when needed, so I accepted that. Even so, I think that there's a case when a "light" dancer import is needed and it is when you need to use some configuration you have in the config.yml that should be the master configuration file for everything in your project (in my idea). So I was wondering if it could be useful to add a "Use Dancer :config" way to import Dancer just to make the config keyword accessible, without creating an App. What do you think about this? -- Simone "Cymon" Faré http://perlishscrewdriver.blogspot.com
Hi, dancer newbie here. I recently wrote a script that read the dancer config in manually. In my opinion, this would be a great import tag. I'll share my use case (while bracing for "that doesn't belong in config, you idiot!" responses--it's ok, just tell me if you think that, I'm eager to learn.): I have a development, staging, and production instance of the app that run on the same url but different ports. I want to put the port number in the config.yml. Another thing someone might want in there would be the location of the PID file for killing the currently running process. I need this in the script that I use to start/re-start the app, which takes the name of the environment as an argument, then checks the PID file for the ID of a running process, kills and reports that, then runs plackup, telling it the port to start on and the name of the run file. Another thing you might want available outside the app is a mount point--instead of differentiating by port, you could mount the app at a different virtual directory (or whatever you call the url prefix). Possibly hostname, too--in short, anything I need to pass to plackup, I would like to be available in a script that doesn't start the app, but gives me the configuration info I need to start the app. mike On Fri, Sep 6, 2013 at 3:30 PM, Cymon <cymon.ML@gmail.com> wrote:
Hi all,
I was a little puzzled when I saw the "Use Dancer :syntax" disappear in the 0.007 release. I thought that a less powerful Dancer inclusion was needed as the "Use Dancer" create an App in every package is used. Thinking about it I realized that probably it's a matter of "code discipline" (tell me if I'm wrong). The right way to do things is not importing "a part" of Dancer environment, but passing the $dsl object when needed, so I accepted that.
Even so, I think that there's a case when a "light" dancer import is needed and it is when you need to use some configuration you have in the config.yml that should be the master configuration file for everything in your project (in my idea).
So I was wondering if it could be useful to add a "Use Dancer :config" way to import Dancer just to make the config keyword accessible, without creating an App.
What do you think about this?
-- Simone "Cymon" Faré http://perlishscrewdriver.blogspot.com _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Hey Cymon, Mike. The ":syntax" import tag wasn't ported to Dancer 2, other than accepting it. The tag was originally meant to not create a web server out of your application, which was useful for defining routes that aren't apps in and of themselves. In Dancer 2 the structure is a bit different which meant there was no need for the ":syntax" tag. You can just "use Dancer2" in your scripts and read the configurations. This is totally fine. We do, however, intend to support the ":script" tag (which is ignored for now) to prevent reading the @ARGV when processing requests. The problem is that the code for processing @ARGV hasn't been ported, so everything is working as if ":script" is in effect. In the end, the situation we want is: * "use Dancer2" without worrying. * "use Dancer2 ':script'" when you want to prevent @ARGV parsing, so you could have your own in your script. The first one is there. The second one is implied since there's no @ARGV parsing, but we will add it in the future. Perhaps you will do it? :) I hope that answers your questions. On Sat, Sep 7, 2013 at 1:20 AM, Mike South <msouth@gmail.com> wrote:
Hi,
dancer newbie here. I recently wrote a script that read the dancer config in manually. In my opinion, this would be a great import tag.
I'll share my use case (while bracing for "that doesn't belong in config, you idiot!" responses--it's ok, just tell me if you think that, I'm eager to learn.):
I have a development, staging, and production instance of the app that run on the same url but different ports. I want to put the port number in the config.yml. Another thing someone might want in there would be the location of the PID file for killing the currently running process. I need this in the script that I use to start/re-start the app, which takes the name of the environment as an argument, then checks the PID file for the ID of a running process, kills and reports that, then runs plackup, telling it the port to start on and the name of the run file.
Another thing you might want available outside the app is a mount point--instead of differentiating by port, you could mount the app at a different virtual directory (or whatever you call the url prefix). Possibly hostname, too--in short, anything I need to pass to plackup, I would like to be available in a script that doesn't start the app, but gives me the configuration info I need to start the app.
mike
On Fri, Sep 6, 2013 at 3:30 PM, Cymon <cymon.ML@gmail.com> wrote:
Hi all,
I was a little puzzled when I saw the "Use Dancer :syntax" disappear in the 0.007 release. I thought that a less powerful Dancer inclusion was needed as the "Use Dancer" create an App in every package is used. Thinking about it I realized that probably it's a matter of "code discipline" (tell me if I'm wrong). The right way to do things is not importing "a part" of Dancer environment, but passing the $dsl object when needed, so I accepted that.
Even so, I think that there's a case when a "light" dancer import is needed and it is when you need to use some configuration you have in the config.yml that should be the master configuration file for everything in your project (in my idea).
So I was wondering if it could be useful to add a "Use Dancer :config" way to import Dancer just to make the config keyword accessible, without creating an App.
What do you think about this?
-- Simone "Cymon" Faré http://perlishscrewdriver.blogspot.com _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, Sep 8, 2013 at 4:57 AM, sawyer x <xsawyerx@gmail.com> wrote:
Hey Cymon, Mike.
The ":syntax" import tag wasn't ported to Dancer 2, other than accepting it. The tag was originally meant to not create a web server out of your application, which was useful for defining routes that aren't apps in and of themselves. In Dancer 2 the structure is a bit different which meant there was no need for the ":syntax" tag.
You can just "use Dancer2" in your scripts and read the configurations. This is totally fine.
We do, however, intend to support the ":script" tag (which is ignored for now) to prevent reading the @ARGV when processing requests. The problem is that the code for processing @ARGV hasn't been ported, so everything is working as if ":script" is in effect.
In the end, the situation we want is: * "use Dancer2" without worrying. * "use Dancer2 ':script'" when you want to prevent @ARGV parsing, so you could have your own in your script.
The first one is there. The second one is implied since there's no @ARGV parsing, but we will add it in the future. Perhaps you will do it? :)
Sure, if you describe what needs to be done I'll make an attempt and put a pull request in. mike
I hope that answers your questions.
On Sat, Sep 7, 2013 at 1:20 AM, Mike South <msouth@gmail.com> wrote:
Hi,
dancer newbie here. I recently wrote a script that read the dancer config in manually. In my opinion, this would be a great import tag.
I'll share my use case (while bracing for "that doesn't belong in config, you idiot!" responses--it's ok, just tell me if you think that, I'm eager to learn.):
I have a development, staging, and production instance of the app that run on the same url but different ports. I want to put the port number in the config.yml. Another thing someone might want in there would be the location of the PID file for killing the currently running process. I need this in the script that I use to start/re-start the app, which takes the name of the environment as an argument, then checks the PID file for the ID of a running process, kills and reports that, then runs plackup, telling it the port to start on and the name of the run file.
Another thing you might want available outside the app is a mount point--instead of differentiating by port, you could mount the app at a different virtual directory (or whatever you call the url prefix). Possibly hostname, too--in short, anything I need to pass to plackup, I would like to be available in a script that doesn't start the app, but gives me the configuration info I need to start the app.
mike
On Fri, Sep 6, 2013 at 3:30 PM, Cymon <cymon.ML@gmail.com> wrote:
Hi all,
I was a little puzzled when I saw the "Use Dancer :syntax" disappear in the 0.007 release. I thought that a less powerful Dancer inclusion was needed as the "Use Dancer" create an App in every package is used. Thinking about it I realized that probably it's a matter of "code discipline" (tell me if I'm wrong). The right way to do things is not importing "a part" of Dancer environment, but passing the $dsl object when needed, so I accepted that.
Even so, I think that there's a case when a "light" dancer import is needed and it is when you need to use some configuration you have in the config.yml that should be the master configuration file for everything in your project (in my idea).
So I was wondering if it could be useful to add a "Use Dancer :config" way to import Dancer just to make the config keyword accessible, without creating an App.
What do you think about this?
-- Simone "Cymon" Faré http://perlishscrewdriver.blogspot.com _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, Sep 8, 2013 at 4:31 PM, Mike South <msouth@gmail.com> wrote:
On Sun, Sep 8, 2013 at 4:57 AM, sawyer x <xsawyerx@gmail.com> wrote:
In the end, the situation we want is: * "use Dancer2" without worrying. * "use Dancer2 ':script'" when you want to prevent @ARGV parsing, so you could have your own in your script.
The first one is there. The second one is implied since there's no @ARGV parsing, but we will add it in the future. Perhaps you will do it? :)
Sure, if you describe what needs to be done I'll make an attempt and put a pull request in.
I'd be happy to. Find me on IRC. :)
participants (3)
-
Cymon -
Mike South -
sawyer x