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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >> > > > _______________________________________________ > dancer-users mailing list > [email protected] > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users > >
_______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
