[Catalyst-commits] r12228 - in trunk/examples/CatalystAdvent/root/2009: . pen

t0m at dev.catalyst.perl.org t0m at dev.catalyst.perl.org
Sun Dec 6 22:15:15 GMT 2009


Author: t0m
Date: 2009-12-06 22:15:14 +0000 (Sun, 06 Dec 2009)
New Revision: 12228

Added:
   trunk/examples/CatalystAdvent/root/2009/7.pod
Removed:
   trunk/examples/CatalystAdvent/root/2009/pen/script_runner.pod
Log:
Move this out the pen as next in line

Copied: trunk/examples/CatalystAdvent/root/2009/7.pod (from rev 12227, trunk/examples/CatalystAdvent/root/2009/pen/script_runner.pod)
===================================================================
--- trunk/examples/CatalystAdvent/root/2009/7.pod	                        (rev 0)
+++ trunk/examples/CatalystAdvent/root/2009/7.pod	2009-12-06 22:15:14 UTC (rev 12228)
@@ -0,0 +1,71 @@
+=head1 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 L<Catalyst::Helper> API and L<Catalyst::Devel> package
+into something a little less hateful. And I accomplished this, more or less. 
+
+=head2 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 the extra C<render_sharedir_file> method to
+get templatesd from a sharedir generated by their Helper class.
+
+=head2 Scripts are now Classes
+
+The scripts, instead of being entities on their own, now just delegate the
+work to a C<< ScriptRunner >> class which finds a script class, loads it,
+makes an instance and invokes it's C<< ->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.
+
+=head2 What does this do for me?
+
+This means that fixing bugs in the scripts is significantly easier
+and less hassle for B<you>, as new scripts are included in L<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
+C<< MyApp::Script::XXX >> then L<Catalyst::ScriptRunning> will pick it up
+and run it in favour of the built in script.
+
+Authors of alternate engines should also be able to reuse L<Catalyst::ScriptRole>,
+provide a C<Catalyst::Script::> class and a C<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..
+
+L<Gitalist> is an example of an application already taking advantage of per-application
+scripts to provide a C<< --repo_dir >> option.
+
+=head2 Application skeleton now uses Moose.
+
+The generated application skeleton had been tidied up in a number of ways, and
+now generates applications which use L<Moose> and L<namespace::autoclean>,
+tests which use C< 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 C< #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

Deleted: trunk/examples/CatalystAdvent/root/2009/pen/script_runner.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2009/pen/script_runner.pod	2009-12-06 22:04:53 UTC (rev 12227)
+++ trunk/examples/CatalystAdvent/root/2009/pen/script_runner.pod	2009-12-06 22:15:14 UTC (rev 12228)
@@ -1,71 +0,0 @@
-=head1 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 L<Catalyst::Helper> API and L<Catalyst::Devel> package
-into something a little less hateful. And I accomplished this, more or less. 
-
-=head2 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 the extra C<render_sharedir_file> method to
-get templatesd from a sharedir generated by their Helper class.
-
-=head2 Scripts are now Classes
-
-The scripts, instead of being entities on their own, now just delegate the
-work to a C<< ScriptRunner >> class which finds a script class, loads it,
-makes an instance and invokes it's C<< ->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.
-
-=head2 What does this do for me?
-
-This means that fixing bugs in the scripts is significantly easier
-and less hassle for B<you>, as new scripts are included in L<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
-C<< MyApp::Script::XXX >> then L<Catalyst::ScriptRunning> will pick it up
-and run it in favour of the built in script.
-
-Authors of alternate engines should also be able to reuse L<Catalyst::ScriptRole>,
-provide a C<Catalyst::Script::> class and a C<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..
-
-L<Gitalist> is an example of an application already taking advantage of per-application
-scripts to provide a C<< --repo_dir >> option.
-
-=head2 Application skeleton now uses Moose.
-
-The generated application skeleton had been tidied up in a number of ways, and
-now generates applications which use L<Moose> and L<namespace::autoclean>,
-tests which use C< 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 C< #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




More information about the Catalyst-commits mailing list