Jumpstarting Reaction Applications

The Script in Action

Since this module comes with templates and this is all still experimental, the share directory discovery is still a bit crude, so I have to tell it where to look.

REACTIONX_JUMPSTART_SHAREDIR=share/ script/reaction-jumpstart

After that, the script will ask a (dynamic) series of questions and tell us which files it generated:

Namespace of the project? (example: MyApp) MyApp
Name of the UI? (example: Web for MyApp::Web) [default Web] 
Descriptive name of the application? [default MyApp] 
 -> writing package MyApp::Web
Name of the View? (example: Site for MyApp::Web::View::Site) 
  [default Site] 
 -> writing package MyApp::Web::View::Site
 -> writing file test/myapp/share/skin/defaults.conf
Name of your application's Skin? [default myapp_web] 
Name of the Skin from which your Skin inherits? 
  [default /Reaction/default] 
 -> creating directory test/myapp/share/skin/myapp_web/layout
 -> creating directory test/myapp/share/skin/myapp_web/web
 -> writing file test/myapp/share/skin/myapp_web/skin.conf
Create a Root Controller? (The Controller managing '/') 
  [default y] 
Name of the Controller? (example: Root for 
  MyApp::Web::Controller::Root) [default Root] 
Do you want a base action to push the SiteLayout ViewPort? 
  (y or n) [default y] 
Do you want a customized SiteLayout ViewPort, Widget and 
  LayoutSet? (y or n) [default y] 
 -> writing package MyApp::Web::ViewPort::SiteLayout
 -> writing package MyApp::Web::View::Site::Widget::SiteLayout
 -> writing file test/myapp/share/skin/myapp_web/layout/site_layout.tt
 -> writing package MyApp::Web::Controller::Root
 -> writing file test/myapp/etc/myapp_web.conf

At the moment, only the first question for the project namespace is required. All other questions have defaults. I hope to keep it this way, so a beginner can just choose a name, then “lean” on the enter key, and end up with a working Reaction application.

Since many things in Reaction are about configuration, I decided to ask the user questions instead of having command line parameters. Having the script tell me what it needs to know is much nicer than trying to figure it out by yourself via a manual.

Of course the defaults do force a certain opinion on the user, but since this is often wanted by newcomers nowadays and nobody is forced to accept them, I don’t see any harm with that, and we can also subtly introduce some larger best practices.

In the questions above, these opinions would be (among others):

• The project namespace and the web application namespace are separated. At a later stage, the Schema or InterfaceModel classes would be under the project namespace (MyApp::) not the UI namespace (MyApp::Web::).

• The SiteLayout group (ViewPort, Widget and LayoutSet) is one I need to change in almost every Reaction project. So the script defaults to creating extensions for them right from the start.

Currently, the script above will create the application directory below a created test/ directory.

The Wonders of Moose Attributes

Since I wanted to keep the questioning of the user simple, but dynamic, I decided to write an (admittedly very hack-ish) attribute trait to lazily prompt the user for the value when required. The type constraint of the attribute is used to determine the type of question to ask. To see an example of how that eases the design of the interface, take a look at how UI and project namespace are aquired.

What is Left

Quite a lot. In no particular order:

• After the jumpstarting is finished, the script should switch into an extension mode. This should allow users to use the script to add InterfaceModel Reflectors, Schema’s, Result and ResultSet classes, Searches, InterfaceModel Actions, Collections, special controllers (CRUD, Collection, Auth), ViewPorts, Widgets, LayoutSets, and many, many more things that I won’t list now.

• Since the questions can be uniquely identified via class/attribute (thanks Moose!) it should be easy to put more elaborate help for the questions on to CPAN and have the script provide links to them).

• The scripts, Makefile.PL, tests, etc. are not yet generated.

• It would be nice if the templates were subclassable, so you could use a set of MooseX::/CatalystX::Declare skeletons instead of the traditional Perl ones. On the other hand, if the declarative Catalyst extension stabilizes, I might just switch over to that completely. Time will tell.

Sounds Good?

This post is aimed at both seasoned Reaction developers and those that haven’t touched Reaction at all (and of course those in-between). But mainly the latter. If you haven’t had a chance to work with Reaction yet, or if you wanted but the entry curve was to steep, have a closer look at the above and drop me a comment if there is anything I didn’t mention that you’d want to see in such a solution. If I thought something up that makes no sense to you, I’d be very interested in that feedback too, of course.