Catalyst::ScriptRunner
Summer of 2009 brought some great things, and one of these things was my being accepted into the Google Summer of Code! My project was to refactor the Catalyst::Helper API and Catalyst::Devel package into something a little less hateful. And I accomplished this, more or less.
Application skeleton files are now in a sharedir
The application skeleton files are now stored in a sharedir, making it
much easier to alter / patch the content of generated
applications. Component authors can also now use a sharedir, and can use
the the extra render_sharedir_file
method to get templates from a
sharedir generated by their Helper class.
Scripts are now Classes
The scripts, instead of being entities on their own, now just delegate the
work to a ScriptRunner
class which finds a script class, loads it,
makes an instance, and invokes its ->run
method.
If you open up a new script, you'll see something like this:
#!/usr/bin/env perl use Catalyst::ScriptRunner; Catalyst::ScriptRunner->run('MyApp', 'Server'); 1;
As opposed to 100+ lines of development server logic.
What does this do for me?
This means that fixing bugs in the scripts is significantly easier and less hassle for you, because new scripts are included in Catalyst::Runtime. Therefore you get the benefit of them just by upgrading, rather than having to regenerate your scripts.
Also, you can write custom scripts, or easily add options to the
existing scripts. This is Really Good if you want to hack your own
server with additional command line flags. If you create a class called
MyApp::Script::XXX
, then Catalyst::ScriptRunner will pick it
up and run it in favor of the built-in script.
Authors of alternate engines should also be able to reuse
Catalyst::ScriptRole, provide a Catalyst::Script::
class and a
Catalyst::Helper::
class, and then generate myapp_engine.pl
scripts
for the user which work just like the other scripts, without duplicating
all of the script code.
Gitalist is an example of an application already taking advantage of
per-application scripts to provide a --repo_dir
option.
Application skeleton now uses Moose
The generated application skeleton has been tidied up in a number of ways, and
now generates applications which use Moose and namespace::autoclean,
tests which use done_testing
, and which turn off some deprecated features.
That's all folks, short and simple.
Hopefully you'll think of some cool and fun uses for the new scripts and
Helper code, and you'll blog in your Ironman blogs about them, or come
chat to us in #catalyst-dev
about what you'd like to do if it
doesn't seem obvious.
This new work is a good basis for people being able to do cool things, but I'm sure there is some work still to be done to make it easier when people start experimenting with their real life use-cases.
- Devin "dhoss" Austin, and thanks a boatload to Tomas Doran for reviewing and beefing things up in this article.